How is AISVS different from the OWASP Top 10 for agentic applications?

The Top 10 is a threat catalog. AISVS is a verification standard. The Top 10 names what can go wrong. AISVS specifies the testable claims a control must satisfy. Pen testers and CI/CD pipelines can run AISVS requirements as pass/fail checks. They cannot run a threat catalog the same way.

Which AISVS verification level should a regulated enterprise target?

L2 is the realistic baseline for a regulated enterprise running production AI. L3 is for systems with strong regulatory exposure (EU AI Act high-risk, HIPAA, DORA-scope financial services). L1 is for early-stage or low-risk internal deployments. The level mapping aligns with how the original ASVS levels worked in web-app security.

Does a policy gateway alone satisfy AISVS?

No. A gateway covers chapters 4 through 9 of the runtime bucket. The training, supply-chain, deployment, and governance chapters require controls that live elsewhere. AISVS 1.0 is explicitly a multi-control-plane standard. A gateway is one of those control planes, not the entire program.

How does AISVS interact with EU AI Act Article 12?

AISVS chapter 7 reads as a verification specification for Article 12 logging requirements. Article 12 says automatic recording over the lifetime of the system. AISVS chapter 7 specifies which fields, what signing guarantees, and what tamper-evidence is required for the recording to count. A control that passes AISVS chapter 7 at L2 will also satisfy Article 12 mechanical requirements; the converse is not always true.

Can MCP traffic be verified under AISVS chapter 8?

HTTP-transport MCP can be verified when the traffic is observable to the verifier. STDIO and local IPC MCP transport sit outside the runtime-enforcement boundary; those deployments need controls at the host-process layer instead.

OWASP AISVS 1.0: A Gateway Control Mapping

On June 24, 2026, the OWASP Foundation published AI Security Verification Standard 1.0. The standard runs 14 chapters and 514 testable requirements, modeled after the Application Security Verification Standard (ASVS) format that has driven web-app pen testing playbooks for over a decade. The agentic threat catalogs (LLM Top 10, Top 10 for Agentic Applications) describe what can go wrong. AISVS is the verification document an auditor, pen tester, or CI/CD pipeline can actually run.

I want to walk through which AISVS chapters describe runtime controls at the AI request and response boundary, which chapters sit in the model and training layers, and how to read the standard when you are scoping a gateway-layer control inventory against it.

TL;DR

AISVS assigns verification work to distinct control owners. A gateway can enforce and record routed HTTP AI traffic, while model and program controls remain separately owned. Each requirement needs an identified owner and retrievable proof.

What AISVS 1.0 covers

The standard's 14 chapters group requirements into three operational tiers. Each requirement is written as a verifiable claim, with verification level L1 (baseline), L2 (standard), or L3 (advanced) attached. The chapters cover training-data integrity, model lifecycle, supply-chain provenance, prompt and response handling, agentic skills and tool use, MCP server authentication, identity and authorization for AI calls, audit logging, privacy controls, deployment safety, third-party risk, monitoring, incident response, and governance.

The verification work has three ownership zones. Model and training work occupies the opening three chapters. Runtime AI-traffic controls sit in the middle six. Program and process work fills the final five. That division follows the familiar OWASP ASVS verification model, adapted to AI-specific request paths.

The runtime bucket is where a policy gateway at the AI request boundary lives. The other two buckets sit in the data science platform, the supply chain, and the security program. A gateway cannot satisfy them, and an honest control inventory says so.

Turning AISVS into a verification plan

Start each requirement with the control owner and the proof an assessor can retrieve. For a request-path requirement, capture the authenticated principal, the model endpoint, the policy version, the decision, and the request identifier in one signed event. Then test an allowed request, a policy-denied request, and a response containing data the policy prohibits. These tests show that the gateway evaluated traffic that actually traversed its HTTP route.

Model-training, supply-chain, and program requirements need their own evidence owners. A model card, dependency attestation, incident exercise record, or governance approval can sit beside gateway logs in an AISVS package, but none of those artifacts is generated by an inline proxy. I would reject a control matrix that credits one gateway with all fourteen chapters; it hides the work a security team must still assign.

Chapter 4: Identity and authorization for AI calls

Chapter 4 requirements cover the AI request authentication and authorization model. The verification claims require a verifiable identity assertion for the calling principal. That identity needs to propagate across multi-agent chains. Audit records need the human principal rather than only a service credential. Each authorization decision is evaluated against the caller and requested data scope.

Gateway control: identity binding at the request layer. The proxy refuses any AI request that does not carry a verified identity assertion. For agent-to-agent or agent-to-tool calls, the proxy requires the upstream principal's identity to travel with the downstream request. Service-credential-only requests are rejected at L2 and above.

Audit fields the gateway writes per request: principal_identity, acts_on_behalf_of, assertion_signature, authz_decision, policy_id, request_id.

Chapter 5: Prompt-injection input handling

Chapter 5 covers input-side controls: prompt classification, indirect prompt-injection detection (poisoned tool output, retrieved-document injection), and the failure mode where adversarial content rides in through a trusted-looking channel.

Gateway control: prompt and tool-output classification on the request path. Every prompt is parsed for adversarial patterns, role-shift markers, and injected instructions, with the classification result attached to the request as a policy input. Tool responses are classified before they re-enter the agent's context window. Requests with high injection signal strength against sensitive tool scopes are blocked or routed through a stricter policy.

The verification levels matter here. L1 asks for prompt-injection detection in some form. L2 requires the classification result to be available as a policy input. L3 requires the classification to gate sensitive tool invocation.

Chapter 6: Output and response filtering

Chapter 6 verification claims cover the response path. A response that contains regulated PII, secrets, or internal infrastructure references should be filtered or blocked before it returns to the caller. The verification asks for deterministic, log-able filtering, not probabilistic model guardrails.

Gateway control: response classification and egress policy. The proxy intercepts the model response, runs classification against the data taxonomy the deploying organization has defined, and applies an egress policy bound to the calling identity. Filtered tokens are recorded with their classification reason. Blocked responses produce an audit record explaining the block.

This is where model guardrails as a control explicitly fail the verification. Guardrails produce probabilistic model behavior rather than an independent enforcement decision. AISVS L2 and above require deterministic enforcement that is independent of the model.

Chapter 7: Audit logging for AI decisions

Chapter 7 reads like a verification rewrite of EU AI Act Article 12 and 19. The required log fields: timestamp at request and response boundaries, principal identity, agent identity, policy ID applied, classification of prompt and response, tool invocations triggered, decision outcome, and a verifiable signature over the record.

Gateway control: per-decision audit record committed before the response returns to the application. The record is signed and stored outside the application that initiated the AI call. The application cannot mutate or suppress the record. This is the self-attestation control gap I covered in the Article 12 walk-through, now expressed as a testable AISVS requirement.

L3 adds tamper-evidence: the record must be cryptographically chained so post-hoc edits are detectable.

Chapter 8: MCP server authentication and tool invocation

Chapter 8 is one of the chapters that arrived because of the speed at which Model Context Protocol (MCP) deployment moved through enterprise stacks. The verification claims: every MCP server connection must mutually authenticate; tool invocations must propagate the calling principal; sensitive tools must be tagged and gated by per-tool policy.

Gateway control: MCP-aware policy enforcement. The proxy treats MCP traffic as first-class AI traffic, applies the same identity-binding and per-tool authorization controls as direct LLM calls, and produces audit records in the same format. The boundary distinction matters: the gateway enforces MCP traffic that flows as HTTP between the agent and the MCP server. MCP servers reached via STDIO or local IPC sit outside this enforcement boundary.

What sits outside the gateway

Chapters 1, 2, and 3 (training data integrity, model lifecycle, supply chain), chapters 10 and 11 (deployment safety, third-party risk), and chapters 13 and 14 (incident response, governance) are not gateway-enforceable. A control inventory that claims otherwise is overreaching.

Specifically: AISVS requirements that cover training-data poisoning, model evaluation, model card content, or supply-chain provenance live in the MLOps and data platform, not in a gateway at the request layer. AISVS requirements that cover security program maturity, incident response runbooks, or board reporting live in GRC and SOC operations.

The gateway can produce evidence that feeds other chapters. The per-decision audit record is the primary evidence source for chapter 12 (monitoring) and chapter 13 (incident response triage), and it backstops chapter 14 (governance reporting). Producing evidence and enforcing the control are different things; the verification language tracks the distinction.

DeepInspect

This is exactly what DeepInspect does. DeepInspect sits inline between authenticated users or agents and the LLMs they call, enforces identity-bound policy on every request and response, and writes a per-decision audit record outside the calling application. The control set maps directly to AISVS chapters 4 through 9 and produces the evidence stream that chapters 12 through 14 require.

The architecture is stateless: each request is evaluated against identity, prompt classification, response classification, and the policy in effect, then resolved with a pass or block decision before the traffic continues. There are no provider API keys stored in the proxy and no long-lived auth state to compromise. The audit record commits before the response returns to the application, which closes the self-attestation gap chapter 7 verifies against.

If your security team is reading AISVS 1.0 against a current AI deployment, the chapters 4-9 mapping is the fastest place to look. Book a demo today.