The OWASP GenAI Security Project has adopted the Agent Control Standard (ACS) into its portfolio of open projects. Worth clearing up first, because the announcement is being read wrong: ACS is not a tool, a library, or a policy engine. It is a protocol specification. It defines the wire format, the control points and the decision vocabulary an external process uses to intervene in an agent's execution. What that process decides, and on what logic, is not the standard's problem.
Put another way: ACS gives you the contract, not the product.
The gap it fills
Plenty has been standardised around agents in the last two years. MCP and A2A settled how they talk to tools and to each other. The OWASP Top 10 for Agentic Applications catalogued what can go wrong. What nobody had standardised is how you control an agent while it runs.
Today that lives inside each framework. LangChain has its callbacks, CrewAI has its own, every proprietary SDK picks whatever it likes. The result is a security policy welded to the framework: change stacks and you rewrite the controls; run three agent platforms and you maintain three implementations of the same rule, with no guarantee they agree.
ACS proposes pulling that logic out of the agent and putting it behind a shared protocol.
The two parties
The model has exactly two actors:
- Observed Agent — the LLM-backed system under supervision. It emits hook traffic and honours the decisions it receives.
- Guardian Agent — the decision point. It receives every step before execution and returns a verdict.
The Guardian is defined with two internal layers, and the order matters: a deterministic layer (OPA/Rego, Cedar) that always runs first, and an agentic LLM layer invoked only when the deterministic layer explicitly delegates. The LLM layer is optional — a deterministic-only deployment is fully conformant.
That's a welcome design decision. Putting an LLM in charge of policing another LLM as the primary control moves the problem rather than solving it, and the standard doesn't force you into it.
Sixteen hooks, and they fire first
v0.1.0 defines 16 lifecycle hooks: sessionStart / sessionEnd, agentTrigger, userMessage, agentResponse, turnStart / turnEnd, toolCallRequest / toolCallResult, knowledgeRetrieval, memoryContextRetrieval, memoryStore, preCompact / postCompact, and subagentStart / subagentStop.
The property that makes them useful is written into the toolCallRequest schema itself:
Fires before tool execution. Primary enforcement gate.
This isn't telemetry you review the next morning. The step halts, gets adjudicated, and only then executes. The hook coverage also tells you a lot about how mature the threat model is: memoryStore and memoryContextRetrieval existing means persistent-memory poisoning is in scope, which is one of the nastier vectors in long-running agents. preCompact and postCompact existing means they've thought about what happens when the context is compressed and something slips into the summary.
Five verdicts, not two
This is where it diverges from a classic guardrail. The Guardian doesn't answer yes or no:
| Verdict | What it means |
|---|---|
allow | The step proceeds. |
deny | The step is blocked. |
modify | The step runs with arguments the Guardian altered. |
ask | It escalates to a human approver before continuing. |
defer | The decision is postponed. |
modify and ask are the ones that change the game. modify lets you sanitise a call instead of killing it, which in production is the difference between a control that stays switched on and one the team disables within a week over false positives. And ask makes human approval part of the protocol, with state, rather than a patch bolted on top.
The schema also requires the reasoning field on deny, modify, ask and defer. Any decision that interrupts the agent has to arrive explained.
The three pillars
| Pillar | What it brings |
|---|---|
| Instrument | The hooks and the verdicts. The only mandatory one (ACS-Core). |
| Trace | Every hook mapped to OpenTelemetry spans and OCSF event classes. The verdict is emitted as a span event on the span of the step it gates, so the decision and the action share a parent. |
| Inspect | AgBOM: a dynamic bill of materials for the agent (models, MCP servers, A2A peers, tools, knowledge sources, memory stores), derivable to CycloneDX, SPDX or SWID. |
On top sit optional profiles declared in the handshake: ACS-Provenance, ACS-Crypto (HMAC-SHA256 baseline, ML-DSA-65 and SLH-DSA-128s for post-quantum, hybrid composites for the transition) and ACS-Audit (request_hash on every entry, so the SHA-256 chain commits to request content rather than just step metadata).
The AgBOM deserves separate attention. An SBOM tells you which libraries your software ships. An AgBOM tells you what your agent can do right now: which model sits behind it, which MCP servers it has wired up, which sources it can reach. And it reports mutations, which is the part that matters when someone adds a tool on a Tuesday afternoon.
The two pieces that actually matter
If you only read two sections of the specification, make it these.
Field-level provenance. Every data-bearing field can carry a Provenance object with origin, source_id and derived_from (the lineage). The key rule is who populates it: deterministic framework code at channel boundaries, never the LLM. That's exactly right. A model classifying the trustworthiness of its own input is the same model you're trying to protect from that input; if the attacker controls the text, they control the label too. Keeping provenance out of the LLM's reach is what makes FIDES- and CaMeL-style enforcement hold up.
Immutable Intent. The Guardian holds the session state, and optionally an Intent: the structured authorisation for what that session may do. Once established, Intent.parsed is immutable to the runtime LLM and to untrusted data, and grows only through approver action via the ask flow.
That rule is the direct answer to indirect prompt injection, LLM01 in the OWASP LLM Top 10. The attack works by having a retrieved document widen what the agent believes it's authorised to do. If scope can only widen through a human, poisoned text has nowhere left to escalate. The network-level version of the same idea is in an offensive agent won't respect a scope that isn't in the network: a boundary that is assumed rather than enforced is not a boundary.
The small print
It's a v0.1.0 public preview, and it should be read as one:
- There is no reference implementation. What exists today is the specification and the JSON schemas. The sample Guardian and the FastMCP and A2A instrumentation are planned for v1.
- Real enforcement over MCP and A2A lands in v3. Extending those protocols to support
denyandmodifyis outstanding work. Theprotocols/A2A/*namespace is reserved in v0.1 and its wrapping spec arrives in v0.2. If someone sells you "ACS-compatible" this year, what you're buying is traceability and shared vocabulary, not a control that stops anything. - It ships no policies. What gets blocked and on what criteria stays yours, and that's the hard part.
- The specification says so itself: ACS-Core authenticates the channel and binds the agent to the Guardian's decisions, but on its own it does not make a deployment secure or its policies strict. Tamper-evidence against a compromised Guardian is the Crypto and Audit profiles, not Core.
- There's a latency cost. Every step goes through an external process before executing. Tolerable in a tool-calling agent, but a real design variable.
What to do with this if you run agents today
- Read it as a threat model before reading it as a standard. The list of 16 hooks is, in practice, an inventory of the points where your agent can be manipulated. If your architecture has no control on memory writes or subagent spawning, you've just identified two gaps without adopting anything.
- Start with the AgBOM. It's the cheapest artefact to produce and the fastest to pay off: knowing which tools and sources your agent has right now.
- Separate policy from framework. Even if you never implement the protocol, moving your rules into an external deterministic layer (Cedar, Rego) is the decision that leaves you aligned the day you want to adopt it.
- Don't accept anyone's conformance claim yet. The profiles are declarative and verifiable. Ask which one is implemented, not whether they "support ACS". And for whatever is implemented, the next question is how anyone shows it works — which is what the red/blue loop is about.
The compliance bridge
A versioned AgBOM plus a verifiable audit chain covers a good part of what Regulation (EU) 2024/1689 asks of high-risk systems as technical documentation (Art. 11) and event logging (Art. 12), and it lines up with what an ISO 42001 auditor will want on operational control. There is no official mapping between ACS and either one, so don't present it as such — but the evidence the protocol produces is exactly the kind you need to generate. What the Regulation demands and from when is broken down in what the AI Act requires in August 2026; if it applies to you, you can check which category your system falls into with the EU AI Act risk calculator.
Where our own work fits
We work on the role ACS calls the Guardian Agent. DELIA is our detection and response layer for LLM, RAG and agentic pipelines — the category known as AIDR: it intercepts inline per hop, returns a verdict in milliseconds, and exports evidence to SIEM and SOAR in OCSF, over OpenTelemetry.
The principles line up with the specification's, and not by coincidence: they're the conclusions anyone reaches trying to stop indirect injection in production. A retrieved chunk's trust level is derived from its source and set by deterministic code, not the model. The decision is made before the action reaches the destination system. And the trace comes out in a format your SOC already reads.
The most literal parallel is the verdict ACS calls ask. In the console it is an approval queue: the tool call is held, with the rule that triggered it in view, and it does not move until a person decides.
What we're not going to claim is that DELIA is ACS-conformant. The specification has concrete profiles, with a declared handshake and schemas to validate against, and as of today we don't implement them. What we are evaluating is aligning the trace layer with ACS-Trace, which is the cheapest part to make real precisely because we already emit OCSF and OpenTelemetry, and following the project's work from the inside.
An open standard with OWASP governance describing this architecture has concrete value for anyone building it: you no longer have to invent the vocabulary to explain to a CISO why the control belongs outside the agent and ahead of the action.
DELIA is in R&D at the lab, sovereign and self-hostable. If you run LLM, RAG or agents in production and want to see what it intercepts on your own pipeline, book a demo.