Agent Governance Foundation

MCP Needs an Authorization Layer, Too

Agent Governance Foundation
mcpauthorizationarchitecturegateway

The Model Context Protocol gives agents a standard way to discover tools from an MCP server and invoke them. That's genuinely useful — it's the same interoperability problem USB-C solved for chargers, applied to tool discovery. An agent that speaks MCP can call tools from any MCP server without bespoke integration code per tool.

What MCP doesn't standardize is the question every framework integration we've written about eventually runs into: should this specific agent be allowed to call this specific tool, right now, given its current trust level and context?

That's not a protocol gap MCP needs to fix — tool discovery and authorization are different concerns, and conflating them would make MCP servers responsible for policy logic that belongs elsewhere. But it does mean MCP deployments inherit exactly the same problem we described for LangChain, CrewAI, and AutoGen: a tool being discoverable and callable is not the same as a tool being authorized.

Where the gap shows up

An MCP server exposes a set of tools to any client that connects to it. In the patterns we've seen so far:

  • The server itself has no concept of which agent is calling, beyond whatever the transport layer happens to carry.
  • There's no standard place to ask "is this call, from this agent, in this context, allowed?" before the tool executes.
  • If the server does add access control, it tends to be static — API-key-scoped or server-wide — not the kind of per-agent, per-action, context-aware decision that agent authorization requires.

That's the same shape of problem API keys had for agents in general, which is what got us started on this in the first place — see why agents need their own identity infrastructure.

How the Gateway works

Unlike LangChain, CrewAI, and AutoGen — where the authorization gate is a line of Python you add to your agent code — MCP authorization doesn't need to touch your agent at all. You register your downstream MCP server with AGF once, and the MCP Gateway sits in front of it, intercepting traffic at the protocol level:

  1. You point AGF at your MCP server (target_url) and register the audience your delegation tokens should carry. AGF gives you back a gateway URL.
  2. Your agent (or whatever's routing MCP traffic) calls that gateway URL instead of the MCP server directly.
  3. On every tools/call and resources/read — the two methods most likely to have side effects or expose data — the Gateway resolves the calling agent's identity, runs the same three-signal decision (policy, trust score, risk) every other AGF integration uses, and produces a signed decision artifact either way.
  4. Only on ALLOW does the original request get forwarded to your MCP server, byte-for-byte. Everything else — initialize, tools/list, resources/list, and other read-only discovery methods — passes straight through once your credentials check out, since those don't act on anything.

A blocked call never reaches your MCP server. It comes back as a standard JSON-RPC error, so any MCP client already knows how to handle it without new code on your side.

Where we are today

The MCP Gateway is live. Registration, the proxy route, and full decision-artifact parity with /v1/decide are shipped — see the MCP Gateway integration guide for the exact request shapes.

One thing still ahead of us: delegation chains travel over a stopgap header (X-AGF-Chain) today rather than a protocol-native field, since MCP itself has no standard place to carry one. That'll collapse into a cleaner mechanism once OAuth 2.1 support for MCP servers ships. If that gap matters for your deployment today, get in touch.

Related

All posts