MCP vs API Gateways: Why AI Agents Need Governance

What the gateway is for

An API gateway sits at the perimeter. It authenticates the caller, applies rate limits and routes the request to a service. It was built for north–south traffic: an external client calling an endpoint. It is good at that, and nothing here suggests replacing it. For the protocol-level comparison of MCP and plain APIs, see MCP vs API.

When this post was first written in 2025, the gateways did not understand MCP at all. That has changed; the major vendors have all shipped some form of MCP proxying or exposure. So the question has moved from "can it carry the traffic" to "can it make the decision".

What the gateway sees, and what it does not

When an assistant calls a tool over MCP, the gateway sees an authenticated session and a request to an endpoint. Allow or deny. That is the whole decision space.

What it does not see, because nothing in its model has a place for it:

• The person. The session belongs to an assistant, or to a service account the assistant uses. Which human asked, and which groups they hold in the identity provider, is not part of the request.
• The tool, as distinct from the server. One MCP server exposes many tools. "Read a customer record" and "delete a customer record" arrive at the same endpoint.
• The arguments. "Read this customer's record" and "read every customer record" are the same tool with different inputs. A gateway rate-limits both identically.
• Whether a human should look first. A gateway allows or denies. It has no third state in which a call is held, routed to an approver and released.
• What it cost, and to whom. Rate limits cap volume. They do not attribute spend to the team whose work it was.

What the governance layer sees instead

The layer Palma provides works from the person outward. Each person gets one governed connector, assigned through the groups they already hold in the identity provider, carrying every tool and Skill they are entitled to into whichever assistant they use. Someone in Finance has Finance tools; someone who joins Sales has Sales tools on day one and loses them the day they leave. The identity provider stays the authority; nothing new has to be maintained.

Policy is evaluated on the actual call: this person, this tool, these arguments. Reads can be open where writes need approval; a write to one record can be allowed where a bulk write is held. Calls that need a human are paused, routed to the right approver in Teams or Slack, and resumed once approved. Every call is logged with who, what, when and why, in a form an auditor will accept, and spend is attributed to the team that incurred it.

None of that replaces anything the gateway does. It answers questions the gateway was never asked.

Why "the gateway covers it" feels true at first

It is common to hear: "MCP is just another API. Our gateway covers that." With one MCP server, mostly read-only calls and a handful of users, it does. The gap opens when a second team wants in, when a tool that writes is added, and when the security review asks who is allowed to use which tool and on which records. At that point the gateway's answer is "whoever has a token", and the pilot stalls.

How the two fit together

• Keep the API gateway at the perimeter for north–south traffic.
• Run the governance layer where the agents are: inside your VPC, on-prem, or as a managed service, whichever your data-residency rules require.
• Reuse what you have: the identity provider for who, your secrets store for credentials, your SIEM for the audit log, Teams or Slack for approvals.

A pilot that shows the difference in two weeks

• Pick one team and the two or three systems they actually use.
• Assign the connector by their existing identity-provider group.
• Set a read-only baseline, and allow one write behind approval.
• Hand the security team the audit trail and the cost breakdown at the end.

If your gateway can already produce that trail, per person and per argument, you do not need us. If it cannot, book thirty minutes and bring the list of systems.