Microsoft Open-Sources the ACS Specification: Putting a Policy Bridle on AI Agents

At today’s opening of the Build 2026 conference, Microsoft unveiled a new specification—the Agent Control Specification, or ACS for short. This is an open‑source standard with one core goal: to allow developers to precisely control what AI agents can and cannot do in a unified way.

It might sound like yet another governance framework, but ACS solves a very specific problem: most teams today manage AI agents with improvised patchwork solutions. They add a few constraints in system prompts, some if statements at the application layer, then train a small classifier to filter inputs and outputs—it works, but everything is scattered. Change the framework, and you have to rewrite everything; when something goes wrong, there’s no way to trace an audit trail.

Why Microsoft Is Doing This

Since AI agents started being deployed, there’s been a pile of failure cases—tools miscalled, parameters passed incorrectly, chain‑of‑calls where one broken link crashes the whole flow. These aren’t model capability issues but behavior constraint issues. The closed‑loop vulnerability process published by Anthropic earlier essentially tackles the same kind of problem.

Microsoft’s observation: development, compliance, and security teams each have their own rules, but when implemented in code, these rules overlap and get mixed together. No one can tell which policy belongs to whom, where it takes effect, or whether it can be bypassed. ACS aims to unify these requirements into one policy file, then have the runtime enforce it.

One key clarification: ACS is not another AI agent development framework. It doesn’t compete with Microsoft’s own Agent Framework, LangChain, or AutoGen. It’s more of a cross‑cutting governance layer, decoupled from specific frameworks—which is why Microsoft emphasizes that it’s vendor‑agnostic. In fact, ACS is being co‑developed with security companies like Zenity, not built solely by Microsoft.

Interception Point Design

The most notable part of ACS is the design of interception points. A full agent execution is divided into several stages, and each stage can have policy checks attached:

• Before receiving input: the user’s request comes in and is first validated by policy
• Before calling tools/APIs: when the agent decides to invoke an API or function, it checks if the call is permitted and the parameters are valid
• After tool execution: once results are obtained, decide whether to sanitize or block them
• Before sending the final reply: one last check before giving the result to the user

Each interception point allows four possible policy actions: allow, block, sanitize, or require human approval. This design resembles middleware in web development—except the subject here is the agent’s behavioral flow, not HTTP requests.

The benefit of this “slice” approach is clear: previously, if you wondered “Why did this agent call a database‑deletion tool?”, you had to search logs, prompts, and code. Now, the policy file itself provides the answer—either it allowed it, missed the case, or got bypassed. Each situation has a distinct fix.

How Policies Are Written

According to Microsoft, ACS policies can include three kinds of logic—not just hard rules:

1. Classifiers – small trained models to detect sensitive or non‑compliant inputs/outputs
2. LLM‑as‑Judge – using a large language model as a referee, prompted to determine if an action should be allowed
3. Rule Checks – hard‑coded logic for specific aspects such as tool calls, selection, input validity, and output usage

These can be combined. For example, in a customer‑service agent: keyword filtering may use rules, detecting privacy leaks can rely on classifiers, and complex decisions like whether a refund should be approved can be handled by an LLM judge.

Policies are defined as a single file and can be packaged with the agent during deployment. The implication: if an agent moves from Azure to AWS or from Agent Framework to LangGraph, the security policy doesn’t need to be rewritten. That’s a huge pain point in enterprise scenarios—many teams have had to rebuild governance rules from scratch after switching frameworks and eventually gave up on systematic governance.

Comparison with Existing Solutions

A horizontal comparison:

• NeMo Guardrails (NVIDIA): uses Colang DSL to define conversation guardrails; strong in dialogue flow control, weaker in fine‑grained tool governance
• Guardrails AI: focuses on input/output validation, operates mostly at the checking layer
• OpenAI moderation API: only handles content filtering
• LangChain callbacks: lets you plug in hooks, but you must build your own policy logic—no standardized specification

ACS tries to unify these fragmented capabilities under a single specification layer. The upside: broader governance coverage—from input, to tooling, to output. The downside: more complexity; small teams may find it overkill.

What’s Available Now

ACS is currently released as an SDK supporting several mainstream agent‑development frameworks and tools. Microsoft hasn’t locked it to its own Agent Framework, which shows an open stance—but whether it succeeds depends on the community. Realistically, specs like this live or die by ecosystem, not technology. OpenTelemetry succeeded because clouds adopted it; OpenAPI succeeded because the tooling ecosystem matured. ACS is still early; the key test will be whether it gets integrated into “de facto standard” frameworks like LangChain or LlamaIndex.

How developers experience ACS in practice:

• Security/compliance teams write a policy.yaml (or similar)
• Dev teams attach that policy file during agent initialization
• The runtime SDK automatically triggers policy checks at four interception points
• Any intercepted actions are logged for auditing purposes

This workflow shifts governance from “scattered logic in code” to “centralized declarations in configuration.” It’s particularly well‑suited to enterprises. In highly regulated sectors like finance and healthcare, compliance teams can finally review one policy file instead of reading developers’ source code.

A Final Assessment

In 2025, people were still talking about AI agent governance; by 2026, it’s time to implement it. ACS isn’t the first attempt and won’t be the last, but its chosen entry point—interception points plus portable policy files—is the right one.

A few things worth watching:

1. How deeply the SDK supports non‑Microsoft frameworks
2. Whether the policy file format becomes a de facto standard (as OpenAPI did for REST)
3. Whether LLM‑as‑Judge incurs manageable latency and cost in production

AI agent uncontrollability has moved from theoretical risk to real incidents. ACS’s standardized governance approach points in the right direction. The only remaining question is: who will make it the industry’s default?

References

• ITHome: Microsoft releases ACS open‑source standard to let developers precisely control AI agent behavior – Chinese report on the ACS specification, including detailed explanations of interception points and policy mechanisms