The OWASP Agent Control Standard, explained

The Agent Control Standard, or ACS, is an open specification for controlling AI agents while they are running. The OWASP GenAI Security Project published it on September 1, 2026, in the same announcement that unveiled the 2026 Top 10 for LLM Applications (OWASP GenAI Security Project). It defines how an agent platform exposes hooks at moments in an agent's life, such as a tool call about to happen, a tool result coming back, or memory being written, and how an outside policy authority answers each one with allow, deny, modify, ask, or defer.

If somebody just handed you ACS and asked whether to adopt it, here is the practical version. Your agent controls today live inside whichever framework each team happened to pick, written in that framework's own idiom, and most of them are checked when the agent is configured rather than when it acts. ACS is an attempt to make one policy portable across frameworks and enforced at the moment of the action. As of October 13, 2026 the specification is still version 0.1.0, with three point releases of the project on top of it, the latest being 0.1.3, tagged October 5. It is something to design against, not something to deploy.

What the spec defines today

ACS sets out nineteen lifecycle hooks and five dispositions (allow, deny, modify, ask, defer), carried as JSON-RPC 2.0, with 44 JSON schemas published under the v0.1.0 namespace. Three of those hooks, for registering, loading, and unloading agent skills, joined the list in release 0.1.2 in September. It is organized around three pillars: Instrument, the hooks and dispositions above; Trace, which emits OpenTelemetry spans and OCSF events; and Inspect, an Agent Bill of Materials, or AgBOM, listing the models, tools, and data an agent can reach, published in CycloneDX, SPDX, or SWID format. Code is Apache 2.0, documentation is CC BY-SA 4.0 (agent-control-standard on GitHub).

The reference implementation is much narrower than the spec. It wires into Microsoft's Agent Governance Toolkit with host shims for Claude Code and OpenCode, and evaluates two hooks live: steps/toolCallRequest and steps/toolCallResult. The project names two gaps itself. The wire is not authenticated yet, tracked as issue #70, and the default failure posture is to proceed rather than to deny, tracked as issues #32 and #37. A control point that fails open is one you have to configure before you can lean on it. Release 0.1.3 also lowered the bar for conformance: support for the modify disposition is now recommended rather than required, and a client that cannot apply a modify has to treat it as a deny and record an audit event (ACS changelog). The next specification release, v0.2.0, is targeted for March 2027, with no date set for v1.0.

How it fits with the OWASP Top 10s

The 2026 Top 10 for LLM Applications, published August 3, 2026 (OWASP GenAI Security Project), moved Excessive Agency from sixth place to third, the largest climb on the list. That edition was scored 75 percent by practitioner voting and 25 percent by incident data, drawn from 7,714 records of which 6,639 carried enough detail to classify (ReversingLabs). Its companion list, the Top 10 for Agentic Applications published December 9, 2025, covers ten agent-specific categories from ASI01 Agent Goal Hijack through ASI10 Rogue Agents (OWASP GenAI Security Project).

Those documents name risks. ACS is the plumbing for doing something about them while the agent runs. Excessive agency is a permissions problem, and a permission that nothing checks at the moment of the call has already failed.

Where it sits against NIST and ISO

ACS does not replace either. The NIST AI Risk Management Framework and ISO/IEC 23894 describe outcomes to govern toward and leave the mechanism to you. ACS is a technical specification with hook names and a wire format, and it says nothing about governance structure. OWASP's own scoring work maps its agentic risk categories into NIST CSF, NIST AI RMF, ISO/IEC 27001 and 27002, and ISO/IEC 23894, which is the intended shape of the relationship: the frameworks set the objective, ACS is one way to meet a piece of it.

What to do with it now

• Inventory your agents the way an AgBOM would. For each one: the model, the tools, the data, and the downstream systems it can reach. That list is worth building whether or not you ever adopt the spec.
• Find out where tool permissions are actually enforced. If the answer is "at configuration," that is the gap ACS exists to close.
• Write down your failure posture. When the policy authority is unreachable or slow, does the action proceed or stop? The reference default is proceed, and the 2026 escape arc is a catalogue of what proceed looks like once the environment fails.
• Ask agent platform vendors which of the nineteen hooks they expose, which dispositions they honor, and whether they emit OpenTelemetry spans and OCSF events. Modify and ask are the two dispositions that quietly go missing, and since release 0.1.3 a product can skip modify and still call itself conformant.
• Ask the same vendors for a date, not a direction, on AgBOM output in CycloneDX, SPDX, or SWID.
• Treat v0.1.0 as an architecture to plan against. No published study yet shows that ACS deployments reduce successful attacks, and the wire is not authenticated.