The question behind the question
The MCP gateway category matured fast. There are now well over a dozen credible products, and if your problem is that your engineers have connected forty MCP servers with no central control, you should buy one. This page is not an argument against them.
It exists because a different question keeps getting asked with the same words. "How do we govern our agents' MCP connections?" means one thing when every server belongs to you, and something else entirely when the server on the other end belongs to another bank.
What an MCP gateway does well
An MCP gateway sits between your agents and the MCP servers they call, and gives you the things any proxy layer gives you:
- Discovery and cataloguing — one register of which servers exist and which tools they expose.
- Access control — which internal teams, agents or users may reach which tools.
- Traffic management — rate limits, timeouts, retries, failover.
- Observability — logging, tracing and cost attribution across agent tool calls.
- Secret handling — credentials held centrally rather than scattered through agent configuration.
All of it is genuinely useful, and all of it rests on one assumption: you are the administrator of both ends. You can enumerate the servers because you deployed them. You can trust the catalogue because you populated it. You can act on the logs because they describe your own systems.
Where the model breaks
Cross the organisational boundary and each of those assumptions inverts. The counterparty is a separate legal entity with its own regulator, its own risk appetite and no obligation to tell you when something changes.
A gateway's catalogue entry says a server is what it claims to be because someone at your company said so when they added it. That is a perfectly good control for an internal service. It is not a control at all when the entry describes another institution.
Four capabilities have no internal analogue, because internally they are never needed:
- Entity verification. Someone must independently establish that the counterparty is the licensed institution it claims to be. See what agent attestation is.
- Bilateral policy. Both organisations have to agree what may be exchanged. An internal ACL is a decision one party makes; a counterparty policy is a position two parties hold.
- Mutual, shared evidence. Your logs are your account of events. A dispute between two institutions needs a record neither side authored alone. See AI agent audit trails.
- Network-wide revocation. When a counterparty's agent is compromised, every organisation exchanging with it needs that to take effect at once, not after each of them notices.
Side by side
| MCP gateway | Agent trust layer | |
|---|---|---|
| Problem | Control over the servers you run | Trust in organisations you do not run |
| Both ends owned by you | Assumed | Assumed not |
| Identity of counterparty | Configured by an administrator | Independently verified, cryptographically attested |
| Policy | Internal ACL, one party decides | Bilateral, per-counterparty and per-data-class |
| Record | Your logs, authored by you | Sealed ledger both parties and a regulator can rely on |
| Revocation | Remove from your catalogue | Instant and network-wide |
| Buyer | Platform or DevOps | Risk, compliance, architecture |
Comparing gateways: what to actually ask
If you are running a gateway comparison, most vendor matrices compare the same dozen features and skip the questions that determine whether the thing survives contact with a risk function. These are the ones worth adding to your evaluation, whichever product you land on:
| Question | What a weak answer sounds like |
|---|---|
| How do you establish that an external server is the organisation it claims to be? | “You add it to the catalogue and set the trust level.” |
| Who can see the record of an exchange with a counterparty? | “It is in your logs.” — meaning your account only, authored by you. |
| How long to sever a compromised external dependency, and whose cooperation is needed? | Anything measured in tickets rather than seconds. |
| Can policy differ per counterparty and per data class, enforced inline? | “You can allow or deny the server.” |
| What do you hand a regulator after a disputed agent-negotiated outcome? | An export of application logs. |
| Where does data reside, and can we run zero-retention on sensitive classes? | A single global region with no per-class control. |
An internal gateway answering these weakly is not a bad product — it is a product being asked a question it was never built for. The questions only become fair once the counterparty is somebody else’s company.
Which do you need?
A reasonable test: name the organisation that operates the server on the other end.
- If it is always yours, you need a gateway. A trust layer would be solving a problem you do not have.
- If it is sometimes another company — a partner insurer, a correspondent bank, an agency — and the data class is regulated, no amount of internal gateway configuration will produce the evidence your risk function will eventually ask for.
- If your agents will be transacting externally within twelve months, the boundary problem arrives before the pilot ends, not after it.
Running both
These compose rather than compete, and the split is clean. Keep the gateway as the internal control plane: catalogue, rate limits, secrets, tracing across everything your agents touch. Put the trust layer at the boundary, governing only the exchanges that leave your organisation.
MCPLayer is explicitly designed not to displace what you already run. You bring the MCP servers you have, bind them to your organisation's attestation, and declare the data classes and scopes they expose externally. Internal traffic never touches it.
Can an MCP gateway be extended to do this?
Parts of it, but the hard part is not software. Entity verification, licence checks and a record two institutions both accept are a registry and governance function — they require a third party that neither counterparty controls. A gateway you administer cannot attest to someone else's identity for the same reason you cannot issue your own passport.
Is this just an API gateway for agents?
The architectural pattern is familiar, which is deliberate. What differs is what is enforced. An API gateway authenticates a caller against credentials you issued. A trust layer verifies a counterparty you did not onboard, applies policy both parties agreed, and produces evidence for a third party who was not present.
Do we have to replace our existing MCP servers?
No. Bring the servers you already run and bind them to your attestation. The servers stay yours; the trust layer governs who may reach them, on what terms, and what record the exchange leaves.