A note on the OWASP GenAI Security Project's agentic track and where AAES action-layer controls overlap it. This page is distinct from the OWASP Top 10 for LLM Applications note, which addresses the model-application risk list; this one addresses the project work aimed at agents that act.
These pages describe the product. They are not a certification or a legal opinion.
Reading this note
This note describes selected AAES controls against the agentic track's published themes. The project's own publications are authoritative for their content. AAES maps to this work; nothing here implies the project endorses AAES.
Instrument identity
- Title
- OWASP GenAI Security Project, agentic track: agentic AI threat lists, the "Agentic AI – Threats and Mitigations" work, and the Agent Control Standard (ACS) proposal
- Issuing body
- OWASP Foundation (community project)
- Instrument type
- Practitioner-oriented community guidance: threat taxonomies, mitigation guides, and reference architectures — not assessable control clauses, not a regulation
- Official sources
- OWASP GenAI Security Project and the Agent Control Standard repository.
The agentic track is the part of the GenAI Security Project concerned with systems that take actions, not only systems that generate text. Its deliverables read as mitigation prose; the ACS proposal is the track's move toward clause-shaped controls and is still a proposal.
Question
For a reviewer who arrives with an OWASP mental model, which AAES controls answer the agentic threats?
The overlap is real and inspectable: pre-execution interception and authorization decisions (AARM rows R1 and R4) sit beside the project's tool-use mediation and human-in-the-loop escalation mitigations; tamper-evident receipts (R5) sit beside its logging and forensics mitigations; risk classification and provenance (R10/R11) sit beside its prompt-injection and untrusted-content threat entries.
For procurement teams, this page is the translation layer: the threats the project names are the threats AAES's controls are designed against, but AARM's clause shape is stricter than OWASP's mitigation prose, so this mapping never tightens AAES's bar.
Selected contribution
The following controls may be usable as mitigation evidence within the client's own handling of the named threat themes. Their scope is the action layer, not the project's catalog as a whole.
| Threat theme (project wording) | What a reviewer can examine in AAES | Boundary |
|---|---|---|
| Tool-use mediation and human-in-the-loop escalation | Agents only see permitted capabilities; actions classified as irreversible require approval by an authorized person; an agent cannot approve itself; approvals bind to the exact request. | Enforcement depends on control of the agent's credential path. An action that satisfies the configured policy may still be authorized. |
| Logging and forensics | One sealed, hash-chained record per action; exports can be checked offline against a public key held by the client deployment (AAES holds no copy of the private key). | Integrity does not prove a complete action history. Activity outside AAES is visible only where telemetry is supplied. |
| Prompt injection and untrusted content | An injected instruction that tries to become an action still has to pass the same decision: permitted capability, scope, approval rules and budget apply regardless of where the instruction came from. | AAES does not detect or prevent prompt injection in model input. It constrains what a routed action can do. |
Preconditions and gaps
- The ACS proposal is not yet a standard. AAES tracks it; if it hardens into clauses, this mapping will be extended and re-dated. AAES has a proposal in the ACS public discussion (issue 185).
- Mapping is not endorsement. The project does not endorse AAES, and this page does not claim its review.
- Credential-path control is required. Activity outside AAES is visible only where telemetry is supplied. Observation is not enforcement.
- No production adoption as of this review. Clients operate their own deployments; AAES does not offer a hosted deployment.
For implementation and testing details beyond this note, use Security and implementation posture and the evaluation page. Results from a client's test tenant are produced during a scoped evaluation.
Client responsibility
The organization runs its own security program against the project's guidance. The client remains the regulated entity.
Identify the credential path, actions, and evidence questions to examine in a client test tenant.