Microsoft’s Agent Control Specification (ACS): The Governance Layer for Enterprise AI Agents

Microsoft’s latest agent announcements point to a problem the AI industry can no longer avoid: building powerful agents is only half the job; controlling them is the other half. At Build 2026, Microsoft introduced the Agent Control Specification (ACS), an open standard meant to help developers, security teams, and compliance teams define how AI agents should behave through portable runtime policy controls.

That makes ACS more than just another developer tool. It is part of a broader push to make AI agents auditable, testable, and governable across frameworks, which matters more as agents move from demos into real business workflows.

What Microsoft announced

Microsoft presented ACS as a portable runtime control standard and positioned it as part of its Agent Governance Toolkit. The company said the specification is designed for broad ecosystem adoption, which suggests Microsoft wants ACS to be used beyond its own platforms rather than kept as a proprietary governance layer.

The timing is important. Build 2026 was heavily centered on agent-first development, and Microsoft repeatedly framed trust, evaluation, and observability as essential to production AI systems. In Microsoft Foundry’s Build update, ACS appeared alongside ASSERT, guided guardrail setup, tracing, optimization, and ROI tooling, which places it inside a larger trust stack rather than as a standalone feature.

Why ACS matters

AI agents are different from ordinary software because they do not just execute fixed commands; they interpret goals, choose tools, and act in partially open-ended environments. That flexibility is useful, but it also creates risk: an agent can overreach, misuse tools, mishandle sensitive information, or take actions that violate business policy if guardrails are weak.

ACS addresses that problem by giving teams a standard way to define runtime controls. In practice, that means organizations can specify what an agent is allowed to do, where checks should apply in the agent loop, and how those policies can travel across environments and implementations. For enterprises, that is a meaningful shift because governance becomes something closer to infrastructure rather than an ad hoc add-on.

If MCP Already Provides Security Context, Why Does ACS Matter?

One question many developers may ask is whether the Agent Control Specification (ACS) overlaps with the Model Context Protocol (MCP).

At first glance, both appear related to agent governance because MCP already provides a standardized way for AI systems to interact with external tools, services, and data sources. MCP can also communicate security-related information such as permissions, identity context, and access constraints between systems.

However, MCP and ACS solve different problems.

MCP primarily focuses on how agents connect to external systems. It standardizes communication between an AI agent and the tools it uses, ensuring that context, permissions, and requests can be exchanged in a consistent manner. In other words, MCP defines the interface through which an agent gains access to capabilities.

ACS focuses on how an agent behaves once those capabilities are available.

For example, MCP may tell an agent that it has permission to access a customer database. ACS can define whether the agent is allowed to retrieve specific categories of records, whether human approval is required before exporting data, or whether additional runtime checks should be enforced before certain actions are executed.

This distinction becomes important because many AI risks do not originate from unauthorized access alone. An agent can technically have valid access to a system and still perform actions that violate business policy, compliance requirements, or organizational best practices.

Think of MCP as the mechanism that grants and communicates capabilities, while ACS provides the policy layer that governs how those capabilities may be used.

Together, the two standards can be complementary. MCP helps agents interact securely with tools and services, while ACS helps organizations ensure that those interactions remain aligned with governance, security, and compliance requirements throughout the agent's lifecycle.

As enterprise AI systems become more autonomous, both layers are likely to become increasingly important: one defining access, the other defining acceptable behavior.

The enterprise angle

The strongest use case for ACS is not hobbyist experimentation; it is enterprise deployment. Large organizations need AI agents to work within security rules, compliance requirements, and internal operating boundaries, especially when those agents touch sensitive data, customer records, finance systems, developer environments, or regulated workflows.

Microsoft’s Build messaging makes that focus clear. The company described new security capabilities that cover the full development lifecycle, from discovering exploitable issues to governing live systems and verifying behavior before production release. ACS fits naturally into that story because it gives teams a standard method to say not just what an agent can do in theory, but what it is allowed to do in practice.

How ACS fits with Microsoft’s broader trust stack

ACS was not announced in isolation. Microsoft paired it with ASSERT, an open-source evaluation framework for regression testing and policy-driven scoring, and surrounded both with other governance and observability tools in Foundry. Testing agent behavior and controlling agent behavior are related but not identical problems.

ASSERT helps teams measure whether an agent behaves as expected during evaluation. ACS helps define the runtime controls that shape what the agent is allowed to do once deployed. Together, they represent a more complete trust model: evaluate the agent before launch, then control it while it runs.

Why Microsoft is pushing an open specification

One of the most notable parts of the announcement is Microsoft’s decision to frame ACS as an open standard for broad ecosystem adoption. That choice reflects a real market need because enterprise AI stacks are becoming more fragmented, with teams using multiple models, tools, frameworks, and deployment environments.

If governance remains vendor-specific, companies end up with duplicated policy logic and inconsistent controls across systems. A portable control standard is attractive because it promises common policy definitions across agent frameworks and runtimes, even if the underlying models or orchestration layers differ. Microsoft benefits if it helps define that standard early, especially as agent infrastructure becomes a major competitive layer.

What this means for developers

For developers, ACS signals that agent engineering is becoming more disciplined. Building a useful agent will increasingly involve not only prompts, tools, and memory, but also formal control layers, observable traces, and testable policy boundaries.

That changes the nature of AI product development. Developers may need to work more closely with security and compliance teams, since policies can no longer be bolted on after the fact in high-stakes environments. In practical terms, the best agent teams will likely be the ones that treat governance as part of the product architecture rather than a deployment checklist.

The bigger picture

ACS reflects a broader shift in AI. The industry is moving from “Can an agent do this?” to “How do we make sure the agent does this safely, predictably, and accountably?” That is the kind of shift that happens when a technology starts moving from innovation theater into operational reality.

Microsoft’s announcement shows where the market is heading: toward standardized control, shared policy frameworks, and agent systems that must be managed as seriously as any other enterprise software layer.

Final take

The Agent Control Specification may sound like a technical side note compared with flashier AI announcements, but it could become one of the more consequential developments from Build 2026. If AI agents are going to become part of mainstream business infrastructure, they need clear behavioral boundaries, and ACS is Microsoft’s attempt to help define them.

As enterprises move from AI experimentation to production deployments, portable control standards like ACS could become a foundational layer for building trustworthy, secure, and governable AI agent ecosystems. While the specification is still in its early stages, Microsoft's push for an open and portable governance framework signals where the industry is headed: toward AI systems that are not only capable, but also accountable.

Build Enterprise-Ready AI Agents with Confidence

As AI agents move from experimentation to production, governance is becoming just as important as capability. Organizations need frameworks that ensure agents remain secure, compliant, and aligned with business objectives while operating across increasingly complex environments.

Whether you're exploring agent-based automation, implementing AI governance frameworks, or building enterprise-grade AI solutions, establishing the right control mechanisms early can significantly reduce risk and accelerate adoption.

Looking to build secure and scalable AI agent solutions? Connect with the team at Kaira Software to explore how governance, observability, and responsible AI practices can be integrated into your AI initiatives from day one.

Contact Us