Microsoft ACS: Open Standard for AI Agent Governance

Every team shipping AI agents in production is solving the same governance problem from scratch: what can this agent actually do, when does a human need to step in, and what gets logged when something goes wrong? Most teams handle this with custom middleware that works for one framework and breaks the moment they switch. Microsoft’s Agent Control Specification (ACS) is a direct response to that: an open, vendor-neutral standard for enforcing deterministic policy at five points in the agent lifecycle, portable across every major framework, and available to install today.

What ACS Is (and What It Isn’t)

ACS is not a Microsoft control plane, a guardrail wrapper, or another enterprise AI product. It is a specification — open source, MIT licensed, framework-agnostic. The core artifact is a YAML policy manifest that travels with your agent regardless of where it’s deployed or what framework it runs on. If MCP standardized how agents access tools, ACS standardizes what agents are allowed to do with those tools. The analogy is deliberate: MCP went from niche to near-universal adoption in about six months. ACS is positioned to follow the same path.

ACS ships as part of Microsoft’s Agent Governance Toolkit, open-sourced on April 2, 2026 under an MIT license. The toolkit covers all ten OWASP Agentic AI risks — tool misuse, goal hijacking, identity abuse, memory poisoning, and the rest. ACS is the specification and policy enforcement layer within it, and it’s the piece agent developers need first.

The Five Checkpoints

ACS enforces policy at five lifecycle checkpoints. Understanding what each checkpoint catches is the quickest way to see why this approach works where generic guardrails don’t:

• Input — Before the agent processes any user message or external data. Catches prompt injection, out-of-scope requests, and sensitive data (PII, credentials) before they reach the model.
• LLM — Before and after model generation. Controls what context the model receives; can redact sensitive fields so the model never sees data it isn’t authorized to process.
• State — When the agent reads or writes memory. Prevents memory poisoning attacks and controls what persists across sessions.
• Tool Execution — Before the agent invokes any tool or API. This is the critical checkpoint: the agent cannot call a tool that violates declared policy, regardless of what the model output says. File access, external APIs, code execution, web requests — all gated here.
• Output — Before the final response leaves the agent. Catches data leakage, exposed credentials, and compliance violations before they reach users or downstream systems.

The tool execution checkpoint deserves emphasis. Most existing governance approaches try to catch bad behavior in the model’s output — after the decision to act has already been made. ACS intercepts at the point of action. That distinction matters for compliance: you don’t just detect the violation, you prevent it.

How Policy Manifests Work

Policies are expressed as portable YAML files. A manifest declares what the agent may do, what it must not do, when a human must approve, and what should be logged for audit. At each checkpoint, a policy verdict can allow an action, block it, redact sensitive information, escalate to a human, or log evidence. A minimal manifest that blocks destructive writes and redacts email addresses from output:

version: "1.0"
agent_id: "customer-support-v1"
checkpoints:
  tool_execution:
    deny:
      - pattern: "DELETE *"
        reason: "Destructive writes require human approval"
  output:
    redact:
      - pattern: "\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Z]{2,}\\b"
        label: "[REDACTED_EMAIL]"

The manifest supports OPA Rego and Cedar alongside YAML, so teams with existing policy infrastructure can plug straight in. A single PolicyEvaluator.evaluate() call can consult all three simultaneously — no migration required.

Getting It Running

Install the Python SDK directly from PyPI:

pip install agent-control-specification

TypeScript developers can install the public preview:

npm install @microsoft/agent-governance-sdk@4.0.0

The toolkit also ships for .NET, Rust, and Go. Integration works through each framework’s native extension points — LangChain callback handlers, CrewAI task decorators — so you don’t need to rewrite agents to add governance.

Why This Exists Now

Two pressures are converging. The first is regulatory: the EU AI Act’s full enforcement window opens August 2, 2026. Documentation alone doesn’t satisfy it — runtime enforcement does. The second is scale: most enterprise teams are now running multiple agents across multiple frameworks with different governance rules per deployment. That approach accumulates governance debt fast.

“Governance without runtime enforcement is unverifiable policy, and runtime security without governance lacks accountability.”

Microsoft Agent Governance Toolkit documentation

ACS is the policy decision layer that’s been missing from agent deployments. The full specification and SDK are available at the Agent Governance Toolkit repository. The Build 2026 announcement covers the broader trust stack context.