We built the Agent Control Standard (ACS) in the open and never put a company gate on it. This month we went further and, after a brief stint at independence, handed it back to OWASP, where it belongs.
ACS is now an OWASP GenAI Security Project standard, released alongside the 2026 Top 10 for LLM Applications. Michael Bargury co-created it at Zenity. It was built completely open from the beginning as neither he nor this company has ever owned it, controlled it, or unilaterally defined its direction. That was the entire point of building it.
The clearest way to explain what changed is a diff. Its predecessor, the Agent Observability Standard (AOS), described itself in one line:
Making AI agents trustworthy by standardizing observability.
The ACS repository today reads:
Making AI agents trustworthy by standardizing observability and control.
Two words. They carry the entire reason the project needed a new name and a bigger home.
I'm one of four people at Zenity holding a named role inside the OWASP GenAI Security Project.
- I co-lead the OWASP Top 10 for LLM Applications, and I’m the lead for the ACS project
- Keren Katz co-leads the OWASP Top 10 for Agentic Applications
- Kayla Underkoffler, our Director of AI Security and Policy Advocacy, is entry lead for ASI01, Agent Goal Hijack
- Michael Bargury, our CTO and Co-Founder, leads OWASP's Low-Code/No-Code project and co-leads AIVSS, on top of co-creating ACS
Our AgentFlayer research is cited three times inside the Agentic Top 10: the ChatGPT connectors 0-click attack under ASI01, full data exfiltration in Copilot Studio under ASI02, and the 0-click memory exfiltration work under ASI06. All three of those attacks run through points where ACS puts a hook.
The “Spec” in ACS
ACS starts from three properties an agent needs before an enterprise should extend it any trust:
- It has to be inspectable, so you know which tools, models, and capabilities are in play, what version is running, and which data it can reach.
- It has to be traceable, so any action walks back to the reasoning and the originating task, even when the thread crosses several agents and systems.
- It has to be instrumentable, so you can hook into execution and steer it rather than reading about it afterward.
The architecture splits into an Observed Agent and a Guardian Agent. The observed agent exposes hooks at the points where something consequential happens, which means a hook fires when the agent takes input, calls a tool, retrieves from a knowledge base, writes to memory, executes code, or invokes a sub-agent. The Guardian Agent sits on the other side of that call and returns one of three verdicts: permit, deny, or modify. That third verdict is what makes this a control standard instead of a logging standard, because modify lets the guardian rewrite a tool call before it runs.
Putting that contract in a standard matters because almost nobody runs one agent platform. You've got Copilot across Microsoft 365, engineers running Claude Code, something built on AWS Bedrock, and a handful of homegrown agents nobody has inventoried yet. Every one of those ships its own guardrails, written in its own vocabulary and enforced at its own choke points, and none of them talk to each other. ACS describes a middleware layer that sits in the same place across all of them, so a policy about what a tool call may do gets written once instead of five times. Any platform that implements the hooks becomes governable on the same terms as the rest.
ACS extends standards that already exist rather than inventing replacements. Tracing rides on OpenTelemetry and the Open Cybersecurity Schema Framework (OCSF). The Agent Bill of Materials (AgBOM) extends CycloneDX, SWID, and SPDX to express what an agent is built from and to keep that current as components change. Instrumentation integrates with Model Context Protocol (MCP) and Agent-to-Agent (A2A). That restraint is an adoption argument. A security team already running OpenTelemetry and ingesting OCSF events doesn't have to stand up a second pipeline to see what its agents are doing.
The AOS Inheritance
Almost all of that carried over from AOS unchanged. The same three properties, the same Observed Agent and Guardian Agent split, the same permit-deny-modify verdict, the same decision to extend OpenTelemetry, OCSF, CycloneDX, SWID, and SPDX rather than compete with them. Read the two repositories side by side and the continuity is obvious.
What changed is scope, and the name followed it. AOS framed the problem as visibility, and visibility was never going to be the whole answer, because knowing an agent exfiltrated a customer list is a worse outcome than stopping it. Once the specification took on hooks that can deny and modify, calling it an observability standard undersold what it was asking platforms to build.
AOS was an OWASP project. ACS spun out to move quickly while the control scope took shape, and it shipped under an MIT license with no company gate on the specification from its first release. Openness wasn't a thing we bolted on at the end.
Coming back to OWASP buys the part an independent repository never could. The GenAI Security Project passed 30,000 members this year, which is 30,000 people who can read the schema, argue with where the hooks sit, build a guardian against their own stack, and tell us what breaks. A control standard carrying one security vendor's name has a credibility problem no license fixes, since that vendor benefits from where the hooks land. Putting it in front of a community that size means it gets reviewed by contributors who compete with us and by people who owe us nothing.
Why the Control Layer Got Urgent
The 2026 Top 10 for LLM Applications tested, for the first time, the ranking against a record of what has gone wrong. We assembled 7,714 real incidents from public vulnerability databases and an AI-harm database, classified the 6,639 that carried enough detail to sort, and weighed that evidence accordingly
Excessive Agency climbed from sixth to third, one of the most consequential moves on the list, because the vote and the incident record agreed that agentic deployments are where the damage is landing. The entry names three root causes and not one of them is a model defect. Excessive functionality means the agent holds tools the task never required. Excessive permissions means those tools connect with more authority than the job needs. Excessive autonomy means the agent commits to consequential actions with nobody confirming.
Michael framed it in the OWASP announcement as a containment problem, saying the work is to contain what a fooled agent can reach before it acts. Containment lands at the moment of action, which is why the specification puts a verdict in the path of the call.
Agency Doesn't Stop at LLM03
The third-place ranking undersells the reach. In Appendix A of the 2026 document we mapped every LLM risk onto the Top 10 for Agentic Applications, and Excessive Agency touches seven of the ten agentic entries: Agent Goal Hijack, Tool Misuse and Exploitation, Identity and Privilege Abuse, Unexpected Code Execution, Insecure Inter-Agent Communication, Cascading Failures, and Human-Agent Trust Exploitation. Prompt Injection reaches the same count of seven. No other entry on the list touches more than three.
Two risks out of ten carry most of the agentic attack surface between them, and one of the two is a permissions and autonomy failure rather than an input-handling failure. You can throw every injection classifier you own at the first one and the second stays exactly where it was.
The Agentic Top 10 pushes further with a term of its own. Least Agency extends least privilege and excessive agency into an instruction to avoid unnecessary autonomy, because putting agentic behavior where it isn't needed grows the attack surface. The same passage states that strong observability becomes non-negotiable, since without visibility into what agents are doing and which tools they're invoking, unnecessary autonomy quietly expands that surface until small problems become system-wide ones. That was written by the Agentic Top 10 working group, and it's a better case for a control layer than any vendor could make.
One more boundary decides which list you're reading. While the model is a component inside your application, the LLM Top 10 owns the risk. Once it becomes an actor, with tools it can call, memory it carries across sessions, and consequences it sets in motion downstream, the risk moves to the Agentic list. ACS is built for the second case.
What v0.1 Is, and What It Isn't
ACS sits at v0.1, public preview, so buyer beware if you plan on implementing against it.
v0.1 covers the documentation and requirements, the ACS definitions and schema, the observability definitions for OpenTelemetry and OCSF, and the AgBOM requirements. That's a specification you can read, argue with, and design against.
The rest is roadmap, and the sequence is public:
- v1 brings agent instrumentation, a Guardian Agent sample application, the OpenTelemetry and OCSF mappers, and FastMCP and A2A client instrumentation
- v2 brings the CycloneDX, SPDX, and SWID requirements and the AgBOM mappers
- v3 extends A2A and MCP to support deny and modify operations
Pay particular attention to that last point. The deny and modify verdicts are specified today, and the protocol work to carry them across A2A and MCP is two major versions out. Anyone telling you ACS gives you runtime enforcement across your agent estate today hasn't read the roadmap. It also demonstrates that ACS is tackling a huge challenge that you can’t “vibe code” around.
The Part Nobody Can Standardize Alone
A hook only exists if the platform builds it. ACS can specify where a hook belongs and what a guardian is allowed to say back, and none of it runs until the agent platform you bought exposes the call. That makes this a procurement question well before it becomes an engineering one, and it's the one place where 30,000 people asking the same thing moves a vendor roadmap faster than any specification can.
Which makes for an honest ask… v0.1 is a specification looking for the people who will break it: platform engineers who can implement hooks, security teams who can write policy against them, red teamers who can find the paths a guardian misses. Every one of those makes v1 better than anything we would have shipped on our own.
The work happens in the open. Request an OWASP Slack invite, then find us in #team-genai-asi-acs-general.