What We Learned Building an MCP Gateway: It's Not a Routing Problem

Most teams treating MCP security as a transport layer problem will build something that looks secure until an agent calls a privileged tool with no auditable identity behind it, no logged intent, and an access control layer that has no opinion about either. We know because we started there too.

The Model Context Protocol solves a real coordination problem - it gives AI agents a standard interface to invoke tools across systems. What it doesn't solve is the identity and access control problem that comes with it. That gap is where we spent most of our engineering time, and it's where most MCP Gateway implementations are quietly underbuilt.

Your Existing IAM Stack Wasn't Built for This

When a human user calls an API, you have a session, a principal, a token with scopes, and usually an audit trail that ties the action back to a person. When an agent calls a tool via MCP, you have none of that by default.

There's no stable principal attached to the tool call. There's no native intent signal. The protocol doesn't carry why the call is being made, only what is being invoked. And there's no inherent sensitivity rating on the tool itself; your gateway doesn't know whether it's about to execute a read against a low-value dataset or trigger a privileged write against a production secrets store.

Your RBAC rules, your session-based policies, your attribute-based controls, all of them were designed around a model where identity is asserted at the front door. MCP tool calls don't come through the front door.

The Three Things You Need to Know at Call Time

After working through this problem in production, we landed on three questions that any meaningful MCP access control layer has to answer before allowing execution:

Who is behind this call? Not just which agent, but what identity is driving it - human, service account, or another agent in a chain. This requires resolving the full identity context behind the tool invocation, not just authenticating the MCP client.

Why is this call being made? Intent isn't something MCP carries natively, so you have to derive it. We do this by analyzing the prompt that triggered the agent and the declared mission of the agent itself. A tool call to query a Snowflake table is routine from an analytics agent running a scheduled report. That same agent issuing a write call to drop or modify a table — against a prompt that never mentioned data changes — is exactly the kind of drift that contextual controls are designed to catch.

How sensitive is the tool being invoked? Not all tools carry the same risk. A read-only lookup is not equivalent to a tool that can modify IAM policies or exfiltrate credentials. Your gateway needs a sensitivity model for tools - not just for the identities calling them.

Miss any one of these three and your controls have a gap. Miss all three and you have an authentication theater.

Where Credentials Actually Break

Tools need credentials to do anything useful - API keys, OAuth tokens, service account secrets. In a naive MCP implementation, those credentials are either hardcoded into the tool definition or injected at runtime by the agent. Both create NHI governance problems.

Hardcoded credentials don't rotate, aren't scoped to the calling context, and are invisible to your secrets management layer. Runtime injection by the agent means your gateway never sees the credential - it only sees the tool call result. Neither model gives you control over what's being used, by whom, or under what conditions.

The right model is gateway-mediated credential injection: the gateway resolves what credential the tool needs, fetches it from a secrets store under the calling identity's entitlements, injects it at call time, and never exposes it to the agent layer. This is also where JIT access becomes meaningful in practice. Rather than maintaining standing credentials per tool, you issue time-bound credentials scoped to the specific invocation context - so a compromised agent session doesn't carry persistent access to anything downstream.

This is one of the places where the NHI problem and the MCP security problem are the same problem. If you don't have a governed view of what non-human identities exist, what credentials they hold, and what they're entitled to access, you can't implement this model. You're back to hoping the agent behaves.

The Real Engineering Problem: Extending Permissions to Tools

Getting authentication working is tractable. The harder problem, and where we spent the most time, was extending our existing permissions model to cover MCP tool calls.

We already had a mature permissions framework built around human and non-human identities: entitlements, access policies, the identity graph that maps relationships between principals and resources. The question was whether we could stretch that model to evaluate tool-level access without rebuilding it from scratch.

The short answer: yes, but it required rethinking what a "resource" means in the context of MCP. A tool isn't a static resource with fixed permissions, it's an action with variable risk depending on the context in which it's invoked and the resources involved. The same tool call can be low-risk in one context and a critical control violation in another.

What we built evaluates all three context signals, identity, intent, tool and resource sensitivity, at call time, against the same policy layer that governs the rest of our identity controls. The MCP Gateway doesn't maintain a separate access control silo; it's an enforcement point within the existing identity graph.

What the Gateway Actually Enforces

When a tool call arrives at the gateway, here's what happens before execution is allowed:

• Identity resolution - The gateway resolves the full principal chain behind the call: which agent, which human or service identity initiated the session, and what entitlements that identity carries.
• Intent evaluation - The originating prompt and the agent's mission are analyzed to establish why this tool is being called. Calls that don't cohere with the agent's declared purpose will get flagged or blocked.
• Tool sensitivity classification - Each tool is mapped to a sensitivity tier. Privileged tools, those that can read credentials, modify policies, or access sensitive data, require stricter contextual justification to execute.
• Contextual policy enforcement - All three signals are evaluated against policy before the call is forwarded. If the identity doesn't have the entitlement, if the intent doesn't match the agent's mission, or if the tool's sensitivity exceeds what the context justifies, the call is denied and logged.

Every decision is audited. Not just whether the call was allowed or denied, but why, which signals were present, which policy rule evaluated, and what the full identity context was at the time.

Routing Is the Easy Part

The teams that frame MCP security as a routing and authentication problem will ship something. It will handle credential injection, it will proxy tool calls, and it will probably produce some logs. What it won't do is enforce meaningful controls on who can call what under which conditions - and in an enterprise environment running agentic workflows at scale, that gap is where your blast radius lives.

We built the gateway we needed because the identity problem behind MCP isn't a future concern. It's in production now, in every organization that's deployed an AI agent with access to real tools.

If you want to see how contextual AI access control works across your MCP environment, request a demo.