Agent Control Standard: Govern Your AI Agents at Runtime

Your AI agents are calling APIs, reading files, executing code, and sending emails. Most of them are doing it with zero runtime controls on what they’re actually allowed to do. The Agent Control Standard (ACS) — launched May 27 at Microsoft Build 2026 — is the first cross-vendor, open specification built to fix that. One policy manifest. Works across LangChain, OpenAI Agents SDK, Anthropic Claude Agent SDK, AutoGen, CrewAI, and Semantic Kernel.

The Governance Gap Is Already Hurting Teams

Gartner puts it plainly: 40% of agentic AI projects are at risk of cancellation by 2027 due to governance gaps discovered only after production incidents. By the end of 2026, most large enterprises will be running more than 1,600 AI agents — and only 18% of those organizations maintain a complete inventory of what’s already running inside their walls. Eighty-eight percent of organizations have already reported confirmed or suspected security incidents tied to AI agents this year.

The industry has protocols for how agents communicate (A2A) and how they call tools (MCP). What it’s been missing is a shared framework for controlling what agents are actually permitted to do once they start executing. That is the gap ACS was built to close.

What ACS Is

ACS is an open specification and reference implementation for the runtime governance layer of AI agents. Its core artifact is a portable YAML manifest that defines four things: what an agent may do, what it must avoid, when human approval is required, and what evidence must be logged. The manifest is bundled with the agent itself, so governance travels with the workload regardless of which framework or deployment environment you’re using. The project is Apache 2.0 licensed, community-governed, and vendor-neutral — no single company owns the spec.

How the Three Layers Work

ACS is structured around three layers that cover enforcement, observability, and auditability.

Instrument

This is where policy is actually enforced. The Instrument layer defines standardized middleware hooks at every agent decision point: receiving input, calling a tool, executing code, writing to memory, invoking a sub-agent. At each hook, a Guardian Agent intercepts the action, evaluates it against your policy, and returns a verdict — allow, deny, or modify — before the action reaches production systems. The policy engine is pluggable: static rules, OPA/Rego policies, ML-based anomaly detection, or a human-in-the-loop approval queue.

Trace

Every action and reasoning step emits structured trace data through OpenTelemetry, extended with agent-specific semantic conventions. Security events map to OCSF so they flow into your existing SIEM infrastructure. You get a full, structured audit trail without building custom logging.

Inspect

The Inspect layer extends CycloneDX, SPDX, and SWID to produce dynamic Agent Bills of Materials (AgBOM) — real-time inventories that answer the questions compliance teams actually ask: which tools is this agent using, which model is it running, what data sources does it have access to, and what software version is deployed.

Your First ACS Policy in Three Steps

ACS ships a thin Python SDK. Install it, scaffold a policy folder, and attach a manifest to your agent.

pip install agent-control-specification
acs init
acs validate

The acs init command scaffolds a .agents/ folder in your project. Your policy manifest lives there. Here is an abbreviated example that binds a Rego policy to the pre_tool_call intervention point for an email-sending agent:

agent_control_specification_version: 0.3.1-beta
metadata:
  name: email-agent
policies:
  email_policy:
    type: rego
    bundle: ./policy
    query: data.email_agent.verdict
    intervention_points:
      pre_tool_call:
        policy_target: $.tool_call.args
        policy_target_kind: tool_args
        tool_name_from: $.tool_call.name

That manifest tells ACS: before this agent calls send_email, run email_policy against the tool arguments. If the policy denies, the call never happens. The full spec and reference implementation are at agentcontrolstandard.ai and github.com/Agent-Control-Standard/ACS.

Framework Support and Where ACS Sits in the Stack

ACS does not replace your agent framework. It governs it. The SDK ships with plugins for LangChain, OpenAI Agents SDK, Anthropic Claude Agent SDK, AutoGen, CrewAI, Semantic Kernel, Microsoft.Extensions.AI, and MCP tools. Think of it this way: A2A handles inter-agent communication, MCP handles tool calling, and ACS handles what those agents are permitted to do at runtime. It is the layer the stack was missing.

Why This Is Urgent

Two deadlines are driving enterprise urgency. The EU AI Act Article 50 deadline hits August 2, 2026, and it requires demonstrable human oversight of high-risk AI systems — the Guardian Agent pattern in ACS’s Instrument layer directly satisfies that requirement. The NIST AI Risk Management Framework calls for continuous monitoring and the capacity to disengage autonomous systems operating outside acceptable parameters — that is the Trace layer.

The Microsoft Foundry announcement from Build 2026 frames ACS as part of a broader open trust stack for agents. The Gartner research backing the 40% cancellation risk figure is worth reading in full.

ACS is at version 0.3.1-beta. The spec is not frozen. But the architecture is sound, the framework integrations are shipping, and the alternatives are either vendor-locked or do not exist yet. Governance tooling is always the last thing developers add and the first thing that causes a production disaster. ACS makes governance declarative and portable — the policy file travels with the agent, not the team. That is the right mental model for the number of agents you are about to be running.