--- title: How MCP works, and why gateways aren't enough description: API gateways and MCP gateways both govern calls. Neither decides what an agent attempts or who the agent is. How MCP works, and where to govern it. image: https://www.cloudorizon.com/hubfs/Blog%20Header%20-%20Agent%20Governance%20Pt1-selection-2.png --- [Skip to content](https://www.cloudorizon.com/insights/how-mcp-works-and-why-gateways-arent-enough#main-content) [![logo-old](https://www.cloudorizon.com/hs-fs/hubfs/logo-old.png?width=583&height=110&name=logo-old.png "logo-old")](https://cloudorizon.com) - [Home](https://www.cloudorizon.com) - [Solutions](https://www.cloudorizon.com/solutions-at-cloudorizon) - [About](https://www.cloudorizon.com/about-cloudorizon) - [Case Studies](https://www.cloudorizon.com/case-studies-cloudorizon) - [Insights](https://www.cloudorizon.com/insights) - [Contact](https://www.cloudorizon.com/book-a-meeting-with-us) - [ROI](https://calc.cloudorizon.com/) - [Workato](https://www.cloudorizon.com/insights/tag/workato), - [SAP](https://www.cloudorizon.com/insights/tag/sap), - [AI](https://www.cloudorizon.com/insights/tag/ai), - [MCP](https://www.cloudorizon.com/insights/tag/mcp) # How MCP works, and why gateways aren't enough - November 12, 2026 ![Lee Cunningham](https://www.cloudorizon.com/hubfs/Lee-Cunningham-Cloudorizon.jpg) [Lee Cunningham](https://www.cloudorizon.com/insights/author/lee-cunningham) *Part one of the series that follows [Every vendor needs an API policy. Not every architecture is fit for one.](https://www.cloudorizon.com/insights/every-vendor-needs-an-api-policy.-not-every-architecture-is-fit-for-one)* #### When agents start calling business systems, the first answer most architects reach for is the one they already have: put a gateway in front of the APIs and tighten the scopes. The controls that answer gives you are necessary. The gateway itself is optional, and the controls are not enough. When I planned this post, the gateway in question was the API gateway. Since July, MCP gateways have become just as relevant, so it covers both. It starts with what MCP actually does, because most governance arguments about it start from a misreading. **![Illustration: a gateway sees the call, not the decision](https://www.cloudorizon.com/hs-fs/hubfs/Blog%20Header%20-%20Agent%20Governance%20Pt1-selection-2.png?width=936&height=523&name=Blog%20Header%20-%20Agent%20Governance%20Pt1-selection-2.png)**   ### **How MCP works** The Model Context Protocol (MCP) standardises how an AI application reaches tools, and through them the systems behind them: business applications, data and integration flows. Anthropic published it in November 2024 and handed it to the Agentic AI Foundation, under the Linux Foundation, in December 2025. It has three roles. The **host** is the application the user works in: Copilot Studio, Claude, an IDE, an enterprise app. It holds the model. The **client** sits inside the host and keeps a connection to one server. The **server** exposes tools, each a named operation with a description and an input schema, and turns tool calls into calls on whatever sits behind it: an API, a database, an integration flow. The sequence is the part that matters. The host shows the model the list of tools. The model decides which one to call and with what arguments. The client sends that request to the server. The server executes it and returns the result to the model, which decides what to do next. **![Diagram of the MCP flow: the host shows the model its tools, the model chooses one, the client sends the request to the server, and the server calls the system behind it](https://www.cloudorizon.com/hubfs/How%20MCP%20works%20(API%20policy%20series%2c%20post%201)-1.svg)** So the model chooses and the server acts. The model never touches your systems. It produces a structured request, and something deterministic carries it out. Every control you can put on an agent sits somewhere along that path. ### **Two gateways** There are now two places to put a gateway, and it helps to keep them apart. **The API gateway** sits in front of a system's APIs. Most estates already have one, as a product or inside their integration platform. It knows who is calling, how often and with which scopes, and it logs each call. It sees API calls. It has no idea a model chose them. **The MCP gateway** sits one step earlier, in front of the MCP servers. MCP has never defined one; its roles are host, client and server. Vendors built MCP gateways anyway through 2025, but the protocol worked against them: sessions pinned every request to one server instance, and a gateway had to open each message to see what was being called. The [28th July 2026 revision](https://blog.modelcontextprotocol.io/posts/2026-07-28/) changed that. It is the first designed with the gateway in mind. The protocol is now stateless, so any instance can answer any request. Each request names the method and the tool in HTTP headers, so a gateway can route, meter and authorise per tool without reading the body. Requests can carry standard trace context, so one call can be followed across gateways. Authorisation has been hardened, and enterprise-managed authorisation, which lets a company's identity provider decide which MCP servers its people can reach, is now a formal extension. The platform vendors moved at the same time: SAP's MCP Gateway went live in July, and Workato's is the same shape. That is why the question of whose gateway sits in the middle became urgent this autumn rather than last year. Two cautions. State has not gone away: a server that needs it now mints a handle that the model passes back as an argument, and that handle should be treated like any other credential: scoped, short-lived and revocable. And the protocol changed in breaking ways less than two years after launch, and will change again. Whatever you build your controls on should not move at someone else's pace. That is the second of the three tests in the overview: your pace of change should not be tied to a vendor's roadmap. You do not need to buy both gateways as products. An integration platform that exposes MCP tools applies the same controls itself. What matters is that the controls exist, not which box holds them. ### **Four places to govern** Read the flow and there are four places to exercise control. 1. **Who the call runs as.** Whose authority the call carries, usually a person who has delegated to the agent. 2. **Who the agent is.** Which configured agent, with which instructions and which model, made the request. 3. **What the model can see.** The tool catalogue. If a tool is not listed, the model cannot ask for it. 4. **What happens downstream.** What the server may do against the system behind it: scope, limits, validation, audit. **![Diagram of the four places to govern an agent’s calls: who the call runs as, who the agent is, what the model can see, and what happens downstream](https://www.cloudorizon.com/hubfs/Four%20places%20to%20govern%20v2%20(API%20policy%20series%2c%20post%201).svg)** Both gateways are strong on the first and the fourth. The second is an identity decision and the third is a design decision. A gateway can enforce both; it cannot make either. ### **What people reach for, and what it misses** Asked how to govern agents, teams reach for one of these. Each answers part of the question. - **An API gateway** answers who is calling, how often and with which scopes. It does not see the sequence the model chose. - **Tighter scopes** answer what a token can touch. They do not answer which tools the agent should see for this job. - **A service account per agent** separates the agent's calls. But it is a standing credential, and the person the agent acts for drops out of the record. - **An MCP gateway** adds per-tool policy, one sign-in and one record across every server. It still sees the person and the application, not the agent, and it still does not choose. - **An integration platform in front of the APIs** applies the same controls and goes further: the agent sees only tools composed at design time, never raw APIs. It still sees the person, not the agent, and it only works if nothing can go round it. Without these controls you have the three gaps behind most of the incidents in the overview: long-lived credentials, no bound on what can be called, and nothing in the record to show that an agent acted. With them, you have governed the calls. The trouble is that the risk is in the choosing. ### **A worked example** Recently I asked my assistant to find a meeting in Granola, the note-taking tool I use. It is a small, ordinary case, and every stage is there. Before I asked, the assistant's client had already fetched Granola's tool catalogue: search meetings, read meetings, read transcripts, and several tools that write. I asked. The model decided to search today's meetings and produced the call. The client sent it to Granola's server with the authority I granted when I connected Granola. Granola ran the search and sent back six meetings. The model read them, decided to open two, then the transcript of one: three round trips, each a separate decision. Then it answered. Granola knew it was me, and applied my access. It knew the calls came from my assistant. It did not know which conversation, or what instructions the assistant was working under. The catalogue it offered included write tools I did not need; the model's judgement and the app's permission prompts were all that stood between a read and a write. And Granola's results carried instructions to the model about how to use its tools: harmless here, but the same channel a hidden instruction would use. Now put an MCP gateway in the middle. SAP and Workato both sell one, and so do others. The assistant connects to the gateway rather than to Granola, and the gateway connects onwards. What it adds: - **One sign-in and one kill switch.** My company's identity provider signs me in. Remove me there and I lose every server at once, not one connection at a time. - **A catalogue the organisation decides.** An administrator chooses which of Granola's tools are offered, and to whom. The write tools need not be there at all. - **One record.** Every call to every server is limited and logged in the same place, under the same policies. What it does not add: the gateway still sees me and the application, not the agent. And the model still decides. Had an instruction hidden in a transcript steered it towards a tool that was exposed, the gateway would have seen an authenticated, well-formed call from me, and passed it. When you need one: not for one person and one server. You need it when there are hundreds of people, several assistants and dozens of servers, some bought and some built, each otherwise governed by whatever its vendor built and none of them visible as a whole. A gateway is an estate control, not a per-call one. And whichever gateway you choose becomes your control plane, so that choice is worth making on purpose. Gateways of either kind are necessary. They are not sufficient, for two reasons. ### **Reason one: a gateway sees the call, not the decision** The model's choice is the unpredictable step. A gateway can check that a call is allowed; it cannot tell whether it should have been made. An agent steered by an instruction hidden in a document, or one that simply reasons its way to the wrong action, makes calls that are authenticated, well formed and within limits. Every control on the path reads them as legitimate, because mechanically they are. That is the confused deputy. It is why [NIST's design tenets for agent identity](https://www.nist.gov/blogs/cybersecurity-insights/design-tenets-agent-identity-management-systems), published on 27 October, ask for the logic that decides what an agent attempts to be architecturally separate from the systems that decide what it is allowed to do, with access decisions resting on deterministic checks. In NIST's words, guardrails alone are insufficient. The practical answer sits in the third place to govern: what you put in the catalogue. Expose raw transactional APIs and the model composes the sequence at runtime, and a gateway can only police each step. Expose composed tools, where the sequence was designed, tested and owned before any agent saw it, and the model can only choose among actions someone has already decided are safe. How far to go depends on the blast radius. Read-only lookups can stay granular, with monitoring; anything that changes a system of record should be composed. That was the subject of [Who decided what your AI agents can do?](https://www.cloudorizon.com/insights/who-decided-what-your-ai-agents-can-do) in September. A gateway enforces the catalogue. It does not write it. ### **Reason two: the protocol knows the user and the app, not the agent** MCP's authorisation identifies two parties: the person whose authority the call carries, and the client application making it. The [enterprise extension](https://py.sdk.modelcontextprotocol.io/client/identity-assertion/) shows this clearly. The assertion a company's identity provider issues is short-lived and signed, and it names one user, one client and one target. The [draft standard behind it](https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-05.txt) allows an actor to be named as well; MCP's documented flow does not require one. What is missing is the agent as a principal in its own right. An agent is a model, a set of instructions, a set of tools and an owner. Change one of those and you arguably have a different agent, which is why NIST's first tenet ties an agent's identity, ideally, to a specific workload, environment and approved configuration. None of it is in the protocol. So a gateway, of either kind, can tell you which person and which application. It cannot tell you which agent decided, and you cannot revoke one agent without revoking the person or the application. The obvious workaround is to register each agent as its own OAuth client, so the client ID stands in for the agent. Plenty of teams do. But that client has to be registered with every vendor's authorisation server it calls. One agent and four vendors means four registrations; fifty agents means two hundred. It moves the problem rather than solving it. NIST is clear that agents need an identity, credential and access lifecycle distinct from the people they act for. What no standard yet settles is where that identity is held. That question, who keeps the register, is being answered by default, vendor by vendor. SAP's answer is its own identity service, and that is where the next post starts. ### **What to do with this** - Put gateway controls in front of every API and every MCP server that can reach a system of record. You do not need a separate product if your integration platform already applies them. - Decide the catalogue at design time, give it a named owner, and prefer composed tools over raw transactional APIs for anything that changes data. - Give every agent an identity of its own, defined somewhere you control, and make sure your audit record can name both the person and the agent for every call. - Ask each vendor, your integration platform included, where your agents' identities are expected to live. **In an SAP estate** The same four places apply, with SAP's names on them. - **The gateways** are API Management in SAP Integration Suite, in front of the APIs, and the MCP Gateway in Integration Suite, in front of the tools. SAP plans an Enterprise AI Gateway on Integration Suite, covering APIs, models, MCP and agent-to-agent traffic, for early 2027. - **Who the call runs as** is the user, signed in through SAP Cloud Identity Services, federated with your own identity provider. - **Who the agent is** is the same gap. [SAP's reference architecture for its own gateway](https://architecture.learning.sap.com/docs/ref-arch/d2e34e) documents the user only. For an MCP server you run yourself, [SAP's guidance](https://architecture.learning.sap.com/docs/ref-arch/137800) requires the agent to be registered in Cloud Identity Services. Same job, different bar: that is the next post. - **What the model can see** is SAP's published APIs and integration flows exposed as tools, plus SAP-provided MCP servers built in Joule Studio. [SAP's API Policy](https://help.sap.com/doc/sap-api-policy/latest/en-US/API_Policy_latest.pdf) allows only published APIs. - **What happens downstream** is governed by SAP's API limits and by Section 2.2.2 of the policy, which allows agentic use only through SAP's endorsed routes or under its conditions. **Next in the series:** Same job, different bar, on SAP's endorsed and permitted routes side by side. *Disclosure: Cloudorizon is an enterprise architecture company specialising in SAP Integration Suite and third-party integration platforms. Where this is my reading rather than a source's words, I have said so.* Blog Post ## Related Articles ### Check out our Insights into all things Workato, SAP and AI These articles will give you a flavour for our approach to making you the best you can be in terms of Integration and Automation. [![](https://www.cloudorizon.com/hubfs/Blog%20Header%20-%20Ones%20You%20Cant%20See-selection.png)](https://www.cloudorizon.com/insights/before-you-scale-ai-agents-govern-the-ones-you-cant-see) [Integration](https://www.cloudorizon.com/insights/tag/integration), [Governance](https://www.cloudorizon.com/insights/tag/governance), [AI](https://www.cloudorizon.com/insights/tag/ai) ### [Before you scale AI agents, govern the ones you can’t see](https://www.cloudorizon.com/insights/before-you-scale-ai-agents-govern-the-ones-you-cant-see) August 4, 2026 Every AI agent is a non-human identity acting on your behalf. Give it the keys before you've decided what it's allowed... [Read more](https://www.cloudorizon.com/insights/before-you-scale-ai-agents-govern-the-ones-you-cant-see) [![](https://www.cloudorizon.com/hubfs/Blog%20Header%20-%20Two%20States-selection.png)](https://www.cloudorizon.com/insights/who-decided-what-your-ai-agents-can-do) [Enterprise Architecture](https://www.cloudorizon.com/insights/tag/enterprise-architecture), [Integration](https://www.cloudorizon.com/insights/tag/integration), [Workato](https://www.cloudorizon.com/insights/tag/workato), [Governance](https://www.cloudorizon.com/insights/tag/governance), [MCP](https://www.cloudorizon.com/insights/tag/mcp) ### [Who decided what your AI agents can do?](https://www.cloudorizon.com/insights/who-decided-what-your-ai-agents-can-do) September 18, 2026 MCP is the easy part. The decision that matters is who gets to say which tools your agents can use, and whether anyone... [Read more](https://www.cloudorizon.com/insights/who-decided-what-your-ai-agents-can-do) [![](https://www.cloudorizon.com/hubfs/Blog%20Header%20Alternatives%20-%20SAP-selection.png)](https://www.cloudorizon.com/insights/sap-without-the-spaghetti) [Enterprise Architecture](https://www.cloudorizon.com/insights/tag/enterprise-architecture), [Integration](https://www.cloudorizon.com/insights/tag/integration), [Workato](https://www.cloudorizon.com/insights/tag/workato), [SAP](https://www.cloudorizon.com/insights/tag/sap) ### [SAP without the spaghetti](https://www.cloudorizon.com/insights/sap-without-the-spaghetti) August 4, 2026 When to reach for Workato, when to reach for SAP BTP, and how to stop your SAP core becoming an island, or a knot. SAP... [Read more](https://www.cloudorizon.com/insights/sap-without-the-spaghetti) [Check all articles](https://www.cloudorizon.com/insights) Blog Post CTA ### H2 Heading Module Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. GET STARTED Subscribe for ### Our Blog Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. [![logo-old](https://www.cloudorizon.com/hs-fs/hubfs/logo-old.png?width=292&height=55&name=logo-old.png "logo-old")](https://cloudorizon.com) #### We move money from maintenance to momentum and prove it with a real result in production A Workato and SAP integration partner focused on one thing: turning integration from your biggest bottleneck into a capability your team owns. > ##### [Click here to start a conversation with our team.](https://www.cloudorizon.com/book-a-meeting-with-us)   ### Pages - [Home](https://www.cloudorizon.com) - [Solutions](https://www.cloudorizon.com/solutions-at-cloudorizon) - [Case Studies](https://www.cloudorizon.com/case-studies-cloudorizon) - [About](https://www.cloudorizon.com/about-cloudorizon) - [Resources](https://www.cloudorizon.com/resources) - [Insights](https://www.cloudorizon.com/insights) - [Contact](https://www.cloudorizon.com/book-a-meeting-with-us) #### Insights - [The Four Decisions That Decide Your ESB Migration](https://www.cloudorizon.com/insights/the-four-decisions-that-decide-your-esb-migration) - [Stop Paying to Keep the Lights On](https://www.cloudorizon.com/insights/stop-paying-to-keep-the-lights-on) - [You Bought the Platform. Why Isn't It Delivering?](https://www.cloudorizon.com/insights/you-bought-the-platform.-why-isnt-it-delivering) - [It's Not a Moving Job. It's a Design Job](https://www.cloudorizon.com/insights/its-not-a-moving-job.-its-a-design-job) - [Onshore, Offshore, Hybrid - Choosing Without Trading Away Security](https://www.cloudorizon.com/insights/onshore-offshore-hybrid-choosing-without-trading-away-security) - [Before You Scale AI Agents, Govern the Ones You Can't See](https://www.cloudorizon.com/insights/before-you-scale-ai-agents-govern-the-ones-you-cant-see) - [SAP Without the Spaghetti](https://www.cloudorizon.com/insights/sap-without-the-spaghetti) #### Links - [SAP](https://www.sap.com) - [Workato](https://www.workato.com) - [Workato Documentation](https://docs.workato.com) - [Workato Academy](https://academy.workato.com) - [Resources](https://www.cloudorizon.com/resources) --- - [Terms and Services](https://www.cloudorizon.com/terms-and-conditions) - [Privacy Policy](https://www.cloudorizon.com/privacy-policy) Connect Online [Follow us on LinkedIn](https://www.linkedin.com/company/cloudorizon) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Lee Cunningham", "url" : "https://www.cloudorizon.com/insights/author/lee-cunningham" }, "dateModified" : "2026-11-12T11:54:34.871Z", "datePublished" : "2026-11-12T10:24:30.000Z", "headline" : "How MCP works, and why gateways aren't enough", "image" : [ "https://www.cloudorizon.com/hubfs/Blog%20Header%20-%20Agent%20Governance%20Pt1-selection-2.png" ], "mainEntityOfPage" : { "@id" : "https://www.cloudorizon.com/insights/how-mcp-works-and-why-gateways-arent-enough", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject" }, "name" : "Cloudorizon" } } ```