OWASP Agent Control Standard Guide: runtime hooks, Guardian decisions and conformance profiles

Most agent platforms give security teams no standard way to stop an action before it happens, so every framework ends up with its own bespoke guardrail plumbing. The OWASP Agent Control Standard (ACS) is an attempt to fix that: a wire specification that lets a separate policy service, the Guardian Agent, inspect what an AI agent is about to do and allow, deny, modify, escalate or defer it, with an audit trail that can be reconstructed afterwards. This guide explains what ACS v0.1.0 actually specifies, what its conformance profiles mean, where identity and non-human identity (NHI) controls fit, and how to pilot it without trusting claims the standard itself says nobody verifies yet. It is written for platform engineers, AI security architects and IAM teams evaluating agent runtime controls. Status was checked against the project repository and OWASP pages on 27 October 2026.

Key takeaways

• ACS is a wire contract, not a product. It defines JSON-RPC 2.0 messages between an Observed Agent and a Guardian Agent; the policy engine, crypto suite, operating system and transport stay your choice.
• It is early. Specification v0.1.0 was published on the OWASP GenAI Security Project resources page on 1 September 2026, the repository was at release 0.1.4 on 16 October 2026, and v0.2.0 targets March 2027 with no v1.0 date set.
• ACS-Core is the mandatory floor. Handshake, envelope, a minimum hook set, four MUST-support dispositions, a hash-chained session context, replay protection, an HMAC-SHA256 baseline signature and decision honouring. Trace, Inspect, Provenance, Crypto and Audit are optional profiles.
• The default failure posture is fail-open. If the Guardian is slow or unreachable the agent proceeds unless the deployment sets on_decision_failure to deny. Change it before you rely on ACS as a control.
• Conformance is self-declared. In v0.1.0 there is no test suite, registry or steward body, so "ACS-Core conformant" is a vendor assertion you must test yourself.

What it is and who it applies to

ACS describes itself as the open foundation for making agents "inspectable, traceable and instrumentable". The OWASP resource page says it is now part of the OWASP GenAI Security Project and that it defines how agent platforms expose middleware hooks through which safety policies are enforced, so that declarative controls are portable across agent frameworks and enforced at runtime. The specification, JSON Schemas and a reference implementation live in the GenAI-Security-Project/agent-control-standard repository on GitHub. Code and schemas are Apache License 2.0; documentation is CC BY-SA 4.0.

Two parties speak ACS. The Observed Agent is the LLM-backed system under governance. It pauses at defined points in its execution, called hooks, and sends a request. The Guardian Agent receives the request, evaluates it against policy and returns a disposition. A Guardian can be a sidecar, a local process or a remote service.

• Agent framework and platform builders: implement the hooks and honour decisions. This is where most of the normative text lands.
• Security and platform teams running agents: deploy and operate the Guardian, write policy and consume the audit trail.
• Buyers of agent security tooling: use the conformance profiles as a vocabulary for requirements, while remembering that claims are unverified.
• IAM and NHI teams: supply the identities the handshake binds and the delegation context policy decisions depend on.

ACS sits below the OWASP risk lists. The OWASP Top 10 for Agentic Applications Guide says what goes wrong; ACS defines a mechanism for intercepting the actions those risks produce. For the broader control landscape around agents, see the Agent Controls and Monitoring Guide.

Structure and key requirements

ACS organises its requirements into three pillars. Instrument covers hooks, the handshake and dispositions. Trace records each hook and decision as an OpenTelemetry span and an OCSF event. Inspect produces the AgBOM, a live inventory of the agent's models, tools and dependencies.

The 19 native hooks

The steps/* namespace defines 19 lifecycle hooks: sessionStart, agentTrigger, turnStart, userMessage, agentResponse, knowledgeRetrieval, memoryContextRetrieval, memoryStore, toolCallRequest, toolCallResult, preCompact, postCompact, subagentStart, subagentStop, skillRegister, skillLoad, skillUnload, turnEnd and sessionEnd. MCP traffic is wrapped under protocols/MCP/*; the protocols/A2A/* namespace is reserved, with wrapping deferred to v0.2. ACS-Core requires at least sessionStart, userMessage or agentTrigger, toolCallRequest, toolCallResult, agentResponse, sessionEnd and, for frameworks that spawn sub-agents, subagentStart.

The five dispositions

DEFER carries a reason (insufficient_context, conflicting_policies, low_confidence, pending_dependency), a resolution_timeout_ms and a timeout_decision that defaults to deny. That default is deliberately the opposite of on_decision_failure, which defaults to proceed: a Guardian that flagged a concern and could not resolve it fails closed, while a Guardian that never answered fails open unless you change the posture.

ACS-Core and the profiles

Profiles are declared in the handshake: the client sends profiles_supported, the Guardian answers with profiles_accepted, and a Guardian may refuse a session that lacks a profile its policy requires.

Other normative points worth knowing

• Decision honouring (section 6.4): the Observed Agent must wait for the verdict up to the negotiated timeout and apply it. Every decision failure, fail-open or fail-closed, must be recorded as an audit event.
• Replay protection (section 10.3): Guardians must reject timestamps outside the negotiated skew_window_ms (recommended default 300000, five minutes) and duplicate request_id values within a session.
• Deterministic first: a policy engine such as OPA/Rego or Cedar always evaluates first. A chain may delegate to an LLM layer, which never reads the policy source and whose answer must clear the deterministic layer again. Deterministic-only deployments are fully conformant.
• Intent immutability (section 8.4): where intent is used, Intent.parsed is fixed once the session starts and may grow only through an approver's intent_extension via ASK. Attempts by the model, tool outputs or untrusted channels to change it must be ignored or rejected.
• The agent must not know about hooks: provenance fields are populated by deterministic framework code at channel boundaries, never by the LLM.
• Deferred to v0.2: streaming, recursive ASK and quorum approval, multi-tenant isolation rules (tenant_id is only reserved), A2A wrapping and AgBOM federation.

Identity and NHI requirements

ACS is deliberately agnostic about identity mechanisms, and that is the part IAM teams most need to understand. The concepts page states that ACS mandates no authentication mechanism: the mechanism in use is declared at the handshake, and trust schemes such as SPIFFE, OIDC, DID, organisational PKI or quorum signing are deployment-defined. Identity descriptors carry a type discriminator (examples given are posix_uid, windows_sid, oauth_subject and cert_subject) and ACS reads only that discriminator.

The repository also holds an Identity workstream document, explicitly marked as a working document with no wire format or normative requirements yet. It names five runtime identity challenges: chain integrity across delegation, over-privilege from standing service accounts and long-lived API keys, token theft resistance when tokens sit in agent memory, last-mile enforcement at the resource, and proof of intent. Its standards page positions ACS as the runtime enforcement layer that consumes identity produced elsewhere, with DPoP or mTLS sender-constrained tokens and WIMSE identifiers proposed. Proposed token lifetime ceilings (15 minutes for LLM, 5 minutes for MCP, 60 seconds for high-risk actions) are listed as open work items, not requirements. Do not cite them as ACS requirements.

In practice this means ACS does not fix agent identity for you. If every agent runs under one shared service account, the Guardian's decisions and the trace will attribute everything to that account. Build the identity layer first: see the Agent Identity and Access Guide, the WIMSE for AI Agents Guide and the DPoP Guide. For carrying the user and call chain through to downstream services, see the OAuth Transaction Tokens (Txn-Tokens) Guide.

Implementation steps

1. Pick one agent and one hook. Start with toolCallRequest and toolCallResult on a coding or internal operations agent. The project's own reference implementation evaluates only these two methods live, which is a realistic first scope.
2. Stand up a Guardian in observe mode. Return ALLOW for everything but log every request and the verdict your policy would have returned. Run for two to four weeks to build a baseline of tools, arguments and destinations.
3. Write deterministic policy first. Express rules in OPA/Rego or Cedar: destructive shell commands, writes outside the workspace, egress to unknown domains, unbounded queries. Keep any LLM judge as an optional second layer. See the Policy-as-Code for Authorisation Guide.
4. Fix the failure posture and authenticate the channel. Set on_decision_failure to deny for any agent that can change production systems, and implement the baseline HMAC-SHA256 signature. The reference Guardian, at the time of checking, implemented neither by default (tracked as issues #70, #32 and #37 in the repository).
5. Turn on DENY and MODIFY in a pilot ring. Enforce on a small group of users, measure false positives, and keep a documented rollback: switching the Guardian back to observe mode, not removing the hook, so the audit trail continues.
6. Add ASK for high-impact actions. Route payments, deletions, permission changes and external messages to authenticated approvers. Watch approval volume; if approvers rubber-stamp, tighten deterministic rules instead. See the Human-in-the-Loop for AI Agents Guide.
7. Wrap MCP. If sessions use MCP at any point, route protocols/MCP/* through the Guardian. The specification names protocols/MCP/resources/read as the canonical prompt-injection ingress for attacker-controlled content, so do not leave it unwrapped.
8. Add profiles as needs appear. ACS-Trace when the SOC needs the data, ACS-Inspect when policy depends on which model or MCP server is loaded, ACS-Audit when evidence must commit to request content.

Small vs large organisations: a small team can run one Guardian with a deterministic rule set and ACS-Core only. A large organisation running several agent frameworks gets the most value from ACS's portability: one policy service and one audit format across frameworks. It should also pin the specification release it tests against, because release 0.1.4 changed the Trace rules in place under the same /schema/v0.1.0/ URIs.

Evidence and assessment

Because nobody verifies a conformance claim in v0.1.0, treat every claim as a hypothesis and collect your own evidence. The repository includes a conformance claim template and a conformance harness (bun run conformance) for the reference tree; use the same approach against any vendor implementation.

Detection and measurement

• Hook coverage: share of tool calls in target-system logs that have a matching toolCallRequest. Anything below 100% is a bypass.
• Fail-open count: decision failures under the proceed posture per week. The target is zero for production-capable agents.
• Disposition mix: rate of DENY, MODIFY, ASK and DEFER per agent; sudden changes point to new behaviour or a broken policy.
• ASK approval rate and latency: near-100% approval suggests rubber-stamping.
• Decision latency (p95): high latency drives teams to raise timeouts or switch the Guardian off.
• Attribution completeness: share of events carrying a unique agent_id and a user principal rather than a shared account.

ACS-Trace maps steps to OCSF 1.9.0 classes: session and sub-agent hooks to Authentication (3002), turns and messages to Application Lifecycle (6002), tool calls to Process Activity (1007), skill load and unload to Module Activity (1005), retrieval and memory to Datastore Activity (6005), non-allow decisions to Detection Finding (2004) and AgBOM events to Device Inventory Info (5001). Since 0.1.4 a decision event records the Guardian's verdict, not the enforced outcome; a matching acs.decision.failure means the decision must not be counted as enforced. Build SOC queries on that rule. See the OpenTelemetry GenAI Semantic Conventions for Security Teams and the AI Agent Observability and Incident Response Guide.

Mapping to other frameworks

Against the OWASP risk lists, ACS hooks give an enforcement point for tool misuse, goal hijack through injected content and identity abuse in the OWASP Top 10 for Agentic Applications Guide, and for OWASP LLM Top 10 LLM06 Excessive Agency Guide. For management-system context, ACS evidence can support an AI management system under the ISO/IEC 42001 Guide.

Common pitfalls

• Leaving fail-open in production: the default on_decision_failure is proceed. A crashed Guardian silently stops governing, which is exactly when an attacker benefits.
• Buying on a conformance claim: v0.1.0 has no test suite or registry. Run the evidence tests above before accepting "ACS-Core conformant" in a contract.
• Hooking tool calls but not content ingress: injected instructions arrive via retrieval, memory and MCP resources. Without knowledgeRetrieval, memoryStore and wrapped MCP, the Guardian sees the action but not why it happened.
• Using an LLM judge as the only layer: ACS expects deterministic policy first. A model judging another model's output is a probabilistic control and is itself injectable.
• Shared identities behind the hooks: if agent_id resolves to one service account across many agents, decisions cannot be scoped and the audit trail cannot answer who did what. See the NHI Ownership Guide.
• Not pinning the release: schema files at the v0.1.0 URIs changed in place in 0.1.4. Record the repository release or commit your implementation and SIEM parsers were tested against.

Practitioner checklist

• Record the ACS specification version and repository release you assessed, and the date.
• Give every Observed Agent a unique identity and bind it at the handshake; never reuse a human account.
• Implement toolCallRequest and toolCallResult first, then content-ingress hooks and wrapped MCP.
• Set on_decision_failure to deny for any agent able to change production data or systems.
• Enable and test the HMAC-SHA256 baseline signature and replay protection; store the key material in a vault.
• Write deterministic policy in a policy-as-code engine, with version control and named reviewers.
• Require authenticated approvers for ASK and monitor approval rates for rubber-stamping.
• Run the evidence tests in this guide against any vendor claiming ACS conformance.
• Ship Trace events to the SIEM and alert on every acs.decision.failure.
• Track hook coverage, fail-open count and decision latency as standing metrics.

Standards and references

• OWASP GenAI Security Project: Agent Control Standard (ACS)
• OWASP GenAI Security Project: Agent Control Standard repository (specification, schemas and reference implementation)
• OWASP GenAI Security Project: Top 10 for Agentic Applications for 2026
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATLAS: AI Agent Tool Invocation

Related NHI Mgmt Group resources: Agent Controls and Monitoring Guide · Agent Identity and Access Guide · OWASP Top 10 for Agentic Applications Guide · Human-in-the-Loop for AI Agents Guide