Every MCP session is a chain of trust decisions that most teams never audit. An agent discovers a server, ingests its tool descriptions, attaches credentials, adds conversation context, and starts firing requests. Each step in that chain, from metadata to identity to content to code, introduces a distinct category of risk. Microsoft’s CISO team and Microsoft Digital published their internal framework for governing that chain in February 2026, and it reads less like a security whitepaper and more like an operations manual. Here is what is worth copying.
The Conversation Graph Problem
Most MCP security discussions focus on individual vulnerabilities: a CVE here, a tool poisoning attack there. Microsoft frames the problem differently. They treat every MCP session as a conversation graph where each node (server discovery, tool description ingestion, credential attachment, request execution) is a potential failure point that compounds with the others.
A rogue tool description does not just affect one request. It shapes every subsequent decision the agent makes in that session. A credential that is too broadly scoped does not just risk the current operation. It opens lateral movement across every server the agent connects to afterward. The conversation graph framing matters because it forces you to reason about risk across the entire session lifecycle, not just at individual tool calls.
This is why Microsoft’s approach is organized around layers, not checklists. A checklist misses the interaction effects. Four layers, applied at every stage of the conversation graph, catch failures that no single control would.
Microsoft’s Four-Layer Defense Model
Microsoft organizes MCP security governance into four layers, each targeting a different failure domain. This is not theoretical. It maps to their actual internal deployment for Microsoft 365 Copilot agents.
Layer 1: Applications and Agents
The human-facing edge where agents, clients, and decision logic live. The primary failure modes here are tool poisoning, silent metadata swaps, and missing consent gates.
Microsoft’s controls: client-side consent validation before any write operation, verified tool contracts checked at connection time, per-tool allowlists, and “ask-before-write” UX defaults. The system also runs liveness checks that compare live tool metadata against the approved contract. If a tool’s description changes after approval, the system pauses it.
That last part is critical. Tool poisoning attacks work by modifying a tool’s metadata after initial vetting. Microsoft’s liveness checks catch exactly this scenario.
Layer 2: AI Platform
The model runtime, orchestration logic, and everything between user intent and tool invocation. Failure modes include model supply-chain drift and prompt injection from tool responses.
Controls: version tracking tied to behavioral telemetry, content safety shields applied at runtime (not just during testing), and automated rollback when behavioral drift is detected. If a model update causes agents to select tools differently than expected, the system rolls back before the change reaches production.
Layer 3: Data
Files, business data, and secrets accessible during a conversation. The two big failure modes are context oversharing (sending unnecessary sensitive data to third-party servers) and over-scoped credentials enabling lateral movement.
Controls: context trimming to task-required information only, blocking full transcript transmission to external servers, short-lived least-privilege tokens with correct audience claims, and token proof-of-possession binding where feasible. The principle is simple: the agent sees only what it needs for the current task, holds credentials only for the duration it needs them, and those credentials work only against the specific service they are scoped to.
Layer 4: Infrastructure
Compute, network, and runtime environments hosting MCP servers and clients. Failure modes: local developer servers with excessive access, cloud endpoints running without gateways, missing TLS, absent rate limits.
Controls: all remote MCP servers must sit behind an API gateway. That gateway enforces TLS/mTLS, authenticates requests, applies rate limits, logs everything, and pins egress to approved destinations using private endpoints and firewall rules. No MCP server talks to the internet directly.
Three Pillars: Architecture, Vetting, and Inventory
The four layers describe what to protect. Microsoft’s three pillars describe how.
Pillar 1: Secure-by-Default Architecture
Every MCP server routes through a centralized API gateway. Not “should route.” Routes. The gateway is the single enforcement point for authentication, authorization, rate limiting, logging, and egress control. This creates one choke point where you can apply controls and, when needed, flip kill switches.
The defaults matter here. TLS is required. Tokens are short-lived. Tool allowlists are enforced. If you want to deviate from a secure default, you need an explicit exception with a documented owner. This inverts the typical pattern where developers start permissive and tighten later.
Pillar 2: Staged Vetting
No MCP server reaches production without passing a staged certification process. It starts with mandatory metadata declaration: the server must document its tools, data categories, authentication methods, runtime environment, and on-call contacts. Then come static checks (manifest verification, SBOM presence, embedded credential detection), followed by dynamic testing (prompt injection probing, consent gating validation for operations with side effects), and resilience validation (health checks, pinned host verification, container isolation testing).
Publication is gated on security, privacy, and responsible-AI reviews. Three separate teams sign off. This is heavy, and that is the point: the cost of vetting is paid once per server, while the cost of a breach compounds across every agent session.
Pillar 3: Living Inventory
Microsoft maintains a single registry for all MCP servers, with required metadata per entry: owner, exposure score, last-seen timestamp, review history. The registry is not a static spreadsheet. It pulls telemetry from endpoints, repos, CI pipelines, IDEs, gateways, and low-code environments.
When the system detects an MCP server that is not in the registry, it automatically creates a registration stub and blocks direct calls until vetting completes. This is how you prevent shadow MCP: servers that individual developers or teams spin up without going through governance.
The registry also monitors for drift. If a server’s tool metadata changes after approval, high-risk actions are paused and routed for re-review, then auto-resumed once approved. This catches both malicious modifications and accidental regressions.
Building Governance Into the Developer Flow
One pattern from Microsoft’s approach that other enterprises can copy immediately: governance differs by development surface.
Low-code surfaces (Copilot Studio and similar tools) are restricted to vetted first-party MCP servers by default. Makers cannot connect to arbitrary third-party servers. This is the right tradeoff for citizen developers who may not understand the security implications of an MCP connection.
Pro-code flows (VS Code, custom agent environments) allow broader connector access but require explicit reviews, service ownership, security and privacy assessments, responsible-AI sign-offs, and consent gating for high-impact actions.
The approved servers live in a single catalog with documented owners, scopes, and data boundaries. Runtime metadata comparisons pause risky actions when a tool’s behavior drifts from its approved specification.
This two-tier model solves a problem that most MCP governance frameworks ignore: you cannot apply the same friction to a citizen developer building a Copilot action and a platform engineer building a custom agent pipeline. The controls should match the risk level, which means matching the developer’s ability to evaluate that risk.
Observe, Detect, Respond: Running MCP as a Live Service
Microsoft’s framework does not stop at deployment. The operational model treats MCP like any other critical backend service, with the addition of AI-specific monitoring.
Observe: End-to-end tool call tracing using correlation IDs that follow requests from client to gateway to server and back. Consistent log schemas capture prompts, tool selections, auth decisions, and resource access. Metrics are augmented with safety signals like unexpected egress patterns and unconsented edits.
Detect: Flag unusual tool selection patterns, write operation spikes, and context sizes inconsistent with task intent. Compare live tool metadata against the approved snapshot at connection time. Automatic pausing on detected drift limits blast radius before a human investigates.
Respond: Graded responses instead of binary allow/deny. Block destructive writes while allowing reads. Throttle noisy clients. Selectively revoke tokens. Kill switches operate at both client and gateway levels for rapid containment without wholesale downtime.
The future direction, per the Microsoft blog, is policy-as-code: allowlists, consent rules, and egress boundaries versioned in source control and testable in CI. Preflight checks will get smarter with stronger injection tests and automatic egress validation.
This is the piece that will separate enterprises that scale MCP governance from those that drown in manual reviews. When your MCP security policies live in code, they ship through the same CI/CD pipeline as your application code, and they are testable, auditable, and version-controlled.
Frequently Asked Questions
What is MCP security governance?
MCP security governance is the set of policies, controls, and processes that enterprises use to secure Model Context Protocol connections between AI agents and external tools. It covers authentication, authorization, audit logging, server vetting, and runtime monitoring across the entire MCP conversation lifecycle.
How does Microsoft secure MCP internally?
Microsoft uses a four-layer defense model (Applications, AI Platform, Data, Infrastructure) combined with three governance pillars: secure-by-default architecture routing all servers through an API gateway, staged vetting with security/privacy/responsible-AI reviews, and a living registry that automatically detects unregistered servers and pauses operations when tool metadata drifts from approved states.
What are the minimum enterprise controls for MCP?
Enterprise MCP deployments require at minimum: OAuth 2.0 authentication with credentials stored outside AI context, per-operation RBAC and ABAC authorization, attribution-level audit logging, path and scope controls, rate limiting, and sensitivity label evaluation. Microsoft adds TLS enforcement, egress pinning, and per-tool allowlists as baseline requirements.
What is an MCP conversation graph?
An MCP conversation graph is the chain of trust decisions that occurs during every MCP session: an agent discovers a server, ingests tool descriptions, attaches credentials, adds context, and starts sending requests. Each step introduces potential risk that compounds with subsequent steps, which is why Microsoft evaluates security across four layers rather than at individual tool calls.
How does MCP policy-as-code work?
MCP policy-as-code stores security rules (allowlists, consent requirements, egress boundaries) as versioned code in source control. These policies are tested in CI pipelines alongside application code, making them auditable, reproducible, and deployable through the same release process. Microsoft is moving toward this model to replace manual review bottlenecks with automated, testable governance.