Part 5 · The Identity & Supply Surface

Security · ~7 min

The Gateway in the Middle

An agent wired to ten MCP servers inherits ten ad-hoc authorisation models. A control plane collapses them into one policy point that every tool call must pass — and the decision is independent of the model.

Why this, for you: as agents connect to more tools, per-server permission settings sprawl into an unauditable mess. The runtime control plane is the architectural fix — one enforcement point between agent and tool, deterministic, logged, and the same pattern AWS, Microsoft, and Red Hat all ship.

A runtime control plane intercepts every MCP tool call at a single evaluation point — checking identity, tool name, arguments, and rate limits against a central policy — then forwards or denies, logging the decision. AWS Bedrock AgentCore states it plainly: it "intercepts all agent traffic… and evaluates each request against defined policies… before allowing tool access."

1 One evaluation point, six dimensions

DimensionExample rule
IdentityNon-finance users may not invoke ledger.write
Tool nameshell.exec is blocked regardless of arguments
Argument inspectiondeploy(environment=production) needs a higher approval tier
Rate limitsearch at most 60/min per session
EnvironmentCallable from staging runners, blocked from laptops
Data labelsBlock if input is confidential and destination lacks scope
The control plane collapses N per-server authorisation models into one policy evaluation point between agent and tool — expressed in a policy language (Cedar, OPA) and evaluated on every call, before the call reaches the server.

2 Deterministic enforcement beats prompt rules

The plane's whole value is that the decision is independent of model judgment. Microsoft's Agent Governance Toolkit benchmark makes the case quantitatively:

# Policy violation rate vs red-team inputs (Microsoft benchmark) prompt-only controls → 26.67% violation rate deterministic app-layer → 0.00% violation rate

An injected prompt that tells the agent to call a denied tool still hits the policy check and is rejected — because the gate doesn't depend on the model following instructions. This is the same principle as the egress policy in Lesson 5, lifted up to the tool-call layer.

3 The plane only sees what passes through it

Off-protocol actions are invisible to the gateway

The gateway sees MCP traffic only. Shell commands, direct HTTP, DB drivers, and headless browsers are invisible to it — blind spots that look like coverage. Worse, tool-name policies without argument inspection miss injection: a pre-approved shell.exec with unchecked args escalates to RCE. And unless every runtime is wired through the gateway, shadow connectors reach the server unchecked. Partial coverage gives false confidence.

So the control plane is the runtime-governance layer — distinct from network egress policy (lower), the process sandbox (Lesson 10), and MCP transport. It's also a single point of failure: route all calls through one broker and it becomes a target and an outage surface. Pair it with a tool registry, framework-level runtime hooks for off-protocol actions, and argument-level policy. Defense in depth, again — the plane is one layer.

↪ Your win: one gate every tool call must pass

Retrieval practice — recall, don't peek

Question 1A runtime control plane's core job is to…

Question 2In Microsoft's benchmark, prompt-only controls vs deterministic enforcement showed…

Question 3Why does an injected prompt fail to bypass the control plane?

Question 4A key blind spot of the gateway is that it cannot see…

Question 5 · spaced recall from Lesson 10For untrusted code on a multi-tenant host, the right family is…

Ask me anything. Want to draft a Cedar or OPA policy for an agent's tool surface, or map which of your tool calls travel off-protocol and escape the plane? Next in Part 5: Keys That Expire in Minutes — replacing static API keys with short-lived federated tokens.
✎ Feedback