The OWASP Agent Control Standard (ACS) is an emerging open wire specification for controlling AI-agent behavior at runtime. Its core idea is to separate the agent that wants to act from the component that decides whether the action is permitted. An Observed Agent emits standardized hooks and a Guardian Agent evaluates policy before the action continues.
ACS was donated to the OWASP GenAI Security Project and publicly highlighted on September 1, 2026. It is designed to make agent controls portable across frameworks instead of requiring every enterprise to build a different enforcement integration for every agent platform. That is an important goal—but ACS is also early-stage. Enterprises should distinguish the specification from individual reference implementations and validate concrete conformance claims before production adoption.
What Is the OWASP Agent Control Standard?
ACS defines a common contract between an AI agent and an independent runtime control point. The agent exposes execution events—such as session activity, tool calls, retrieval, memory operations, and responses—through structured hooks. The Guardian evaluates those events against policy and sends back a disposition that the observed agent is expected to honor.
This addresses a practical problem in agentic AI: powerful agents increasingly operate across SaaS, cloud, on-premises systems, developer endpoints, browsers, MCP servers, APIs, and other agents. Without a common control interface, security policy becomes framework-specific and difficult to audit consistently.
ACS Status in September 2026
The OWASP GenAI Security Project resource page dates ACS to September 1, 2026. The current repository describes specification v0.1.0 and a tagged release of v0.1.1. It also states that v0.2.0 is targeted for March 2027 and that no v1.0 date has been set.
That versioning matters. The architecture is concrete enough to evaluate and prototype, but the project is intentionally transparent about current gaps and evolving work. The v0.1.0 conformance model is self-declared: there is no third-party steward currently validating that an implementation which advertises an ACS profile actually satisfies every requirement.
For procurement, avoid a binary “supports ACS” checkbox. Ask which specification version is supported, which profiles are implemented, which hooks are emitted, whether decisions are honored correctly, what failure posture is configured, and what evidence proves those claims.
How ACS Works: Observed Agent, Guardian, Hook, Decision
Two logical parties speak ACS:
- Observed Agent: the LLM-backed system being governed. It emits standardized hook requests at defined points in its lifecycle.
- Guardian Agent: the external policy decision point. It receives the hook, evaluates policy and context, and returns the disposition.
A useful mental model is intercept → decide → enforce → record. Before a tool call, for example, the observed agent sends the relevant action and context to the Guardian. The Guardian can permit it, block it, alter parameters, send it for approval, or defer the result. The observed agent then applies that decision before the tool executes.
| Disposition | Meaning | Example enterprise use |
|---|---|---|
| ALLOW | Proceed as requested | Read-only lookup within approved scope |
| DENY | Do not perform the action | Block destructive command or prohibited endpoint |
| MODIFY | Change the request before execution | Reduce query scope, remove a risky field, cap a parameter |
| ASK | Route to a human, service, or other approver | Require approval for a payment, delete, or sensitive export |
| DEFER | Postpone the final verdict | Wait for additional context or another decision dependency |
This structure moves important security decisions out of prompt text and into a control path that can be deterministic, observable, and centrally governed.
The Three ACS Pillars: Instrument, Trace, Inspect
Instrument
Expose agent lifecycle hooks and receive Guardian dispositions. This is the active runtime-control plane: it creates the point where policy can permit, block, change, or escalate behavior.
Trace
Represent agent activity and decisions in standardized observability formats. ACS defines profiles around OpenTelemetry and OCSF so existing monitoring and SIEM tooling can consume the trail.
Inspect
Describe what the agent is made of through an Agent Bill of Materials (AgBOM), including models, tools and dependencies, with serialization options such as CycloneDX, SPDX and SWID.
ACS-Core is the mandatory foundation. Trace and Inspect can be layered on through declared profiles. This matters operationally because an organization can start with control-path instrumentation, then add richer observability, inventory, provenance, stronger cryptography, and audit assurances as needed.
What ACS-Core Requires
The current v0.1.0 conformance documentation defines ACS-Core as the mandatory baseline. Important elements include:
- Handshake: the client and Guardian negotiate capabilities and profiles.
- JSON-RPC 2.0 envelopes with ACS extensions: requests carry identifiers, timestamps, version and metadata.
- Lifecycle hooks: a baseline covers session start/end, user or agent trigger events, tool-call request/result and agent response, with additional normative hooks for turns, retrieval, memory, subagents, compaction and skills.
- All five dispositions: allow, deny, modify, ask and defer.
- Session context and intent: append-only context supports reconstructing what happened and why.
- Replay protection: unique request IDs and timestamps are required and Guardians must reject replays.
- Baseline message integrity: ACS-Core specifies HMAC-SHA256 over canonical envelopes using per-session key derivation.
- Decision honoring: the observed agent must wait for and apply the Guardian decision up to a negotiated timeout.
- Liveness: a ping mechanism supports health checking.
- Wrapped MCP support: the core specification defines a way to instrument MCP-related actions.
Core conformance says something specific: the control channel follows the ACS baseline and the observed agent honors Guardian decisions. It does not mean the organization wrote good policies or that a permissive Guardian is secure. Correct plumbing and effective policy are different concerns.
ACS Conformance Profiles
Beyond ACS-Core, deployments can declare optional profiles. The current documentation describes the following set:
| Profile | Adds | Why it matters |
|---|---|---|
acs-core | Wire format, hooks, dispositions, baseline integrity and decision honoring | Mandatory control foundation |
acs-trace | OpenTelemetry and/or OCSF trace events | Cross-vendor observability and SIEM integration |
acs-inspect | AgBOM snapshot and standardized serialization | Policy based on models, tools and component inventory |
acs-inspect-dynamic | Inventory-change events during a session | Agents that hot-swap tools, models, skills, or MCP servers |
acs-provenance | Field-level origin and derivation metadata | Information-flow and trust-aware enforcement |
acs-crypto | Asymmetric/post-quantum signature options beyond Core HMAC | Higher-assurance integrity and external verifiability |
acs-audit | Request-content hashes in the audit chain | Stronger evidence that the chain commits to actual request content |
Profiles are composable. A deployment can be Core-only or combine Trace, Inspect, Provenance, Crypto and Audit depending on risk. However, v0.1.0 profile claims are self-declared, so buyers should require test evidence rather than relying only on a feature label.
How Policy Evaluation Is Intended to Work
ACS does not require the Guardian to be another generative model. The project explicitly supports a deterministic policy layer—such as a policy engine evaluating written rules—as the primary decision mechanism. A conformant deployment can remain deterministic-only.
The reference design also allows optional delegation to an LLM-based agent layer when deterministic logic cannot resolve a request. In that pattern, deterministic policy remains the outer control layer: it decides what context can be delegated and checks the returned result before the final disposition leaves the Guardian.
That is a useful security property because it avoids making the same probabilistic component both the subject of governance and the ultimate authority over its own permissions. High-impact decisions should remain anchored in explicit policy, user authority, task scope, data classification, tool capability and risk.
Agent wants to call tool
↓
Emit tool-call request hook
↓
Guardian evaluates identity + task + tool + arguments + policy
↓
ALLOW | DENY | MODIFY | ASK | DEFER
↓
Observed agent honors decision
↓
Record context, policy reference and outcomeFailure Posture, Authentication, and the Reference Implementation
Security teams should pay close attention to failure behavior. The ACS-Core specification supports an on_decision_failure posture and documents proceed as the default. In other words, if the Guardian times out or the control channel fails, a deployment can fail open unless it is configured otherwise. For high-risk actions, enterprises may prefer a deny-on-failure posture, but that decision must account for availability and operational impact.
It is equally important to distinguish the specification from the current reference implementation. The project’s own README states that the reference Guardian does not yet implement the baseline wire authentication required by ACS-Core and currently defaults to fail-open. Those are disclosed implementation gaps, not a statement that the ACS-Core specification omits authentication.
Before production use, validate at least four things: the channel is authenticated as required, the observed agent really honors decisions, the selected failure posture matches the business risk, and logging cannot become a bottleneck or leak sensitive context.
How ACS Relates to MCP and A2A
MCP, A2A, and ACS solve different problems. MCP standardizes how AI applications connect to tools and context. A2A standardizes communication and collaboration between agents. ACS focuses on control: where an agent exposes hooks so a Guardian can inspect and govern behavior at runtime.
These protocols can therefore be complementary. An enterprise agent might discover or invoke tools through MCP, communicate with a remote agent through A2A, and expose ACS hooks around those actions so policy can evaluate them before execution. The ACS documentation includes explicit instrumentation concepts for MCP and A2A rather than positioning ACS as a replacement for either protocol.
Protocol support alone still does not establish security. Teams must bind agent identity, user authority, task intent, tool/API scope, credentials, data policy, and runtime evidence across the full chain.
Enterprise ACS Evaluation Checklist
- Record the exact version. Ask whether the implementation targets ACS v0.1.0 and which tagged software release provides it.
- List declared profiles. Require an explicit statement for Core, Trace, Inspect, Inspect-Dynamic, Provenance, Crypto and Audit.
- Verify hook coverage. Confirm which lifecycle events the agent actually emits—not only which hooks exist on a product roadmap.
- Test all dispositions. Demonstrate allow, deny, modify, ask and defer with observable enforcement outcomes.
- Prove decision honoring. Attempt to bypass or ignore a Guardian decision and confirm the observed agent does not proceed incorrectly.
- Inspect failure posture. Simulate timeout, unreachable Guardian, malformed response and startup/handshake failure. Decide where fail-open is unacceptable.
- Verify channel integrity. Confirm signatures, key management, replay rejection and transport security match the claimed profile.
- Validate identity and authorization. Ensure policies can distinguish agent, user, tenant, task, tool and environment rather than relying on a shared agent identity.
- Review trace output. Confirm decisions and relevant context reach OpenTelemetry/OCSF/SIEM without exposing unnecessary secrets or creating excessive latency.
- Review AgBOM accuracy. If Inspect is claimed, compare the declared model/tool/dependency inventory with the live environment and test dynamic changes.
- Measure decision-path latency. Runtime governance sits in the action path; test normal, high-load and failure conditions.
- Require evidence for conformance claims. Because v0.1.0 has no independent certification, document how the implementer tested every claimed requirement.
How Ammune Can Complement an ACS-Based Agent Security Architecture
ACS focuses on the agent control contract. Ammune is relevant to a different but complementary layer: the live API traffic agents generate when they call enterprise services. Runtime API visibility can help security teams observe which endpoints an agent reached, what data moved in requests and responses, how behavior changed, and whether sensitive APIs or unusual sequences need investigation or enforcement.
A practical architecture can therefore combine agent-native control hooks with API-native runtime evidence. ACS can expose why an agent intended to perform an action and what disposition the Guardian returned; API security can show what request actually reached the service and what response came back.
For related guidance, see AI agent API security risks, API visibility for AI agents, and API runtime security protection.
Frequently Asked Questions
What is the OWASP Agent Control Standard?
ACS is an open wire specification for runtime AI-agent control. An observed agent emits standardized hooks to a Guardian that evaluates policy and returns a decision before the action proceeds.
When did ACS become part of the OWASP GenAI Security Project?
The OWASP GenAI Security Project announced ACS as a project resource on September 1, 2026 and stated that the standard had been donated to the project.
What are the five ACS decisions?
The five dispositions are ALLOW, DENY, MODIFY, ASK and DEFER. They let a Guardian permit an action, block it, rewrite it, route it for approval, or postpone the verdict.
What are the three ACS pillars?
They are Instrument, Trace and Inspect. Instrument provides hooks and control decisions; Trace provides standardized observability; Inspect provides an Agent Bill of Materials for models, tools and dependencies.
What is ACS-Core?
ACS-Core is the mandatory v0.1.0 baseline. It covers the handshake, request/response envelopes, hook taxonomy, dispositions, context chain, replay protection, baseline message integrity, decision honoring, liveness and related core behavior.
Is ACS v0.1.0 independently certified?
No. The current conformance documentation says profile claims are self-declared and that v0.1.0 has no third-party conformance registry or steward that independently verifies implementations.
Does ACS require an LLM-based Guardian?
No. Deterministic-only Guardians are supported. An implementation may optionally use an LLM-based decision layer, but the project describes deterministic policy as the control layer that runs first and validates the final result.
Does ACS fail closed by default?
No. The current Core documentation describes a default decision-failure posture of proceed, or fail-open. High-risk deployments should deliberately evaluate whether to change that behavior and test failure scenarios.
Does ACS replace MCP or A2A?
No. MCP is mainly about connecting AI applications to tools and context, A2A is about agent-to-agent interoperability, and ACS is about runtime control and observability. They can be used together.
What should enterprises verify before adopting ACS?
Verify the specification version, supported profiles and hooks, decision enforcement, failure posture, channel authentication, replay protection, identity context, trace quality, latency, inventory accuracy and evidence behind every conformance claim.
Authoritative References
Connect agent control with runtime API evidence
As AI agents gain access to enterprise APIs, security teams need both agent-level policy decisions and visibility into the requests, responses, data and behavior those agents produce at runtime.