Three-quarters of enterprises have already rolled back or shut down an AI agent after deployment, and ungoverned tool access is one of the primary reasons. Every time an agent connects to a new service through the Model Context Protocol, it opens a trust boundary. When you multiply that by dozens of agents and hundreds of tools, the governance surface compounds quickly. The question is whether you are managing those boundaries as infrastructure or discovering them after an incident.
By the end of this article you will understand why governance infrastructure, not model capability, is the durable enterprise product for any organisation betting on AI agents. And you will have the framework to evaluate whether your agent governance is production-ready.
What is the Model Context Protocol and why does it need enterprise governance?
The Model Context Protocol is an open standard that defines a client-server architecture for connecting AI agents to external tools, data sources, and APIs through explicit permissions. Originally developed by Anthropic, it has seen adoption accelerate from roughly 100,000 server downloads in late 2024 to over 8 million by April 2025, with more than 5,800 MCP servers now publicly available.
MCP is transformative because it standardises what was previously a bespoke integration problem. It is the USB-C for AI agents: a universal connector that any model can use to plug into any tool.
The thing is, MCP handles the connection. It does not handle who gets to connect, under what conditions, or what happens when something goes wrong. As Tray.ai’s security analysis puts it, MCP “describes how clients and servers exchange resources and tools. It does not define who gets to act, when they can act, and under what conditions.” The protocol deliberately omits governance mechanisms from its core specification, leaving security to application developers.
Why should you care? Because a February 2026 scan of over 8,000 MCP servers on the public internet found that a large portion exposed admin panels, debug endpoints, or API routes without authentication. Over half of public MCP servers use static secrets rather than proper OAuth, and tool poisoning attacks succeed at a 72.8 per cent rate in benchmark testing. On April 15 this year, SecurityWeek reported that MCP contains a “by design” weakness enabling supply chain attacks where a single compromised server can pivot across every connected resource.
Agent-to-agent communication adds another dimension. The A2A protocol enables agents to coordinate autonomously, but research has documented attack vectors including fake agent advertisement, recursive denial-of-service, transitive prompt injection, and context tampering. Unchecked, one compromised agent can cascade failure through an entire multi-agent system.
Microsoft’s own approach to MCP governance organises around a four-layer security model: transport security (TLS and mTLS on every connection), authentication and authorisation (workload identities with scoped permissions), input/output validation and content filtering (Prompt Shields, data classification), and behavioural monitoring (anomaly detection for unusual tool usage patterns). The baseline posture is secure-by-default: deny first, allow-list second. Every MCP server goes through a full lifecycle: registration, security review, integration testing, limited production deployment with monitoring, and full promotion. Every server is versioned so that tool access can be rolled back the moment something looks wrong.
What is the Agent Control Specification and how does it enforce safety at runtime?
Pre-deployment testing catches the failure modes you already know about. The Agent Control Specification catches the ones you do not, at runtime, before they reach production systems.
ACS is a vendor-agnostic, MIT-licensed open standard for governing AI agents through middleware hooks. It is built around three layers.
Instrument places policy hooks at five checkpoints in an agent’s lifecycle: input, LLM call, state change, tool execution, and output.
Trace extends OpenTelemetry with agent-specific semantic conventions and OCSF security event formatting.
Inspect adds CycloneDX and SPDX extensions for dynamic Agent Bills of Materials, so you know exactly what dependencies every agent carries at any moment.
The checkpoint model is where ACS differentiates itself from static testing. Pre-action checkpoints evaluate whether a proposed action is safe before execution. Post-action checkpoints evaluate whether the result violates policy. Continuous monitoring detects anomalous behavioural patterns across the entire agent fleet. When an agent receives input or calls a tool, ACS fires a hook, evaluates the action against policy, and returns a verdict, allow, deny, or modify, in single-digit milliseconds.
“Governance cannot rely on soft guardrails or wishful system prompts,” Michael Bargury, co-creator of ACS, said at launch. ACS fills that gap with deterministic enforcement that cannot be talked around or jailbroken.
Attestation is the other piece that makes ACS matter for regulated industries. At each checkpoint, ACS produces cryptographic proof that the agent’s behaviour complied with policy. This creates the evidence chain that regulations like the EU AI Act require for high-risk systems: demonstrable human oversight, real-time intervention capability, and auditable decision trails. NIST’s AI Risk Management Framework calls for the same kind of continuous monitoring. ACS provides both as infrastructure.
What is ASSERT and how does it convert written policies into executable agent evaluations?
ASSERT converts written policies from static documents into executable agent evaluations, bridging the gap between what governance looks like on paper and what it does in practice.
ASSERT, short for Adaptive Spec-driven Scoring for Evaluation and Regression Testing, is Microsoft’s open-source framework that turns natural-language behaviour specifications into automated evaluation suites. The pipeline has four stages. First, taxonomisation converts a written policy into a structured taxonomy of permissible and impermissible behaviours. Second, test-set generation instantiates that taxonomy into executable cases, including single-turn prompts and multi-turn adversarial scenarios. Third, inference runs those cases against the target agent, recording tool calls, retrieved context, and intermediate actions. Fourth, scoring evaluates each trace against the policy, producing pass-or-flag verdicts with rationale, policy citation, and the exact turn that justified the verdict.
Here is a concrete example. Suppose your policy says “agents may not access customer PII without explicit consent.” ASSERT takes that sentence, builds a taxonomy of what counts as PII and what counts as consent, generates scenarios where an agent might try to access customer data, runs those scenarios against your agent, and flags every violation with a citation back to the original policy language. That output feeds into ACS pre-action and post-action checkpoints. The loop from governance intent to governance verification closes.
This is the paradigm shift: policy-as-eval, extending the policy-as-code discipline from infrastructure to agent behaviour. And because ASSERT works across LangChain, CrewAI, OpenAI, and more, you do not need to rebuild your evaluation pipeline every time you change model providers.
What governance framework should enterprises put in place before deploying autonomous agents?
Governance is an architectural stack with five integrated layers that must be in place before the first agent reaches production.
The first layer is identity. Agents require a distinct identity class, workload identities with scoped permissions, separate from both user accounts and service accounts. Microsoft Entra Agent ID gives every agent a unique, persistent identity that you can scope, monitor, and revoke independently. As the identity industry has reached consensus: “Agents are not users. They are not service accounts.” Without identity, you cannot govern what you cannot identify.
The second layer is content safety. This means Prompt Shields against direct and indirect injection, output filtering for harmful content, and abuse monitoring across the agent fleet.
The third layer is operational controls. Provider caps apply rate limiting per agent, per model, per tool. Kill switches operate at the infrastructure level, not within the agent itself, because a compromised agent cannot be trusted to honour its own termination instruction. Deploy these through your gateway enforcement layer so that platform teams can sever connections, revoke tokens, and halt compute without vendor support.
The fourth layer is regulatory alignment. The EU AI Act, effective August 2026, imposes requirements for high-risk AI systems: transparency, human oversight, accuracy, and robustness. Non-compliance penalties reach €35 million or 7 per cent of global revenue. NIST’s AI Risk Management Framework provides the voluntary standards baseline with its Govern, Map, Measure, and Manage functions. ACS attestation creates the evidence both require.
The fifth layer is hardware trust. Confidential computing ensures data remains encrypted even during processing, which matters when agents handle sensitive workloads across multi-tenant infrastructure.
The governance gap is not theoretical. Among organisations with mature governance frameworks, the rollback rate actually increases to 81 per cent. As Daniel Morris, CPO at Sinch, observed: “The most advanced organisations aren’t failing less; they’re seeing failures sooner.” Governance infrastructure does not prevent every incident. It catches them before they reach customers.
What are Toolboxes and how do they manage MCP tools at scale?
The identity and controls layers of the governance framework need operational mechanisms to function at scale. Toolboxes are Foundry‘s answer to that problem.
Without a shared management layer, every agent team repeats the same authentication setup, re-implements the same integrations, and operates without shared governance. A Toolbox groups MCP servers, applies policies at the group level, and exposes a single MCP-compatible endpoint that any agent can consume. You define rate limiting, authentication requirements, and content filtering rules once, and every member server inherits them.
Where Toolboxes change the operational picture is in lifecycle management. Versioning is built in: create and test a new version, promote it to default, and every agent pointing to the Toolbox picks up the change with no code changes and no redeployment. Versions are immutable snapshots, which means rollback is instant when something breaks. This is the difference between managing MCP connections as infrastructure and managing them as configuration files that drift across teams.
Toolboxes handle credential injection, token refresh, and enterprise policy enforcement at runtime. Content filtering guardrails operate independently of model-level filters, so you are not relying on any single model provider to police your tool access. Azure API Management provides the gateway enforcement layer: rate limiting, authentication, and monitoring for every MCP endpoint as a managed resource.
Foundry’s governance model versus building custom governance
With the framework laid out and Toolboxes demonstrating how it operates at scale, you face a practical decision: integrate or assemble.
Everything in the governance stack is available as open standards. The MCP spec is open. ACS is MIT-licensed. ASSERT is open source. You can assemble your own governance infrastructure from these components. The question is what that assembly costs over time.
Foundry provides the integrated stack: Toolboxes for MCP management, ACS for runtime enforcement, ASSERT for policy-to-evaluation, Entra ID for identity, and Azure API Management for gateway enforcement. Custom governance requires integrating these same capabilities yourself, and the integration surface compounds with each new model, each new tool, each new deployment.
The scaling argument is not about feature parity. It is about integration debt. Only 14 per cent of enterprises have scaled an agent to production-grade operation. The organisations that succeed spend proportionally more on evaluation infrastructure, monitoring tooling, and operational staffing. Custom governance adds a layer of maintenance that platform teams carry across every model, tool, and deployment they add.
That said, enterprises with small, homogeneous agent fleets and dedicated platform teams may find custom governance viable. If you are running a handful of read-only agents on a single model provider, the integration surface is manageable. If you are running a heterogeneous fleet across multiple providers with agents that modify data and trigger business processes, the platform approach scales in a way that custom assembly does not.
How can platform teams assess their MCP server governance?
Start with the four-layer assessment. Transport: are all MCP connections using TLS or mTLS? Authentication: are agents operating as workload identities with scoped permissions? Validation: are content filters applied to tool inputs and outputs? Monitoring: is there anomaly detection for unusual tool usage patterns?
Then audit your posture against secure-by-default. The secure-by-default principle, deny first and allow-list second, should be your baseline. Does your current configuration actually enforce this? Who approves new MCP server connections? If the answer to any of those is “we will figure it out,” your governance is not adequate.
Finally, evaluate lifecycle maturity. Are MCP servers versioned? Is there a deprecation path? Can tool access be rolled back on incident? The MCP Security Maturity Model defines four levels, starting from token-only authentication at Level 1 up to hardware-backed identity and real-time anomaly detection at Level 4. Most production organisations sit between Levels 2 and 3. Where your organisation lands depends on your risk tolerance and the sensitivity of what your agents can access.
Governance posture shifts as new tools are added and agent fleets grow. Organisations that treat this as a continuous assessment rather than a one-time exercise are the ones that sustain production deployments. The 74 per cent rollback rate reflects what happens when governance is treated as documentation rather than infrastructure, and the path forward is an engineering discipline you now have the framework to begin.
Frequently Asked Questions
How long does it take to put governance infrastructure in place before deploying agents?
Plan for four to eight weeks to reach minimum viable governance: workload identity configuration, MCP vetting process establishment, content safety filtering, and kill switch deployment. The longer pole is not the technical implementation but the policy decisions. What permissions should agents hold? Who approves new tool connections? What constitutes an incident requiring agent termination? Governance infrastructure deploys in weeks; governance decisions that earn platform team and compliance alignment take longer.
Do we need both MCP and ACS, or can we start with just one?
Start with MCP governance as your foundation. Without managed, vetted, and monitored tool connections, there is nothing for ACS to enforce. Add ACS when agents move beyond read-only operations and start taking actions that modify data, trigger business processes, or communicate with other agents. MCP governs the connections; ACS governs the behaviour. Both are necessary for production deployments, but MCP is the prerequisite: you cannot govern what you cannot connect securely.
How do I stop an AI agent if it is doing something it should not be doing?
Kill switches must operate at the infrastructure level, not within the agent itself. A compromised or misbehaving agent cannot be trusted to honour its own termination instruction. Deploy emergency kill switches through your gateway enforcement layer (Azure API Management) that sever all connections at the network level, revoke the agent’s workload identity tokens through Entra ID, and halt compute resources. These controls should be testable quarterly and executable by platform teams without requiring model-provider or vendor support.
Is the Agent Control Specification only for Microsoft Foundry?
No. ACS is an MIT-licensed, vendor-agnostic, open-source standard. It defines middleware hooks that any agent platform can implement, and it integrates with OpenTelemetry for observability and OCSF for security event formatting. Foundry provides a managed implementation, but you can build ACS-compatible enforcement with open-source toolkits. The specification, not the implementation, is the durable standard, and its governance model works across any agent runtime that adopts the checkpoint architecture.
What is the first thing our platform team should do to start governing AI agents?
Establish agent identity as workload identities in Microsoft Entra ID. Until every agent has a unique, verifiable identity with scoped permissions, you are governing shadows. Workload identities are the governance primitive on which every other control depends: MCP server authorisation, content safety scoping, rate limiting, kill switches, and compliance attestation all require knowing which agent is taking which action. Start with identity, then audit every existing tool connection against the secure-by-default principle.
Can small enterprises with limited resources govern AI agents effectively?
Yes, but scope discipline matters more than resource depth. Small enterprises should limit their initial agent fleet to read-only or low-risk operations, deploy MCP governance using managed Toolboxes rather than custom integration, and focus on the two controls with the highest return: workload identity and content safety filtering. The MCP spec and ACS are open standards, so the governance architecture is accessible. What small teams lack in dedicated governance headcount they can offset by constraining the problem: fewer agents, fewer tools, tighter boundaries.
How does agent governance differ from API governance?
API governance controls what a system can access. Agent governance controls what an agent chooses to access, when, and in what sequence. An API gateway authenticates a caller once per request; agent governance evaluates every action at pre-action, post-action, and continuous monitoring checkpoints because agent behaviour is non-deterministic. The same API connection that is safe in one context may be dangerous in another. Agent governance adds behavioural monitoring, anomaly detection, and cryptographic attestation that API governance alone does not provide.
What happens if an agent uses a tool outside its approved Toolbox?
This is the security posture that secure-by-default MCP strategy prevents. When properly configured, every MCP server connection is denied by default and explicitly allow-listed after vetting. An agent attempting a connection to an unregistered MCP server receives a deny verdict at the gateway enforcement layer, the attempt is logged as a security event, and anomaly detection flags the agent for review. If the agent has been compromised and is probing for unapproved connections, behavioural monitoring surfaces the pattern before exfiltration occurs.
Does MCP governance slow down agent performance?
The performance impact is negligible for well-architected governance. MCP connection authentication occurs once per session, not per invocation. ACS checkpoint evaluations are policy lookups, not model inferences, and execute in single-digit milliseconds. The architecture places enforcement at the gateway layer (Azure API Management) rather than inline within the agent runtime, so governance checks do not compete with inference compute. The real performance cost in enterprise deployments comes from ungoverned tool access triggering incidents, not from governance itself.
What if our agents use models from multiple providers?
Multi-model deployments strengthen the case for governance infrastructure, not weaken it. MCP and ACS are model-agnostic: the protocol governs tool connections regardless of which model initiated the call, and the checkpoint model evaluates actions regardless of which model generated them. Foundry’s governance stack abstracts the model layer, applying consistent identity, content safety, rate limiting, and kill switches across OpenAI, Azure, and third-party models. Homogeneous model fleets are simpler to operate; heterogeneous fleets are where governance infrastructure proves its platform value.
