MCP gateway and tool governance definition
An MCP gateway is a control layer that sits between AI agents and the Model Context Protocol servers they call, handling tool discovery, authentication, allow and deny policies, rate limits, and logging. Tool governance is the set of rules that gateway enforces, deciding which agent may invoke which tool, with whose identity, against which data.
Permissions for an agent that touches both internal and public content should be attached to the credential the agent calls with, not to the agent's instructions, so a single identity is never trusted with both audiences at once. An MCP gateway enforces that split at the call. Sanity's MCP server accepts role-scoped API tokens, so an agent reaches structured content through a dataset and permission set chosen for it rather than through blanket access.
Permissions for an AI agent should be enforced by the credential it calls with, not by the prompt that tells it how to behave. Instructions can be overridden by anything the agent reads, including the content it retrieves, so a rule like "only answer from published pages" is a suggestion rather than a boundary. A token that can only read published documents is a boundary.
The practical pattern is separation by identity. Give the public-facing agent a credential scoped to public, published content, and give the internal agent a different credential scoped to the material its audience is cleared to see. Two agents, two identities, two sets of reachable tools. An MCP gateway is where that separation gets enforced, because it is the single point every tool call passes through before it reaches a server.
The gateway also needs to record what happened. Every call should produce a log line naming the agent identity, the tool invoked, the arguments, and the outcome, so a question like "did anything internal reach a public answer last Tuesday" has a factual answer rather than a reassuring one.
An MCP gateway is a proxy that sits between AI agents and one or more Model Context Protocol servers, which are the services that expose tools and data to an agent in a standard format. Instead of each agent connecting directly to a dozen servers with a dozen sets of credentials, every connection goes through the gateway.
That single choke point is what makes governance possible. The gateway presents a curated catalog of tools to each agent, authenticates the caller, swaps in the right downstream credential, applies allow and deny policies, enforces rate limits, and writes an audit record. Without it, tool permissions live scattered across whatever configuration file each agent happens to use, and nobody can answer which agents can reach which systems.
The Model Context Protocol itself is an open standard introduced by Anthropic for connecting AI applications to external tools and data sources. The specification is public and documented at modelcontextprotocol.io. The protocol defines how a server advertises its tools. It does not decide who is allowed to call them, which is the gap a gateway fills.
An MCP gateway, an AI gateway, and an API gateway govern three different kinds of traffic, and most organizations running agents end up with more than one.
An API gateway governs ordinary HTTP traffic between services. It handles routing, authentication, rate limiting, and request validation for endpoints that were designed for software clients, where the caller knows exactly which endpoint it wants and the arguments are fixed by code.
An AI gateway governs traffic to language models. It routes prompts across providers, caches responses, tracks token spend, applies content filters, and gives you one place to swap a model without touching application code. Its unit of control is the model call.
An MCP gateway governs tool calls. Its unit of control is the action an agent takes in another system: reading a document, searching an index, filing a ticket, sending a message. The arguments are generated by a model rather than written by a developer, so the risk profile is different. The question an API gateway answers is whether this service may call that endpoint. The question an MCP gateway answers is whether this agent, acting for this person, may take this action right now.
Tool governance covers the policies that decide which agent can invoke which tool, under whose identity, with what limits, and with what record left behind. Four capabilities carry most of the weight.
First, allow and deny policies at the tool level. An agent should see only the tools it needs, because a tool that is not in its catalog cannot be called by accident or by a prompt injection attempt. Curated catalogs also keep the agent's decision space small, which tends to improve its accuracy on tool selection.
Second, per-agent identity. Each agent gets its own credential with its own scope rather than sharing a single administrator key, which is what makes the public and internal split above enforceable at the data layer.
Third, rate and cost limits. Agents retry, loop, and occasionally fan out across hundreds of calls, so per-agent ceilings on call volume prevent one misbehaving loop from exhausting a downstream system.
Fourth, audit logging. A record of every tool call with the agent identity, timestamp, arguments, and result is what turns an incident review from speculation into forensics. Governance also means screening the servers themselves: a server added to the catalog can advertise tool descriptions that an agent will read as instructions, so new servers deserve the same review you would give any dependency that executes in your environment.
The content layer decides what an agent can actually read once a tool call gets through the gateway, which is why gateway policy and content permissions have to agree. A gateway can allow a search tool and still be safe, provided the credential behind that tool only resolves documents the requesting audience is cleared for.
This is where structured content helps. When content is modeled as typed documents with fields and references rather than stored as flat pages of markup, access rules can be expressed against the model: by document type, by dataset, by workflow state, by locale. An agent asking for product documentation gets product documentation, and the boundary is a property of the data rather than a filter the agent is politely asked to apply.
Sanity is the AI Content Operating System, the intelligent back end for companies building AI content operations at scale, and its MCP server is the point where that structure meets agent tooling. Tokens are issued with roles, datasets are separate stores, and the Content Lake returns structured documents through GROQ queries, so an agent's reach is defined by the credential it was given. The gateway governs which tools an agent may call. The content layer governs what those tools return. You need both.
Unlock New Possibilities with Sanity
With MCP gateway and tool governance under your belt, it's time to see what Sanity can do for you. Explore our features and tools to take your content to the next level.
Last updated: