OWASP Agent Control Standard: runtime enforcement gets a portable spec

What is this?

On 1 September 2026, the OWASP GenAI Security Project announced that the Agent Control Standard (ACS) had been donated to the project, alongside the 2026 edition of the Top 10 for LLM Applications. ACS is not a risk taxonomy — the Top 10 already fills that role. It is a technical specification for runtime governance of AI agents: it defines how agent platforms expose middleware hooks, and how safety policies can be enforced through those hooks as declarative controls that are portable across agent frameworks.

The project states the premise plainly: enterprises cannot rely on black-box agents operating across cloud, SaaS, on-premises and endpoint environments. To be trustworthy, an agent must be inspectable, traceable and instrumentable — you must be able to see what it is, what it can reach, what it did and why, and be able to constrain its behaviour while it runs rather than after the incident report.

The timing is not accidental. In the 2026 Top 10, published 3 August 2026, Excessive Agency climbed from sixth to third place, the largest upward move in the list. That edition was the first to weight its ranking against empirical evidence — per the Cloud Security Alliance’s 4 September 2026 research note, 75% practitioner consensus and 25% analysis of 6,639 documented real-world incidents. The message from the data is that the damage is rarely the text a model produced; it is the permissions the model happened to hold.

How it works

ACS describes an Agent Control System sitting between an observed agent and the systems it acts on. Per CSA’s analysis of the specification, it has three moving parts:

• Enforcement points. “Guardian agent” hooks that observe agent events and apply policy. The specification currently defines the core model; expanded protocol support for deny and modify actions across A2A and MCP is on the roadmap rather than shipped.
• An observability layer. Agent events traced through OpenTelemetry and the Open Cybersecurity Schema Framework (OCSF), so agent activity lands in the same pipelines a SOC already runs rather than in a vendor-specific console.
• An Agent Bill of Materials (AgBOM). A machine-readable inventory of an agent’s tools, models and accessible data, expressed through CycloneDX, SWID and SPDX.

The load-bearing idea is portability. Today, scoping what a LangGraph agent may do is a different engineering exercise from scoping a CrewAI or AutoGen agent, so policy is re-implemented per framework and drifts. A declarative control that any conforming platform can enforce is an attempt to break that pattern.

The maturity caveat matters. The specification is at version 0.1, covering core definitions. Instrumentation and reference guardian-agent samples are targeted for v1; full AgBOM mapper implementations for v2; deny/modify enforcement across A2A and MCP for v3.

Why it matters

Most agent security guidance published so far tells you what can go wrong. Very little of it standardises how you stop it once it starts. That gap is why prompt injection keeps converting into real impact: the injection is the delivery mechanism, but the blast radius is set by whatever the agent was already permitted to reach.

The AgBOM piece addresses something more mundane and more widespread. A large share of organisations running agents cannot answer basic inventory questions — which agents exist, which tools they hold, which data stores they can read. Without that inventory, no policy is enforceable, because there is nothing to enforce it against.

The honest assessment: at v0.1, with no reference implementation and no confirmed adoption from major framework vendors, ACS is an architecture to plan against, not a control you can deploy this quarter. Its value depends entirely on whether orchestration platforms implement the hooks.

Defenses

• Re-baseline your agent risk register against the 2026 ranking. A three-place jump for Excessive Agency, backed by incident data rather than opinion alone, is a signal to audit permission scope — not just prompt hygiene.
• Inventory now, formalise later. Map every deployed agent to the tools, data sources and downstream systems it can reach. This is independently useful and a precursor to any AgBOM adoption.
• Enforce scope at invocation time, not at configuration time. Permissions granted once and never reviewed are a recurring contributor to excessive-agency incidents. Check authorisation on each tool call.
• Extend confidentiality controls past the system prompt. The 2026 list retired System Prompt Leakage in favour of Hidden Context Exposure (#8), which also covers retrieved documents, agent memory, tool responses and application state. Controls built around protecting one static prompt no longer cover the surface.
• Put tracing requirements into procurement. Require that any agent framework under evaluation publishes a roadmap for OpenTelemetry/OCSF event tracing and component inventory, so conformance is not a retrofit.
• Treat guardian-agent enforcement as a design reference. Inspectability, traceability and instrumentability map cleanly onto obligations most organisations already carry under existing AI governance policy.

Status

This is a defensive standard release, not a vulnerability. No CVE is associated with this item.

Item	Detail
Standard	Agent Control Standard (ACS), OWASP GenAI Security Project
Donation announced	1 September 2026 (press release dated 2 September 2026)
Specification version	v0.1 — core definitions; v1/v2/v3 roadmap published
Components	Guardian-agent enforcement points; OpenTelemetry + OCSF observability; AgBOM via CycloneDX / SWID / SPDX
Roadmap targets	v1 instrumentation & reference samples · v2 AgBOM mappers · v3 deny/modify across A2A and MCP
Related release	Top 10 for LLM Applications 2026, published 3 August 2026
Ranking shift	Excessive Agency 6th → 3rd; System Prompt Leakage retired, replaced by Hidden Context Exposure (#8)
Methodology	75% practitioner consensus + 25% analysis of 6,639 documented incidents (per CSA research note, 4 September 2026)
CVE	None