Agent Control Specification: Portable runtime governance for AI Agents
Skip to main content
Skip to main content
Source
Signal blog<br>Official Microsoft Blog<br>Microsoft On The Issues<br>Asia<br>Canada<br>Europe, Middle East and Africa<br>Latin America<br>The Code of Us<br>Conexiones
What's new today
AI
Innovation
Digital Transformation
Sustainability
Security
Work & Life
Diversity & Inclusion
Unlocked
Microsoft 365<br>Azure<br>Copilot<br>Windows<br>Surface<br>XBOX<br>Deals<br>Small Business<br>Support
Windows Apps<br>Outlook<br>OneDrive<br>Microsoft Teams<br>OneNote<br>Microsoft Edge<br>Moving from Skype to Teams
Computers<br>Shop Xbox<br>Accessories<br>VR & mixed reality<br>Certified Refurbished<br>Trade-in for cash
Xbox Game Pass Ultimate<br>PC Game Pass<br>Xbox games<br>PC games
Microsoft AI<br>Microsoft Security<br>Dynamics 365<br>Microsoft 365 for business<br>Microsoft Power Platform<br>Windows 365<br>Small Business<br>Digital Sovereignty
Azure<br>Microsoft Developer<br>Microsoft Learn<br>Support for AI marketplace apps<br>Microsoft Tech Community<br>Microsoft Marketplace<br>Software companies<br>Visual Studio
Microsoft Rewards<br>Free downloads & security<br>Education<br>Gift cards<br>Licensing<br>Unlocked stories
View Sitemap
Search articles
Article
Share
in
Introducing Agent Control Specification: Portable runtime governance for AI Agents
Introducing Agent Control Specification: Portable runtime governance for AI Agents
ACS is an open, vendor-neutral standard that defines how runtime governance is applied across the agent lifecycle, independent of framework, runtime, or policy engine.
By Responsible AI at MicrosoftMicrosoft’s Responsible AI team, Mohamed ElmergawiPrincipal Software Engineering Manager, Microsoft, Mohammad AbouomarPrincipal Architect, Responsible AI, Microsoft, Liam CrummSenior Software Engineer, Microsoft, and Mehrnoosh SamekiPrincipal PM Manager, Microsoft
AI is entering a new phase, and agents are the mechanism that will turn it into real economic impact.
We’re moving beyond models that generate text or code, and into systems that act by retrieving data, calling tools, executing workflows, and making decisions across environments. Frameworks like LangChain, AutoGen, CrewAI, and the Microsoft Agent stack have made it straightforward to build agents that can reason and operate end-to-end. When software starts acting on behalf of people, the surface area of automation expands across every workflow, every system, and every industry.
That shift introduces a new problem: As agents gain autonomy, the question is no longer just what they can do, but what they should be allowed to do and who defines those boundaries. Recent industry work highlights failure modes that don’t exist in traditional systems: tool misuse and unintended actions across multi-step failures that emerge across agent workflows. At the same time, regulatory expectations are accelerating, with new requirements around high-risk AI systems and accountability already coming into play.
Today, governance largely lives in the development layer. Individual teams embed rules in prompts, application code, or framework-specific hooks. These controls are fragmented, inconsistent, and tightly coupled to how each agent is built. There is no standard mechanism by which a security or compliance team can define, enforce, and audit policy across agents.
Why the existing playbook breaks
Traditional security models assume a fixed actor and a fixed scope. With agents, the same credential that may be safe in one moment becomes risky in the next. A Slack token that’s fine for posting a meeting summary becomes dangerous the moment the agent has read a document marked confidential or included external users in the group. Traditional access control has no vocabulary for this: It can only answer “is this credential allowed to call this resource?”—not “given everything this agent has touched in this conversation, is this call still safe?”
Customers told us they were patching these gaps by stitching together classifiers, validations, and custom checks throughout their codebases. Every team had built some versions of this. We consistently saw the same patterns emerge.
System prompts are often the first line of defense. They tell the agent what it should or should not do. They’re useful, but they aren’t enforceable. A prompt instruction lives in the same stream as user input, retrieved content, tool results, and potentially attacker-controlled text.
Custom logic inside the agent can provide stronger guarantees for deterministic checks. But those rules are usually buried in application code. They’re hard to audit, hard to reuse, and hard to move when the team changes frameworks.
Input and output classifiers help detect risks like jailbreaks, prompt injection, toxicity, or sensitive content. But classifiers often only see isolated text. They don’t automatically know which tool is about to run, what data labels are attached, or what context the agent has accumulated.
Framework-specific guardrails (OpenAI Agents SDK input/output guardrails, Semantic...