Comparison
mcp gateway vs. compliance layer.
Both sit in front of your MCP server, both get called "control" - yet they answer different questions. The gateway governs who may talk. The compliance layer governs which individual action may happen, who approves it and how that is proven.
MCP-Gateway
An MCP gateway is infrastructure: authentication, rate limits, routing, a tool registry - comparable to an API gateway. It answers the access question. Some gateways now ship approval features too, typically developer-oriented via Slack or webhooks.
Glossary: MCP gatewayCompliance-Layer
A compliance layer is the workflow and evidence layer behind it: per-tool rules with conditions, approvals on the decision-makers' channels, deadlines, the four-eyes principle - and tamper-evident proof of every decision, usable as an audit annex.
Glossary: human-in-the-loopThe division of labor in detail.
| Aspect | MCP gateway | Compliance layer |
|---|---|---|
| Core question | Who may access at all? | May this one action happen - and who answers for it? |
| Auth, rate limits, routing | Yes - the core business | No, deliberately not |
| Per-tool-call rules with conditions | Partly, mostly allow/deny lists | Yes - allow/approve/deny plus amounts and hours |
| Approvals by non-developers | Typically Slack/webhook for engineers | Signed email links, push, SMS, WhatsApp - for CFO and team lead |
| Deadlines & four-eyes principle | Rare | Yes, configurable per rule |
| Tamper-evident record | Logs | SHA-256 hash chain, oversight report (PDF/CSV) with verification |
| Segregation of duties | Controls and attests itself | Independent instance next to execution |
| Typical user | Platform and infrastructure team | Ops, compliance, internal audit - and business decision-makers |
When is a gateway enough?
- Your agents run internally, decision-makers are developers, Slack approvals suffice.
- There are no evidence obligations - no Art. 14 exposure, no internal audit, no ICS.
- You mainly need access control, quotas and a tool registry.
When do you need the independent layer?
- Auditors, internal control or data protection ask for provable human oversight (EU AI Act Art. 14, ISO 42001, ICS).
- Decision-makers are not developers: the team lead approves via email, not in a terminal.
- Critical operations demand four-eyes and deadlines - documented.
- The evidence must be independent of the executing system to hold up in an audit.
The structural argument: segregation of duties.
Even when a gateway ships approvals, one question auditors ask remains open: can the instance that executes credibly attest that it controlled itself correctly? Internal control systems separate execution and control for exactly this reason. An independent compliance layer is that separation - it works with any gateway or none, and its evidence does not belong to the vendor whose infrastructure it attests.
Frequent questions.
- Does tokyn.trail replace my MCP gateway?
- No - deliberately not. Auth, rate limits and routing stay with the gateway. tokyn.trail is the workflow and evidence layer in between, and works with any gateway or directly in front of the MCP server.
- My gateway already has approvals - why a second layer?
- Because of three gaps auditors find: approval workflows for non-developers (email, deadlines, four-eyes), a tamper-evident record with hash-chain verification usable as an audit annex - and segregation of duties: control should not belong to the same system that executes.
- How much latency does the extra layer cost?
- p95 < 150 ms overhead for passed-through calls - enforced as a CI benchmark. Held calls wait on purpose: for a human.
- Can I start small?
- Yes: monitor mode only records and blocks nothing (fail-open). Rules and enforce mode follow once you have seen the status quo.
tokyn.trail is that independent compliance layer - in front of your MCP server in 10 minutes, no code changes.
Start for free