Two agent-governance projects use the initials ACS: OWASP’s Agent Control Standard and the Agent Control Specification used by Microsoft’s Agent Governance Toolkit (AGT). An integration review should start with their exact versions, the host that applies decisions, and the evidence that records what happened.
The names leave real questions open. An approval must reach a host that can request and resolve it. A transformed tool input must be applied to the action that actually runs. A decision-service outage needs a defined outcome. Those details decide what an integration can claim. This post pins both contracts as of 26 October 2026, reports a run of the OWASP reference host-adapter tests, and links a versioned comparison. This post is part of a three-part research series on agent authority, published 26 October 2026: stop evidence, policies in agent memory and agent control standards.
Pin the actual contracts
On 26 October 2026, OWASP’s published tree identifies release 0.1.4, dated 16 October. Its wire and schema namespace still identifies 0.1.0. The changelog records changed Trace requirements under that namespace and asks conformance claims to name the release or commit. A handshake version alone therefore leaves part of the contract unspecified. Pinned release history.
Microsoft’s current documentation reflects a changed structure. AGT uses an upstream policy-decision runtime and a separate Agent Hooks interception contract. The host supplies a complete snapshot, receives the runtime’s decision and owns enforcement. AGT’s current ACS guide.
The OWASP reference bridge pins an older AGT revision and Node SDK 0.3.1-beta.0, so its mapping must be read against that generation. The current AGT guide describes three normalised decisions, allow, deny and transform, with warnings and approval information carried alongside them. A bridge shown to work against the older contract needs fresh compatibility evidence before it can stand for the current one. Bridge dependency pin.
| Item | OWASP Agent Control Standard | AGT / Agent Control Specification |
|---|---|---|
| Release | 0.1.4 (16 October 2026) | Engine dependency 0.4.0-alpha.4 |
| Wire or manifest | Wire, spec and schema namespace 0.1.0 | Existing manifest 0.4.0-alpha.1; opt-in contract 0.5.0-alpha.1 |
| Reference bridge | Pins an older AGT commit and Node SDK 0.3.1-beta.0 | Not applicable |
Follow approval and failure through the host
OWASP defines decision dispositions and capability-dependent behaviour, including approval, deferral and modification. Mandatory Core requirements sit beside optional profiles. The specification separates decision-delivery failure from other outcomes and defines a negotiated failure posture. Pinned conformance contract.
In the current AGT contract, a denial can carry approval information that the host resolves, and a transformation requires the host to validate and apply it. The runtime’s decision is one step in that flow. Agent Hooks states its trust boundary: the host is trusted, controls run in process, and its eight interception points do not promise complete mediation. Agent Hooks.
An integration record should connect the proposed action to the decision, any human approval, the input finally dispatched and the result. If input changes after approval, the record must show how the application decides whether the approval still applies. If a host cannot render a required control, its documented fallback becomes part of the assessment.
| Concern | OWASP 0.1.4 | Current AGT |
|---|---|---|
| Decisions | ALLOW, DENY, ASK and DEFER must be supported; MODIFY should be, with defined handling for clients that cannot apply it | allow, deny, transform; warn becomes allow with warnings; escalate becomes a liftable deny carrying approval |
| Human approval | ASK details, timeout and approver capability have defined behaviour | The host owns approval resolution |
| Delivery failure | Negotiated on_decision_failure; default proceed with required audit | Runtime errors yield deny; deployment behaviour depends on the host |
| Coverage | Core plus self-declared optional profiles | Eight interception points; trusted host; no promise of complete mediation |
What we ran
We checked out the OWASP reference implementation at commit 4cf23d4 and ran its decision-validation and failure-posture suites unchanged with Bun 1.3.14. All 94 tests in those two files passed (236 assertions). They exercise malformed modifications, expired decisions, delivery failures, explicit refusal and failure to record an audit event.
The tests make useful distinctions. An expired approval request can be treated differently from a decision service that never answered. An explicit refusal differs from a transport failure. A configuration that allows the action to proceed still has to meet its audit requirement. A single label such as “fail closed” cannot describe all of those paths without their conditions.
Two runtime-dependent test files could not load their native dependency, which requires glibc 2.39; our host has 2.35. We kept the failed attempt alongside the successful run. We obtained no live policy-engine results from those files, and the 94 passing tests do not establish full conformance or interoperability.
The reference maintainers also disclose gaps in hook coverage, signing, authentication and replay protection. Those are part of the implementation’s documented scope, and any reference that uses it as an example should keep them visible. Reference implementation scope.
Record the outcome the evidence supports
The Trace changes in OWASP 0.1.4 add a useful rule: correlate request and session identifiers, and check for a matching decision-failure event before treating a decision as enforced. That separates what the policy service decided from what the host completed.
The October comparison separates source requirements, helper-level observations and scenarios we did not run. Use these scenarios for an integration test plan:
| Scenario | Observation needed | This review |
|---|---|---|
| Denied tool call | The host prevents dispatch | Helper behaviour and source reviewed; live native path not run |
| Approval followed by changed input | The approval binds the action actually dispatched | Not run |
| Decision service unavailable | Chosen posture, resulting action, audit event | Host-helper tests passed; live path not run |
| Expired decision | Time boundary and fallback outcome | Host-helper tests passed |
| Replayed request | Duplicate detection and recorded disposition | Missing protection disclosed upstream; no live probe |
| Transformation cannot be applied | Safe fallback and evidence | Host-helper tests passed |
| Decision recorded, host fails to apply | Joined decision and failure evidence | Trace contract reviewed; scenario not run |
How KLA handles the same questions
KLA is not an implementation of either ACS project. For comparison: the KLA Policy Engine returns one of four outcomes, allow, warn, require_approval or block, for each governed action. When evaluation fails it returns its fail-closed decision, require_approval by default, and policy-pack lint rejects a policy whose default decision is fail-open. On the governed tool path, an approval request for a tool call records a SHA-256 hash of the arguments it was issued for, which addresses the “approval followed by changed input” scenario above.
The tests in this post ran against the OWASP reference implementation only and contain no KLA result. The OWASP agentic controls guide maps runtime controls to evidence in more detail.
Frequently Asked Questions
What is the difference between OWASP ACS and Microsoft’s Agent Control Specification?
They share initials and differ in contract. OWASP’s Agent Control Standard (release 0.1.4, wire namespace 0.1.0) defines ALLOW, DENY, ASK, DEFER and MODIFY with a negotiated failure posture. The Agent Control Specification used by Microsoft AGT normalises decisions to allow, deny and transform, and leaves approval resolution and enforcement to a trusted host.
Which version should an agent control conformance claim name?
The release or commit. OWASP 0.1.4 changed Trace requirements without changing the 0.1.0 wire namespace, and its changelog asks conformance claims to name the release or commit. For AGT, record the engine, manifest and contract versions separately.
Does the OWASP reference implementation pass its tests?
On 26 October 2026 at commit 4cf23d4, the two host-adapter suites we ran passed 94 of 94 tests. Two runtime-dependent files could not load their native dependency on a glibc 2.35 host. These results cover helper behaviour only and do not establish conformance.
What does “fail closed” mean for an agent control?
It depends on the failure. An expired approval, an unanswered decision request, an explicit refusal and a transport error can each have different required behaviour. Name the failure class, the resulting action and the audit event for each.
Key Takeaways
Project names do not establish interoperability. Pin the release and wire versions, follow approval and transformation through the host, test each failure class, and check the trace before claiming enforcement. The October comparison gives a dated starting point; refresh it when either project moves.
Versions were pinned on 26 October 2026. Our run covered 94 host-helper tests; no live host, approval or trace scenario was executed.