OWASP AISVS 1.0: A Verification Standard for Agentic AI Security

What OWASP AISVS 1.0 Is

OWASP AISVS is built on the same verification-standard model OWASP established with the Application Security Verification Standard (ASVS). ASVS defines security requirements as discrete, testable statements grouped by control domain, which allows organizations to test and certify application security controls rather than treat guidance as narrative advice. AISVS applies that same approach to generative and agentic AI systems, positioning it within OWASP's broader GenAI Security Project, the initiative that also produces the OWASP Top 10 for LLM Applications.

The distinction matters operationally. A risk-category list like the LLM Top 10 tells a team what can go wrong, categories such as prompt injection, insecure output handling, or excessive agency. A verification standard tells a team how to confirm, in a testable and repeatable way, whether specific controls are actually in place.

What can be described with confidence is the standard's role: a checklist-style verification framework intended to make agent security controls consistently assessable across teams and vendors, addressing the enterprise problem of inconsistent, ad hoc agent security review.

AISVS in Context

The table below places AISVS alongside the related frameworks it extends and complements.

Why ASVS and the LLM Top 10 Are Not Sufficient on Their Own

ASVS was built for traditional web application architectures, where the security boundary is largely defined by user sessions, API endpoints, and server-side authorization checks. Agentic AI introduces control surfaces ASVS was never designed to cover:

• Persistent agent identity that exists independently of any single user session
• Delegated permissions that may extend beyond what the invoking user directly holds
• Multi-step tool invocation chains
• Autonomous decision loops that execute actions without a human confirming each step

The LLM Top 10 addresses a different problem entirely. Its risk categories concern what happens at the model's input and output boundary: prompt manipulation, unsafe generated content, and agency that exceeds intended scope. It does not, by itself, specify how to verify that an agent's tool calls are checked against an authorization policy at execution time, or that agent identity is separable from the identity of the calling application.

Existing mitigations built for LLM-specific risks, such as prompt filtering or output validation, address a different threat surface than agent permission enforcement and should not be assumed to satisfy agent-identity or tool-call governance requirements. This is the practical reason a dedicated verification standard for agentic systems is needed.

Agent Identity, Permissions, and Tool-Call Governance

Verifying agent identity requires distinguishing three separate contexts at each tool-call boundary:

• The human principal on whose behalf an action is ultimately taken
• The calling application or service that invoked the agent
• The agent's own credential or session context

Without this separation, it becomes difficult to attribute an action to a specific actor during an incident review, or to enforce different authorization rules for the agent than for the human or service that triggered it.

Tool-call governance extends this further. It is not sufficient to authenticate an agent once at session start. Each requested action needs to be checked against the agent's authorized scope, parameters, and context immediately before execution. This implies the need for a policy decision point: a control that evaluates whether a specific tool invocation, with its specific parameters, is permitted for that agent in that context, rather than relying on a broad, one-time grant of access.

In multi-agent or delegated-agent architectures, this becomes more complex, since permissions and identity need to propagate correctly across agent-to-agent calls, a scenario that single-agent security models generally do not address.

Runtime Controls Implied by Least-Privilege and Auditability Requirements

Applying least-privilege and auditability principles to agentic systems implies several runtime control requirements:

• Scoped, time-bound, task-bound credentials for agents in place of static, broadly-scoped API keys
• A policy decision point at the orchestration or gateway layer that evaluates each tool call before execution
• Structured, tamper-evident logging of agent decisions, tool calls, and permission checks, not only general application logs
• Interception of agent actions as they occur, rather than reliance solely on after-the-fact log review
• Defined handling for permission and identity propagation across agent-to-agent or delegated-agent calls

Preparing for Verification in Practice

Before assuming existing controls cover agent-specific risk, security teams should map current IAM and API gateway configurations against agent-specific requirements: how agent identity is established, how session boundaries are defined, and how scope is enforced per tool call. Gaps here are common because most identity and access infrastructure was designed around user and service accounts, not autonomous agents making sequential tool calls.

Verification against a checklist-style standard also requires an evidence-collection process. Teams need to produce logs, policy configurations, and test results that demonstrate a requirement is satisfied, not just described in a design document. For organizations managing agents across multiple internal teams or third-party vendors, this evidence needs to be comparable, which is why a shared control taxonomy matters more than any single team's internal documentation standard.

Governance ownership should be defined explicitly. Because agent security spans both traditional security engineering and AI/ML teams, unclear ownership of compliance evidence for categories like identity, permissions, and runtime enforcement tends to produce inconsistent verification outcomes, which is precisely the problem a verification standard is meant to resolve.