Microsoft published an architecture proposal for securing the Model Context Protocol — the open standard that a growing number of AI agent frameworks use to discover and invoke tools. The core problem: MCP standardizes how agents call databases, APIs, and file systems, but says nothing about who gets to call what, when, or under what constraints.
What happened
MCP gives agents a uniform interface to external capabilities — a common protocol layer for AI tool integration. The protocol itself has no built-in authentication, authorization, rate limiting, or audit logging. Every MCP server implementer is left to roll their own security — or skip it.
Microsoft’s proposal introduces a control plane layer that sits between the AI agent and MCP tool servers. Rather than letting agents call tools directly, the control plane intercepts every tool invocation and enforces policies: identity verification, scoped permissions, input validation, rate limits, and full audit trails. The architecture draws from patterns already proven in API gateway and service mesh designs, applied specifically to the agent-tool boundary.
WARNING
MCP currently has no spec-level mechanism for authentication or authorization. Any MCP server exposed to an agent today relies entirely on whatever security the server author chose to implement. Before deploying any MCP server in a sensitive environment, review its source code for access controls — do not assume they exist.
Why it matters
Agents operating through MCP can chain multiple tool calls autonomously. A single prompt can trigger a database query, a file write, and an API call to a third-party service — all without human review of each step. Without a governance layer, a prompt injection or misconfigured agent can exfiltrate data, modify production systems, or rack up API costs with no audit trail.
Microsoft’s control plane concept addresses this with five specific capabilities:
| Capability | What it does | Risk it mitigates |
|---|---|---|
| Identity & authentication | Ties every tool call to a verified identity (user, agent, or service principal) | Unauthorized access to tools |
| Scoped authorization | Enforces least-privilege; e.g., a coding agent can read a repo but not delete branches | Privilege escalation, lateral movement |
| Input/output validation | Checks tool arguments and responses against schemas before execution | Prompt injection, malformed payloads |
| Rate limiting & quotas | Caps call frequency and resource consumption per identity | Runaway agents, cost overruns |
| Audit logging | Records every tool invocation with full context | Compliance gaps, post-incident forensics |
The proposal frames these patterns as applicable to Microsoft’s own agent infrastructure, though the blog post focuses on the architectural pattern rather than announcing specific product features.
TIP
If you’re building or deploying MCP servers today, treat them like internal APIs: put them behind authentication, restrict network access, validate inputs, and log every call. Don’t wait for the spec to mandate it.
Who should care
Platform engineers integrating MCP servers into agent workflows — especially in environments with access to production databases, customer data, or paid APIs. Security teams evaluating agent deployments. Anyone building multi-agent systems where one agent can invoke tools on behalf of another.
If you’re running MCP servers on localhost for personal use, the risk profile is lower. But the moment an MCP server is network-accessible or handles sensitive data, the absence of a control plane is a real exposure.
NOTE
This proposal is an architectural reference, not a shipped product or an update to the MCP specification itself. It describes patterns that can be implemented independently of Microsoft’s stack using existing infrastructure tooling.
Practical takeaway
Start by auditing your current MCP server deployments. Catalog which tools are exposed, what data they can access, and whether any authentication exists between the agent and the server. Microsoft’s architecture gives you a concrete reference design — even if you’re not on Azure, the pattern of intercepting tool calls through a policy-enforcing proxy is implementable with existing API gateway tools like Envoy or Kong. The control plane pattern closes the gap between a working MCP integration and one that is safe to operate in production.