In September 2026, OWASP’s GenAI Security Project added a standard for controlling AI agents while they operate. The project’s accompanying code demonstrates how a proposed action can be checked and denied before a tool runs.
The documentation also identifies a consequential default: if the checking service fails to return a decision, the demonstration can allow the action to proceed.
Both facts matter. A system can demonstrate that it blocks a prohibited operation and still need a different answer when the safeguard is unavailable. What, exactly, would stop the agent then?
The Check Happens Before the Tool Runs
OWASP describes the Agent Control Standard as defining how agent platforms expose middleware hooks and how safety policies can be enforced through them, as declarative controls portable across agent frameworks and enforced at runtime. Enforcement at runtime is a different mechanism from instructions given to the model beforehand.
The project documentation calls the acting system the Observed Agent and the checking component the Guardian Agent. The former submits a proposed operation; the latter returns a decision. The specification includes allowing, denying, modifying, requesting approval, or deferring an operation.
The design gives an organization a place to apply a rule before an action takes effect. It also provides a common format for connecting agent software to the component evaluating that rule.
Consider a hypothetical agent preparing a report. It can read an internal file and draft a summary, but company policy prohibits sending the file to an unapproved external address.
A prompt can tell the agent about that restriction. A control placed before the sending operation can examine the recipient and refuse the transfer. Establishing that the control works requires checking what the deployed software actually does with the refusal.
The Specification and the Software Are Different Evidence
The project’s reference-implementation documentation describes a proof of concept connecting two coding-agent clients, Claude Code and OpenCode, to a single Guardian process running Microsoft’s Agent Governance Toolkit as its policy engine. It expressly identifies the software as a demonstration, rather than a production system.
That distinction is essential to interpreting its disclosed limitations. As reviewed on October 15, the documentation identifies incomplete coverage of the specification — two of nineteen step methods evaluated — and missing authentication, origin checking, request signing, and replay protection. It also describes the configurable default that permits continuation when no decision arrives.
These disclosures do not establish that every implementation of the standard has those limitations. They show why publishing a specification and implementing it are separate accomplishments. The specification itself is at version 0.1.0, with version 0.2.0 targeted for March 2027 and no 1.0 date set.
A specification can require a protection. The software must supply it. A test must establish whether it works under the conditions being examined. Evidence concerning one of those steps cannot automatically establish the others.
The demonstration therefore supplies a useful question for anyone evaluating an agent product: which protections have been specified, which have been implemented, and which have been verified?
No Decision Is Still a Decision About What Happens Next
The reference software’s failure behavior makes that question concrete. Its documentation explains that the default permits continuation when a decision cannot be obtained, records each such continuation in an audit log, and allows configuration to require blocking instead. A decision that does arrive is never overridden by that posture: a refusal, an invalid envelope, or an evaluation error is treated as a denial.
Returning to the hypothetical report agent, an unavailable checking service leaves two possible outcomes. The send operation waits or stops. Or it proceeds without the check that ordinarily determines whether the recipient is permitted.
The organization needs to choose that behavior deliberately. Continuing without a check has consequences for disclosure. Blocking has consequences for availability and completion of the work. A requirement to protect information needs to address both the ordinary decision path and the response when that path fails.
Testing one successful denial would leave this question unanswered. The relevant evidence would include what happens during an outage or a delayed response, and whether the resulting behavior matches the organization’s requirements.
A Checkpoint Must Cover the Actual Route
The location of the check matters too. In the hypothetical, restricting one email tool would leave a gap if another connected service could upload the same file without evaluation.
This is a practical implication of the design. Organizations need to identify the operations that can produce the prohibited result and determine which controls apply to each route.
Approval introduces another question. If a person approves sending a summary to one recipient, the system needs a way to ensure that the operation executed is the one approved. The specification’s ask disposition can route to a human, another agent, or a service, which makes that assurance more important rather than less. A later change to the attachment or destination changes the action being authorized.
Records can help establish what occurred: the proposed operation, the rule applied, the decision returned, and what ultimately ran. Recording a denial alone does not establish that the underlying operation was prevented.
Rules Need Accurate Descriptions of the Action
Structured definitions can help a control distinguish a permitted operation from a prohibited one. The hypothetical organization could define approved recipients, restricted files, and the operations allowed for each combination.
That is where a shared description of entities and their relationships can contribute. ACS keeps one: a concepts layer covering identity, intent, capability, provenance, and trust basis, which each pillar’s specification references rather than restates. Its usefulness depends on whether the checking component receives accurate information and whether the system enforces the resulting decision. ACS provides interfaces for controls; it does not supply every organization’s substantive rules or establish their adequacy.
Nor is ACS legislation or government certification. Technical enforcement means that software applies a decision within the deployment. It does not mean that publishing the standard creates a legal obligation to adopt it.
