Agent Control Standard: how to prove controls on runtime without calling warranty preview

An agent can receive a perfect policy in the prompt and still execute an undue action. Between written intention and effect in the world there are tools, identities, arguments, state, memory and integrations. This is where controls need to be observable and applicable.

O Agent Control Standard (ACS), presented by OWASP GenAI Security Project as a public preview v0.1 proposes a common language to instrument, track, inspect and control agents in runtime. The project is relevant because it moves governance of the document to the point of execution. It is not yet proof of effectiveness, adoption or compliance.

Status: Evidence Brief technical approved for publication. The analysis was closed on 02/09/2026 and describes the public stage observed on this date. Components, counts and roadmap can change.

The problem that the ACS tries to solve

Agentic applications differ from a simple call to model because they choose paths, use tools, and can produce effects outside the conversation interface. A useful control needs to answer at least:

• which agent tried to act;
• with what identity, scope and objective;
• which tool and arguments were requested;
• which policy was evaluated;
• whether the action was allowed, denied or modified;
• what material result occurred;
• which human or system had the authority to interrupt and recover.

Register only prompt and answer does not cover this chain. Nor is it enough to ask the model itself to state whether it acted correctly.

What the public version proposes

The official page of OWASP GenAI Security Project and default repository describe four main blocks:

1. runtime hooks for observing decisions and tool calls;
2. a policy context accompanying implementation;
3. enforcement decisions as allow, deny and modify;
4. portable records of telemetry and agent composition.

The project brings your events closer to conventions like OpenTelemetry and OCSF and proposes an Agent Bill of Materials, or AgBOM, to declare relevant components of the application. In the documentation consulted, the integration with OpenTelemetry appears as active, AgBOM as ongoing work and MCP/A2A integrations as planned.

This state distinction is important. “Forecast in roadmap” does not mean “implemented”; “implemented in project” does not mean “validated in your environment”; “registered event” does not mean “effective control”.

Minimum integration architecture

A responsible implementation can treat ACS as an adaptor between the agent's runtime and the policy layer:

intenção de produto
        |
        v
agente -> hook de ação -> policy decision point -> ferramenta
              |                 |                    |
              +------ trace + receipt <--------------+
                               |
                         revisão / incidente

The hook collects context before execution. The decision point assesses rules outside the model. The tool only receives the authorized action. Receipt records decision, versions and result without exposing unnecessary secrets or personal data.

Control needs to fail safely. If the policy is unavailable, high-impact actions should not inherit implicit permission. Fallback behaviour shall be decided by risk class, documented and tested.

The contract that must exist before the code

For each tool, register:

AgBOM can help answer “what makes up this agent?”, but it does not replace SBOM, data inventory, IAM, threat model or evidence of deployment. The artifact needs to point to versions actually executed.

Minimum tests for a pilot

A pilot shouldn't start with full coverage. It shall demonstrate that the border of authority operates in the most relevant scenarios:

1. an action allowed reaches the tool with reduced scope;
2. a prohibited action is denied before taking effect;
3. a modified action does not allow recovering the original arguments;
4. absence or timeout of the policy engine blocks the critical class;
5. exchange of identity or context invalidates the previous decision;
6. replay does not duplicate irreversible action;
7. logs preserve correlation without storing credentials or unnecessary content;
8. an operator can rebuild decision, execution and result;
9. revocation interrupts new actions and leads the state to recovery;
10. Agent update, tool or policy triggers regression.

The exact profile depends on the product and needs three modeling. Previous sources on sandbox, AISVS and delivery chain help structure the problem, but do not certify a deployment or define a universal control. [R2-C3]

What cannot yet be stated

At the cut date, the ACS was a preview v0.1 in active implementation. We do not find benchmark independent of incident reduction, public adoption base in production, controlled comparison with other approaches or certification associated with the standard.

O AI Security Standards Crosswalk of the same ecosystem also requires caution. Public pages consulted exhibited different counts of entries, frameworks and mappings; the project itself informs that mappings remain unreviewed until the signature of an identified reviewer. Therefore, crosswalk can support navigation and coverage hypothesis, but should not be used as a compliance seal.

Publications of the NIST on identity for agents and your synthesis of responses on safety of birth systems corroborate the general problem: agents need strong identity, authorization and auditability. They do not validate a specific implementation of the CHA.

Adoption criteria

Adopt the standard first as an interoperability contract and controlled experiment, not as a security claim. A production decision shall require:

• real compatibility with the runtimes and tools used;
• latency and availability measured on the critical path;
• policies outside the model and versioned;
• evidence of denial, revocation and recovery;
• minimisation and protection of telemetry;
• operation tested when control component fails;
• revision of pattern changes before updating integration.

The most important signal is not how many events were generated. It is if the organization manages to prevent a forbidden effect, explain a decision and recover the system when the flow escapes what is expected.

Sources and editorial context

1. OWASP GenAI Security Project — Agent Control Standard. Project page; primary source interested in the adoption of the proposal.
2. Agent Control Standard — documentation. Official documentation of the public version consulted on 02/09/2026.
3. Agent Control Standard — repository. Public code and roadmap; repository activity does not prove operational effectiveness.
4. OWASP AI Security Standards Crosswalk. Community mapping in evolution; public counts diverged and items without signature remained unreviewed in the cut.
5. NIST — Why Agentic AI Needs a Strong Identity Foundation. It supports the need for a strong identity, not an implementation of the CHA.
6. NIST — Summary and Analysis of Responses on Security Considerations for AI Agent Systems. Summary of contributions received; it is not ACS benchmark.

Editorial and responsibility note

This text combines facts attributed to sources with analysis and technical recommendations of the author. The ACS is presented as public preview v0.1, not as a guarantee of safety, certification or evidence of compliance. Personal and professional views should not be confused with proven facts; when there are data or implementation states, the source, cutting and limitations are indicated. The content is informative and does not replace threat modeling, testing, legal review, privacy assessment or independent audit. Tech Human and Trustyu act commercially on related topics. Research, structure and writing received AI assistance; the publicable version received factual review, authorial review and editorial approval on 02/09/2026, without independent human review.

Search cut: 02/09/2026. Editorial status: special publication brought forward by explicit decision to 02/09/2026 at 09h25 BRT.