Security · ~7 min
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.
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."
| Dimension | Example rule |
|---|---|
| Identity | Non-finance users may not invoke ledger.write |
| Tool name | shell.exec is blocked regardless of arguments |
| Argument inspection | deploy(environment=production) needs a higher approval tier |
| Rate limit | search at most 60/min per session |
| Environment | Callable from staging runners, blocked from laptops |
| Data labels | Block if input is confidential and destination lacks scope |
The plane's whole value is that the decision is independent of model judgment. Microsoft's Agent Governance Toolkit benchmark makes the case quantitatively:
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.
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.
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…