OWASP Agent Control Standard (ACS): Runtime control for AI agents

From answer generator to actor

Classic LLM applications generate text that a human reads before anything happens. AI agents, by contrast, plan autonomously, call tools, write to long-term memory and spawn subagents. Each of these steps can change data or send it outside. The control question is therefore: “May exactly this action, with exactly these arguments, take place in this session right now?” It can only be answered at runtime — between the model’s decision and its execution by the framework.

System prompts are not controls

Many deployments rely on system-prompt instructions such as “do not delete production data”. Such sentences are requests to a probabilistic system, not enforced rules. The ACS project page opens its rationale on exactly this point: system prompts are not controls, better models do not cover edge cases and adversarial inputs, and proprietary guardrails create vendor lock-in.

Vendors and researchers confirm this. On 22 December 2025, OpenAI wrote that prompt injection is “unlikely to ever be fully ‘solved’”. In the study “The Attacker Moves Second” (arXiv, 10 October 2025), adaptive attacks overcame twelve recent defences, mostly with success rates above 90 per cent — even though most of them had originally reported rates close to zero. Model robustness lowers the risk but does not eliminate it. What is needed is an independent control point outside the model.

Lethal trifecta and the Agents Rule of Two

On 16 June 2025, Simon Willison described the “lethal trifecta”: an agent that has access to private data, is exposed to untrusted content and can communicate externally can be manipulated via prompt injection into exfiltrating data. On 31 October 2025, Meta extended this into the “Agents Rule of Two”: within a session, an agent should combine at most two of three properties: processing untrusted inputs; accessing sensitive systems or private data; changing state or communicating externally. If it needs all three, at least supervision is required, for example through human approval. Meta stresses that the rule complements least privilege rather than replacing it.

VamiSec assessment: both models describe properties of a session, not of a model. They can only be enforced if one component sees every action and the session history so far. This is the control point that the OWASP Agent Control Standard (ACS) standardises. Detecting untrusted inputs requires the optional acs-provenance profile; ACS-Core alone does not provide provenance information.

Documented incidents — and what runtime control could have limited

Why control has to sit at runtime

Model selection, prompt hardening and red teaming before go-live remain necessary, but they do not tell you what an agent does in a specific session. Runtime control complements them: it acts before the action, evaluates the context of the entire session and leaves a reconstructable audit trail. For ASI02 (Tool Misuse and Exploitation), the OWASP Top 10 for Agentic Applications 2026 recommends upstream policy enforcement middleware, an “Intent Gate” that checks intent and arguments before execution. ACS is not mentioned there, but (VamiSec assessment) it provides an open wire contract for precisely this control point. The policies remain your responsibility.

More precisely: the Agent Control Standard (ACS) is a specification of the OWASP GenAI Security Project that defines at which control points (hooks) an AI agent submits its steps to an external policy authority and how that authority responds with a decision (disposition). The format is JSON-RPC 2.0 with a dedicated acs_version field, transported over HTTP(S) or stdio. The current version is specification v0.1.0, published as release 0.1.2 (tag dated 21 September 2026). ACS defines the contract between agent and Guardian, not the policies: what is permitted is still decided by your organisation.

The parties

One design principle underpins the architecture: the language model must know nothing about the hooks. The framework fires them, and provenance information is set outside the model’s output path. As we read it, the intention is that a manipulated model can neither see nor influence the control point.

Three pillars: Instrument, Trace, Inspect

ACS-Core and seven profiles

Conformance is modular. ACS-Core is the mandatory baseline, on top of which sit six optional profiles that a deployment declares in the handshake. There are no numbered levels — only profile names that can be combined independently. The only dependency: acs-inspect-dynamic extends acs-inspect.

The specification is matter-of-fact about what ACS-Core guarantees: the channel is authenticated, and the Observed Agent follows the decisions. It does not guarantee that the policies are strict — a permissive Guardian is conformant, just permissive. Tamper evidence for the audit chain, even against a compromised Guardian, is only provided by acs-crypto and acs-audit, because the HMAC baseline is a symmetric scheme. The specification’s example combinations range from a minimal IDE integration with acs-core only to a high-assurance deployment with all seven profiles.

The project page’s tier model: architectural layers, not levels

1. 1
   Tier 1 · Platform layer

   Agent frameworks provide standardised middleware hooks — this is where the control point is created.

2. 2
   Tier 2 · Enforcement layer

   An open-source component reads declarative policies and returns decisions via these hooks.

3. 3
   Tier 3 · Enterprise layer

   Custom classifiers and domain-specific logic plug in behind the same interface.

This model describes who contributes which part, not how conformant a deployment is. For conformance claims, only the profiles count. It is still useful for your architecture planning: it separates the question of which platform supplies the hooks from the question of who operates and maintains the policies.

From observation to control

Work began on 11 May 2025 as the “Agent Observability Standard” (AOS) in Zenity’s GitHub environment and moved to the OWASP organisation in June 2025, where AOS was listed as an “OWASP other project”. In May and June 2025, the protocol layer was temporarily called “ASOP” (Agent Security & Observability Protocol) before reverting to AOS. After a phase with only sporadic commits from mid-2025, the rebranding to Agent Control Standard followed on 10 April 2026. The new name marks the substantive step from mere observation to enforcement. ACS then briefly ran as an independent project outside OWASP and returned in September 2026 — this time to the OWASP GenAI Security Project.

Status: Incubator and public preview

ACS is a project of the OWASP GenAI Security Project, where it is assigned to the Agentic Security Initiative. In its own OWASP Nest metadata it declares Level 2 — the “Incubator” stage in the Nest schema; this does not establish a classification by an OWASP body. The project lead publicly describes the status as “public preview” and explicitly advises implementers to proceed with caution. ACS is not an ISO, IETF or W3C standard and not a harmonised standard. The early stage is also evident formally: there are no GitHub releases, only tags; specification prose and schemas changed between v0.1.1 and v0.1.2 without the specification version v0.1.0 being incremented.

Who steers the project?

According to GOVERNANCE.md, Michael Bargury and Ory Segal created ACS; both remain project leaders. The project lead is Rock Lambros. For transparency: Bargury is CTO and co-founder of Zenity, Lambros is listed by Zenity as “Director of AI Standards and Governance”, and the early AOS commits come predominantly from the Zenity sphere. The workstreams — Coding Agents, Development (SDK), Identity, Outreach and Spec — are led by people from several organisations. The project page describes ACS as vendor-neutral and community-governed; that is a self-description. Our assessment: an OWASP project with a strong Zenity imprint in its founding and leadership.

Decisions go through an acceptance gate. Only issues labelled status:accepted make it into the backlog; changes to behaviour, normative text or code require an accepted issue, specification changes start as a GitHub Discussion, and commits require a DCO sign-off. Development takes place on the integration branch. Only when the project lead promotes to main are the site and schema URIs republished. As of 3 October 2026, main has not been promoted since 10 September 2026 — changes on integration are therefore not yet published.

Licensing: what you may reuse

Roadmap: what is documented

The next specification release, v0.2.0, is targeted for March 2027; no date has been set for v1.0. Items earmarked for v0.2 include streaming and interruption, recursive ASK and quorum, multi-tenant isolation, the Cedar binding, AgBOM federation across A2A peers and A2A wrapping. The ongoing goal since the kick-off on 10 September 2026: within 90 days, a working Guardian reference implementation, benchmarked for interoperability with Microsoft’s Agent Governance Toolkit, in the hands of external evaluators. Whether this will be achieved by early December 2026 remains open. Also open is PR #21, which seeks to redraw the mandatory scope of ACS-Core. Diverging version outlines in blog posts are not an official roadmap.

On the wire, hooks carry the prefix steps/, for example steps/toolCallRequest. In addition, there are methods that are not native steps/* hooks: agbom/snapshot and agbom/changed for the inventory, the liveness probe system/ping, the handshake handshake/hello and the protocols/MCP/* namespace for wrapped MCP messages. The specification’s hooks page counts 19 hooks plus two AgBOM methods plus ping as 22 methods; the schema package comprises 44 JSON schemas in total. Some project texts (README, docs/acs.md) still refer to 16 lifecycle hooks — that is the count without the three skill hooks.

The core minimum: six hooks

ACS-Core requires at least six hooks: sessionStart, userMessage or agentTrigger, toolCallRequest, toolCallResult, agentResponse and sessionEnd. A framework should implement all the others if it can observe the relevant event; they are negotiated in the handshake. For your product evaluation, this means that the statement “supports ACS” does not yet tell you whether memory writes, subagents or skills reach the Guardian at all.

The methods_evaluated trap

In the handshake, the Observed Agent reports which methods it implements (methods_implemented). The Guardian responds with the list of methods it actually evaluates (methods_evaluated). If the agent sends a hook that is missing from this list, it must treat it as ALLOW-by-default — at best the step is logged, but it is not checked. The only reference implementation, for example, evaluates only steps/toolCallRequest and steps/toolCallResult, i.e. two of 19 hooks.

toolCallRequest: the central enforcement point

steps/toolCallRequest is the only hook for which the specification explicitly provides all five dispositions; this is also where the control paradigms apply. One MUST rule is central: frameworks must fire toolCallRequest for every action that leaves the agent’s reasoning context — even if the framework does not treat it internally as a tool. This covers read and write access to the file system, network fetches, process launches and shell commands. Anything that bypasses this hook is invisible to any policy.

Mandatory in the payload are tool.name and arguments, where each argument value can carry its own provenance. Optional additions are an abstract capability such as filesystem.delete or network.egress, the raw_command and an intent. This allows policies to evaluate what an action does rather than which program executes it.

Hooks with a particular protective effect

• memoryStore is the standard sink for influence across sessions and, according to the specification, the point of intervention against memory poisoning (cf. ASI06: Memory & Context Poisoning).
• preCompact and postCompact secure compaction: the summary must carry origin agent_generated and inherit the provenance of all compacted entries so that untrusted content cannot be laundered.
• subagentStart allows the Guardian to refuse the start of a subagent; each subagent receives its own session_id and its own audit chain.
• skillRegister and skillLoad bind skills to a digest: only what was previously approved with an identical skill_id and an identical digest may be loaded; loads that cannot be matched should be rejected.

On the wire, dispositions appear in lowercase in the decision field; the specification prose writes them in capitals (ALLOW, DENY …). In v0.1, every response is of type final — intermediate states (progress) and interruptions (interruption) are only planned for v0.2. Mandatory in every response are type, acs_version, request_id and decision; the request_id mirrors that of the request.

MODIFY: two mutually exclusive forms

The modifications object comes in two forms. Either modified_content replaces the entire payload — in which case no further edits are allowed. Or the Guardian sends structured edits: redactions (JSON Pointer path plus replacement text, default “[REDACTED]”) and/or parameter_overrides (argument name plus new value). Both may occur together, but their targets must be disjoint: no redaction path may hit the same field as an override, nor a parent or child of it. The specification’s rationale: a fixed order of application would resolve conflicts silently and, depending on the order, re-expose redacted values or overwrite sanitised ones. If a Guardian violates these rules, the Observed Agent must treat the response as a deny.

An example: an agent wants to query a customer table in full. The Guardian responds with modify and an entry in parameter_overrides that limits the query to 500 rows — as in the simulator scenario “Unbounded database query”. Override values appear as raw values in the object, not in a value wrapper.

ASK: approval with clear rules

• ask_details requires an approver with type (human, agent or service) and id, a question and timeout_seconds (at least 1).
• When the timeout expires, timeout_disposition applies; the default value is deny.
• The Guardian must verify the approver’s identity against the policy — approver authentication is mandatory.
• Only one hop: approvers must not themselves return ask. Quorum and recursive approvals have been deferred to v0.2.
• If a client cannot resolve ASK, the Guardian must not send ask. Instead, it falls back to defer with timeout_decision deny or to deny with the reason code approver_unavailable — a silent allow is ruled out.
• Via intent_extension, an approval can extend the permitted capabilities for this_request or for the entire session. According to the specification, this is the only conformant way to change the established intent after the fact.

Important from a regulatory perspective: ASK is not automatically human oversight. The approver can be an agent or a service, and timeout_disposition can be set to allow. Human oversight under EU AI Act Art. 14 applies to high-risk systems from 2 December 2027 (Annex III) and 2 August 2028 (Annex I) respectively; AI agents are not high-risk per se. In VamiSec’s assessment, anyone using ASK as a building block for this needs a policy with approver.type human and timeout_disposition deny, as well as an approval process that avoids decision fatigue. ASK then supports your evidence trail but does not by itself fulfil Art. 14: v0.1 has no stop button, only step-by-step deny.

DEFER: postponing the decision, within limits

defer_details requires a reason (insufficient_context, conflicting_policies, low_confidence or pending_dependency), a resolution_method (additional_context, human_approval or timeout) and resolution_timeout_ms. On expiry, timeout_decision only allows deny or ask — no allow — and defaults to deny. The prose requires the field, but the schema does not list it as mandatory; so always set it explicitly. Cascading deferrals must be limited per session. Mind the units: ASK counts in seconds (timeout_seconds), DEFER in milliseconds (resolution_timeout_ms).

Every session starts with handshake/hello. The ClientHello is carried in the payload of a normal request envelope; the ServerHello comes back as result — without a decision. The negotiated version must match the client’s major version; unknown fields must be ignored.

Failure posture: fail-open is the default

For every reported step, the Observed Agent must wait for the decision — up to the negotiated timeout — and apply it. A framework that sends hooks but ignores the verdict is not conformant. If no usable decision arrives, the specification speaks of a decision failure: the Guardian is silent, the transport fails (refused connection, TLS error, malformed response) or the Guardian returns an error instead of a decision. In all three cases on_decision_failure applies, and its default value is proceed: the action continues unchecked. Fail-closed (deny) has to be configured explicitly by a deployment.

The specification is open about the price: anyone who can disrupt the channel turns control into mere logging. As a counterweight, a hard obligation applies — every step that proceeds without a decision must be recorded as an audit event. If a decision does arrive within the timeout after all, the agent must follow it, regardless of the posture.

Startup posture: when even the handshake fails

If the Guardian is unreachable at session start or responds without a ServerHello, a startup posture configured outside the protocol applies: proceed (the session starts unprotected) or refuse. Here, too, proceed is the default so that a Guardian outage does not block new sessions. A session started without protection must be recorded in the deployment’s own audit log. An explicit rejection by the Guardian, such as SESSION_REFUSED, by contrast counts as a decision and not as an outage.

Timeouts: no default in the specification

The specification does not set a numerical default timeout. timeout_config.default_ms is mandatory in the ServerHello, but the value is up to the deployment; per_method_ms allows different values per method. The handshake schema points out that every millisecond of timeout can, in the worst case, mean added latency for the step, and recommends aligning per-method timeouts with latency tolerance rather than with a generous blanket value. The reference implementation uses 5000 ms — an implementation value, not a requirement. A sensitivity-based timeout model is planned for v0.2. To clarify terminology: ACS_ON_DECISION_FAILURE is an environment variable of the reference Guardian that sets the value of on_decision_failure — not a field of the specification.

Ping does not prove enforcement

system/ping is a pure liveness probe: the Guardian must always respond with allow, the ping requires no signature and is not written to the audit chain. So a Guardian can answer pings while rejecting every signed hook. The specification therefore recommends monitoring decision failures directly on the hook path.

Two layers, fixed order

The deterministic layer evaluates every hook first. It either decides itself or delegates to the agent layer — according to the specification, controlled via a chain configuration with the modes “*”, on_ask or pattern-based. However, v0.1 does not define a format for this configuration. The agent layer receives the same inputs plus the interim result of the deterministic layer, but never the policy code. On the way back, its response must pass through the deterministic layer again.

1. 1
   Hook arrives

   The request envelope, SessionContext, intent and, if present, provenance are passed to the policy engine.

2. 2
   Deterministic evaluation

   Policy-as-code — in v0.1 with OPA/Rego as the starting reference — returns allow, deny, modify, ask or defer, or delegates.

3. 3
   Optional LLM layer

   Evaluates cases that cannot be decided deterministically; treats untrusted fields as data and sees no policy code.

4. 4
   Re-check and response

   The result passes through the deterministic layer again; metadata.evaluator indicates deterministic, agent or composite.

5. 5
   Logging

   Every decision is logged with its reasoning, model identifier and, where available, confidence.

Policy engine: an interface, not a product

ACS defines the interface to the deterministic engine, not the engine itself. The input consists of the request envelope, SessionContext, intent and provenance; the output is a decision envelope, optionally with a delegation to the agent layer (delegate_to). ACS also sets conventions, including: no external HTTP calls in canonical policies. This supports determinism and low latency.

Obligations of the LLM layer

• Untrusted data is data, not instructions; the relevant fields must be wrapped or quoted in the prompt.
• No access to the policy code of the deterministic layer.
• Log every decision with reasoning, model identifier and confidence (where available); for evaluator agent or composite, model_id must be specified.
• Timeouts follow the timeout_config negotiated in the handshake.
• The entire layer is optional in v0.1.0: purely deterministic deployments are fully conformant.

Control paradigms without a dedicated wire extension

The specification names four paradigms as targets for v0.1. A Guardian expresses them via the same fields — reason_codes, policy_references, policy_data and cited_provenance_ids. If a deployment combines several paradigms, a single decision may cite all of them.

FIDES, CaMeL and AARM-style rules need provenance information and therefore require the acs-provenance profile; pure IBAC does not. ACS does not implement any of these approaches itself; it provides the fields through which a Guardian applies and justifies them. In other words, ACS does not prevent prompt injection — it creates the control point at which policies counter its consequences.

Operations: latency and availability (VamiSec assessment)

• Latency: every check sits in the agent’s critical path. Keep the deterministic layer local and free of external calls, reserve the LLM layer for a small number of ambiguous cases and measure evaluation_duration_ms per method.
• Availability: with fail-closed, the Guardian becomes business-critical. Run it close to the agent and redundantly. The reference implementation itself documents the risk: it writes logs synchronously in the decision path, so a slow disk blocks every pending decision.
• Policy lifecycle: version your policies and return policy_version in every decision; the specification provides for this so that historical policy states can be reconstructed.
• Scope: the Guardian is no substitute for a sandbox, IAM, secrets management or an egress firewall. Actions that bypass toolCallRequest remain invisible to it.

The only reference implementation runs Microsoft’s Agent Governance Toolkit unmodified behind the ACS wire. It is explicitly a proof of concept: two of 19 hooks live, no HMAC signature, fail-open by default. It demonstrates the pattern for two clients (Claude Code and OpenCode) but is not intended for production use.

Decisions that release or block actions travel between the Observed Agent and the Guardian Agent. Anyone able to tamper with this channel can turn a deny into an allow or replay an old approval. The OWASP Agent Control Standard (ACS) therefore treats channel security as part of the mandatory ACS-Core baseline, not as an optional profile.

Baseline signature: HMAC-SHA256 with a session key

ACS-Core requires a signature over the canonical envelope on every request and every response. The baseline that satisfies this requirement is HMAC-SHA256. The key is derived per session via HKDF — from deployment key material (a pre-shared secret or a channel binding such as a TLS exporter) together with the session_id. v0.1 does not define an in-protocol key exchange. What gets signed is the RFC 8785 canonicalisation (JCS) of the envelope without the signature field; the recipient recomputes this form and rejects any signature that does not match. TLS alone is explicitly not sufficient, because it does not bind individual messages for audit purposes. The only method exempt from the signature requirement is the liveness method system/ping.

Two details matter for the architecture. In the JSON schema, signature is optional, yet it is normatively mandatory in ACS-Core — schema validation alone will therefore not detect missing signatures. And the specification does not fix the salt, info string, hash function or key length for HKDF, so two implementations may derive different keys. In our assessment, these parameters belong in the interface agreement between platform operations and Guardian operations.

Replay protection

Every request carries a request_id (UUID), a timestamp and, optionally, a nonce. The Guardian must reject requests whose timestamp falls outside the negotiated skew_window_ms window (recommended default 300,000 ms, i.e. five minutes) and must reject duplicate request_id values within a session; it should reject duplicate nonces. This implies an easily overlooked operational requirement: synchronised clocks on both sides.

Audit chain: a hash chain with a published head

For each session, the Guardian maintains a SessionContext, an append-only chain of ContextEntries. Each entry receives an entry_hash: SHA-256 over the JCS-canonicalised entry without its hash fields, chained to the hash of its predecessor; the first entry has previous_hash null. Other canonicalisations are not permitted in v0.1. Publication is the decisive point: for every content-bearing step, the Guardian must include the current chain_hash in its response, covered by the response signature. The specification states the reason openly: if the Guardian kept the chain head private, it could, for example, remove a deny, recompute the chain from that point onwards and later present a sanitised history. Anyone capturing the traffic can detect a chain that has been rewritten after the fact.

What the chain proves — and what it does not

• The only mandatory fields of a ContextEntry are entry_id, step_id, step_type and entry_hash. The request_hash over the request content is merely recommended (SHOULD) in ACS-Core and only becomes mandatory in the acs-audit profile. Without it, the chain proves that a step took place, but not what was requested.
• The ContextEntry schema has no field for disposition, rationale or approver. ACS records decisions normatively as trace events (acs-trace profile, Chapter 9); only an intent extension writes a dedicated entry containing the approver identity (Chapter 11).
• HMAC is symmetric: the Guardian holds the key and could re-sign a rewritten chain head. The channel is protected against tampering on the network, not against a compromised Guardian.
• Non-repudiation towards third parties only comes with acs-crypto: at least ML-DSA-65 (MUST), SLH-DSA-128s (SHOULD), hybrid schemes optional.
• v0.1 provides no reconciliation across multiple Guardians (issue #18, deferred).

The normative contribution of Trace is its vocabulary: span names, attribute keys, event classes and the mapping of dispositions to severity levels. Transport uses OTLP (gRPC or HTTP) to existing backends; the wire namespace trace/* is merely reserved in v0.1.0. The stated goal is for ACS events to fit into SIEM pipelines without special parsers. In the repository, both the OTel and the OCSF extensions carry the status “Working draft”. Trace is the optional acs-trace profile. Anyone claiming it must emit at least one of the two formats with the mandatory attributes for every supported step, record every decision with its disposition, evaluator and — where available — rationale, and carry provenance facts from the hook over to the event.

OpenTelemetry: spans per hook, decisions as span events

The span hierarchy is deterministic: one root span acs.session per session, beneath it one acs.turn per turn and one step span per hook. Decisions are not separate spans but a span event acs.decision on the step span; the verdict and the controlled action thus share the same parent context. The event’s mandatory attributes are acs.decision and acs.evaluator (deterministic, agent or composite). For tool calls, ACS uses the span names gen_ai.tool.call and gen_ai.tool.result. Note: in the OpenTelemetry GenAI semantic conventions (status “Development” as of October 2026), gen_ai.tool.call is only an attribute prefix; the recommended span name there is execute_tool {gen_ai.tool.name}. Dashboards and queries aligned with these conventions will therefore not match ACS tool spans without adjustment.

SIEM use cases for agents

Limitations you should plan for

• Best effort: Trace must never block enforcement. If the sink fails, the decision still reaches the Observed Agent — so telemetry may have gaps.
• Self-reporting: trace events are generated in the observed environment and only become evidence once attested by an external party.
• Skill gap: the mappings cover 16 of the 19 native hooks plus the two agbom methods. skillRegister, skillLoad and skillUnload have neither an OTel nor an OCSF mapping.
• Documentation drift: where provenance is placed in OCSF is contradictory (enrichments in the normative mapping, unmapped.acs.provenance in the guide). The examples page with Splunk and Elastic queries still uses the former name ASOP and OCSF 1.0.
• Data protection: spans may contain prompts and tool arguments. The specification recommends redaction at the point of emission; in our assessment, this should be a binding part of the logging concept.

According to the specification, the AgBOM is a queryable, dynamic inventory of the components an Observed Agent uses. The rationale is precise: any policy that depends on what an agent is — which model, which tools — becomes unverifiable without an inventory. If a Guardian policy depends on the inventory, for instance to ban a model or tool, the deployment must implement the acs-inspect profile. The canonical AgBOM is a component graph, stored as a flat list with references by ID so that states can be compared by diff.

Eight component types

snapshot and changed: two wire methods

The Observed Agent sends agbom/snapshot once per session, after sessionStart and before the first content-bearing hook; the message contains the complete AgBOM. agbom/changed reports mutations — added, removed or modified components, either as a diff or as a full snapshot — and can carry a cause such as component_upgraded, discovery or user_action. Both events are recorded in the audit chain. The Guardian may use deny to refuse a session with a banned component or to block a hot swap.

Important for choosing profiles: anyone claiming only acs-inspect delivers exactly one snapshot per session and does not track changes. Runtime changes only become visible with acs-inspect-dynamic. The snapshot triggers renegotiation and policy_request refer to mechanisms that are not due to be specified until v0.2 — in v0.1, only session_start can be relied on in practice. Each component should also carry a registration_provenance (mandatory under acs-provenance). This makes it possible to distinguish whether a component comes from the configuration or was added at runtime.

Serialisations: CycloneDX, SPDX, SWID

The canonical form is always what goes on the wire; the Guardian renders serialisations on request for downstream tools. An acs-inspect deployment must offer at least one of them: CycloneDX 1.6, SPDX 3.0 or SWID (ISO/IEC 19770-2). All three mappings have the status “Working draft”, and the mappings to CycloneDX and SPDX are partly not schema-valid. The CycloneDX mapping uses type names such as ai-model or service as component types that CycloneDX 1.6 does not define in that form; the SPDX mapping uses classes and relationships that do not exist in SPDX 3.0.1. Plan exports with your own validation accordingly. CycloneDX itself has been available in version 1.7 since October 2025.

Telling them apart: AgBOM, AI-SBOM, CRA SBOM

Field provenance: facts instead of trust labels

Provenance answers where a data element came from and how it got to where it is. A provenance object carries a provenance_id, an origin with one of seven values — user_input, system, tool_output, retrieved, agent_generated, a2a_inbound, external — and, optionally, a source_id (such as a tool name, URL or path) and derived_from as a list of predecessors. This information is attached to data-bearing fields, and for toolCallRequest even to each individual argument. A policy can therefore target a specific data flow rather than the entire call.

• Framework-set: origin, source_id and derived_from are assigned by deterministic code outside the LLM output path. Instructing the LLM to generate provenance is not conformant.
• Transitive lineage: derived data inherits the origin of its inputs, including across summarisation and compaction. A summary of external tool outputs thus remains recognisable as such.
• No trust field: a trust value is only reserved in v0.1, not defined in the schema. The Guardian derives trust from origin and source_id against its policy; untrusted material never becomes trusted through LLM processing (monotonicity rule).
• All or nothing: with provenance_producer: deterministic, every data-bearing field must carry provenance; partial population is not conformant. If the client reports provenance_producer: none although the policy requires provenance, the Guardian rejects the session as early as the handshake with PROVENANCE_REQUIRED.

Provenance is not part of ACS-Core but of the acs-provenance profile. It is a prerequisite for enforcement paradigms such as FIDES, CaMeL and AARM, but not for purely intent-based authorisation (IBAC). ACS does not prevent prompt injection. It creates the control point at which a policy can limit the consequences — for example by blocking an email whose recipient and content originate from an untrusted retrieval result. Sensitivity or IFC labels are not part of the standard; they are the responsibility of the Guardian or the deployment.

Session Intent: the locked-in purpose

In ACS, intent is not a wire format but a governance concept: it binds actions to an authorised purpose — before untrusted data can exert any influence. Intent.parsed, the set of capabilities authorised for the session, is fixed at sessionStart or at the first agentTrigger. After that, neither the LLM nor tool outputs nor data from untrusted channels may change it; if the intent is set at sessionStart, a later agentTrigger with a different intent must be rejected.

The only conformant way to extend it is an intent_extension returned by an approver via the ask flow — with mandatory details on capabilities and scope. With scope this_request, the extension applies only to the current request. With scope session, the Guardian appends the capabilities, writes a ContextEntry of type intent_extension containing the approver identity and keeps the provenance of the extension separate from that of the original intent. Under scope_mode strict, it must not honour any extension that the policy prohibits in strict mode. In our assessment, this is the CISO’s lever against creeping privilege expansion: every extension of scope requires an authenticated approval.

Identity: normatively lean, much still in progress

The ACS-Core signature authenticates the channel between Observed Agent and Guardian symmetrically. It is neither authentication of the principal nor non-repudiation — and you should not conflate either of these in your architecture or your evidence.

MCP wrapping: specified, but whether it is mandatory is unresolved

The namespace protocols/MCP/* is the canonical way to carry MCP messages to the Guardian, for example protocols/MCP/tools/call. The MCP message itself remains unchanged; ACS layers the envelope, the decision contract and the audit chain rules on top. The flow has two stages: the agent submits the wrapped request to the Guardian, enforces its decision, forwards the message to the MCP server after an allow (according to the flow description) and also has the server’s response checked before processing it.

A deployment may consolidate MCP tool calls (tools/call) into the generic hooks steps/toolCallRequest and steps/toolCallResult if tool-level policies are sufficient. Wrapping is intended for cases where the policy needs MCP-specific distinctions: capability negotiation at initialize, server-side prompt templates (prompts/get), resource access (resources/read) and notifications (notifications/*). Irrespective of this, frameworks must fire toolCallRequest for every action that leaves the reasoning context — including built-in file, network or shell operations.

MCP 2026-07-28: the spec prose lags behind

Since 28 July 2026, MCP revision 2026-07-28 has been the current one (as of October 2026). It makes the protocol core stateless, abolishes the initialize handshake and, among other things, deprecates sampling and roots. The ACS namespace protocols/MCP/* is version-neutral; revision 2025-06-18 appears in the specification only as an example. The prose, however, still assumes the older semantics and explicitly names initialize negotiation as a point to be controlled. The specification leaves open whether this affects the wrappers in practice, and we are not aware of any robust analysis. In our assessment, MCP-heavy architectures should plan for the generic tool hooks as their primary control point.

A2A: reserved for v0.2

The namespace protocols/A2A/* is only reserved in v0.1; normative wrapping semantics are planned for v0.2 (target for v0.2.0: March 2027). The A2A pages in the repository date from the AOS era in 2025 and are not schema-compatible. Today, A2A relationships are only visible indirectly: via agentTrigger with trigger_type a2a_inbound and via a2a_peer components in the AgBOM. In-process subagents, on the other hand, are covered by ACS through subagentStart and subagentStop; each subagent gets its own session with its own audit chain, which the parent references via the final_chain_hash without merging the chains.

Skill lifecycle: register, load, unload

The digest covers the complete loadable artefact, including any bundled model weights or adapters; only the reference and the digest are persisted in the AgBOM, not the content. The Guardian should not rely on a digest_verified reported by the framework but should compare against its own approval. The repository’s design proposal for the skill lifecycle openly states the limitation: the digest binds the registered artefact, not code that a skill loads later — such dynamic loading runs as network.egress or process.execute through the regular tool hooks. Pre-publication marketplace scanning is not part of ACS, and the three skill hooks still lack a trace mapping (Chapter 9).

ACS is a project of the OWASP GenAI Security Project and, according to its own OWASP Nest metadata, is classified at Level 2 (Incubator); the project lead describes its status as “public preview”. ACS is not an ISO, IETF or W3C standard, nor is it a harmonised standard.

What v0.1 already delivers

Despite its early stage, v0.1 has substance: a shared vocabulary of 19 hooks and five dispositions, 44 published JSON schemas, a clearly described failure posture with an audit requirement for every bypass, and a specification that openly names its own gaps. In our assessment, this is enough to measure vendors against an open, shared yardstick and to design your own control points so that they remain compatible with later versions — but not enough to rely on conformance labels.

Conformance is self-declaration

In the handshake, the Observed Agent declares which profiles it supports (profiles_supported), and the Guardian declares which ones it accepts (profiles_accepted). There are exactly seven profiles: acs-core as the mandatory one, plus acs-trace, acs-inspect, acs-inspect-dynamic, acs-provenance, acs-crypto and acs-audit. There are no tiers or levels. Who verifies conformance claims? The specification answers that itself: in v0.1.0, nobody. There is no test suite, no register of conformant implementations and no body that resolves disputed claims (issue #19, open, priority P1). Moreover, ACS-Core guarantees only two things — an authenticated channel, and that the Observed Agent follows the Guardian’s decisions. It does not guarantee strict policies: even a permissive Guardian is conformant.

Reference implementation: an honest look at where it stands

The only reference implementation is explicitly a proof of concept. It runs Microsoft’s Agent Governance Toolkit (AGT), unmodified, as the policy engine behind the ACS wire, with host integrations for Claude Code and OpenCode. It claims acs-core only in a restricted form (“qualified”) and none of the six optional profiles. There is no interoperability benchmark with AGT yet; producing one is the goal of the 90-day window that began with the kick-off on 10 September 2026. No endorsement of ACS by Microsoft can be inferred from this. Beware the name clash: in the AGT documentation, “ACS” stands for Microsoft’s own “Agent Control Specification” (2 June 2026), the policy language of AGT — not for the OWASP standard.

Open spec gaps with practical relevance

• Default fail-open: on_decision_failure and the startup posture are set to proceed; you must configure fail-closed (deny or refuse respectively) deliberately.
• No stop mechanism: v0.1 has no kill switch; interruption and streaming are planned for v0.2. In v0.1, an agent can only be stopped step by step via deny.
• Mandatory scope in flux: an open proposal (PR #21) would downgrade modify and system/ping to SHOULD.
• Interop gaps (our own analysis): the HKDF parameters, the handshake signature and the input for request_hash are underspecified.
• Documentation drift: some pages still mention 16 instead of 19 hooks, or only three dispositions. The specification and the schemas are normative.

Three points of context first. First, ACS does not create a presumption of conformity; the specification text contains no mapping to the AI Act, NIS2, DORA, the CRA or ISO/IEC 42001 — all mappings below are VamiSec interpretations. Second, AI agents are not high-risk systems per se. Following the Digital Omnibus (Regulation (EU) 2026/1744), the high-risk obligations under Chapter III, Sections 1–3 of Regulation (EU) 2024/1689 apply from 2 December 2027 for Annex III and from 2 August 2028 for Annex I; Art. 50 has applied since 2 August 2026. Third, any line of argument depends on the profiles: ACS-Core alone includes neither Trace nor AgBOM nor request_hash.

Getting started in five steps

1. 1
   InventoryCapture and classify your agents

   Capture agents, models, tools, MCP servers and skills, and clarify the AI Act classification for each use case. Outcome: an agent register with risk class, owners and data access.

2. 2
   ArchitectureDefine control points and profiles

   Check which hooks your platform actually fires and which ones the Guardian confirms under methods_evaluated in the handshake: everything else is treated as allow-by-default and is unprotected. Choose profiles according to your evidence needs, for example acs-core plus acs-trace and acs-audit for logging obligations.

3. 3
   PolicyExpress policies as code

   The deterministic layer runs first (v0.1 reference: OPA/Rego). Write rules for destructive commands, egress and payments, require ask with a human approver and timeout_disposition deny for consequential actions, and reference policy versions in policy_references.

4. 4
   OperationsDecide on and test the failure posture

   For agents with high damage potential, set on_decision_failure to deny and the startup posture to refuse. Test Guardian outages, replay and signature errors, and monitor decision failures directly, because a successful ping does not prove healthy enforcement.

5. 5
   EvidenceConnect Trace and maintain evidence

   Export OCSF or OpenTelemetry to the SIEM, implement the use cases from Chapter 9 and define retention periods. Secure the chain head externally and verify vendors’ conformance claims through your own tests.

For an in-depth treatment with a 100-day programme, a roles and responsibilities model, metrics and assessment questions for agent platforms, see the CISO whitepaper “Agent Control for CISOs”, which you can request further down this page. VamiSec supports assessment, architecture, policy design and testing as an independent consultancy; VamiSec is not part of the ACS project.