10. Verifying AI Applications: AISVS and LEARN

Introduction

You have shipped an AI feature. Your security lead asks a reasonable question: “How do we know it’s secure?”

Nothing you have learned so far answers that question in a form anyone can check. The Blueprint tells you what to deploy, layer by layer, and it is an infrastructure answer to an infrastructure question. Section 9’s loop tells you how to keep those controls aimed at arriving attacks. Both are about the platform around your application. Neither hands you a list of things a reviewer can walk through and mark pass or fail on the code you wrote.

That gap has a name, and until recently it was a genuine hole in the field: there was no application-level equivalent of the checklists that web application security has used for a decade. OWASP closed it on 24 June 2026 with the Artificial Intelligence Security Verification Standard (AISVS) 1.0 – 191 testable requirements across 12 chapters, every one phrased as “Verify that…”, modelled directly on the ASVS that web security already runs on.

This section teaches AISVS as the thing you actually verify against, and keeps LEARN – five letters covering the application-level practices this course has taught since Chapter 1 – as the recall aid that gets you to the right chapter when you are away from the document. The two do different jobs. A mnemonic is for remembering; a standard is for proving. Reach for the mnemonic in a design review and the standard in an audit.

What AISVS Is – and What It Is Not

AISVS is a catalogue of testable security requirements for AI-enabled systems. It does not tell you what can go wrong – that is the Top 10 lists’ job – and it does not tell you what product to buy. It tells you what to check.

The shape of it, as of version 1.0:

The twelve chapters:

Note the weighting. C9 and C10 together are 57 of the 191 requirements – 30% of the standard, all of it agentic. That is the same conclusion Chapter 2 Section 5 reached from the attack side, arrived at independently by a different group of people.

Pin the version in every citation

AISVS identifiers are stable within a version and may move between versions. OWASP’s own guidance is to write v<version>-C<chapter>.<section>.<requirement> – so v1.0-C9.4.3, not C9.4.3 – and to treat a bare identifier as meaning “whatever is current,” which is exactly the ambiguity that breaks a document two years later.

What AISVS explicitly is not

OWASP is unusually direct about the boundaries, and they matter for how you use it:

• Not a governance framework. NIST AI RMF and the EU AI Act cover that ground, and Section 11 is where this course does.
• Not a risk management framework. AISVS supplies the technical controls a risk process points at; it does not tell you how to assess risk.
• Not a tool recommendation list. It is vendor-neutral, which is precisely why it is the right thing to hold a supplier to.

Where it sits among the frameworks you already know

Chapter 2 Section 1 taught you to pick a framework by the question it answers. AISVS adds a fourth question, and OWASP positions it as supplying “the detailed controls to mitigate” the two Top 10 lists:

The first three describe threats. AISVS and the Blueprint describe responses – AISVS at the application, the Blueprint at the platform. A finding from the Top 10 lists becomes an AISVS requirement to verify and a Blueprint layer to deploy.

Choosing Your Level

Every AISVS requirement carries a level, and the level is the mechanism that stops a 191-item list from being unusable.

OWASP’s guidance is that most production systems should target Level 2. The distribution is deliberately front-loaded: of the 191 requirements, 51 are Level 1, so a team starting from nothing has a bounded first target rather than an aspirational one.

The ownership split is the same one running through all of Chapter 3. A platform team can satisfy C4 (Infrastructure) and much of C5 (Access Control) on your behalf, and no platform team can satisfy C2, C7 or C9 for you – those are properties of the application you wrote. Run Section 9’s ownership table alongside your level choice and mark each chapter ours, theirs, or shared before you start evidencing anything.

LEARN: The Recall Overlay

Five letters, covering the application-level practices this course has taught across all three chapters. Each one is an index into AISVS, not a substitute for it.

L – Linguistic Shielding

Treat every element of the context window as untrusted input, not just the user’s message.

What actually works, and each item maps to a requirement:

• Normalise before inspecting – v1.0-C2.1.1 requires input normalisation before tokenization or embedding, and v1.0-C2.1.2 requires that encoding and representation smuggling be detected and mitigated. This is Chapter 2’s filter-evasion finding turned into a check: a filter that tokenizes differently from the model is inspecting a different string.
• Screen every steering input, not the prompt field – v1.0-C2.1.3 requires that “all inputs that could steer model behavior” be treated as untrusted and screened. Retrieved documents, tool outputs, agent messages, uploaded files.
• Reject over-length input rather than truncating – v1.0-C2.1.4 is explicit that controls “must reject inputs that exceed token limits rather than truncating them”, because silent truncation decides for you which half of a payload survives.
• Encode reserved special tokens as literals – v1.0-C2.1.7, which closes the special-token injection route Chapter 1 Section 4 describes.

And carry Chapter 2’s verdict on the whole letter: input filtering is a cost-raiser, not a boundary. v1.0-C2 is worth every requirement in it, and the measured residual on the best production guardrail on record is still low single digits.

E – Execution Supervision

Bound what the agent may do, and what it may do irreversibly. This is v1.0-C9, the largest chapter in the standard, and the one where AISVS is most obviously ahead of common practice.

• Budgets and circuit breakers – v1.0-C9.1.1 and C9.1.2 require per-tool quotas and per-execution budgets (recursion depth, token use, monetary spend) enforced by the runtime, and C9.1.3 requires a swarm-level kill switch.
• Approval gates on the irreversible subset – v1.0-C9.2.1 requires the runtime to block privileged, high-impact or irreversible actions pending verified human approval. This is Layer 4’s human-in-the-loop enforcement expressed as a check.
• Reversibility classification – v1.0-C9.2.3 requires each high-impact action to carry a trusted classification (read-only, reversible, externally reversible, irreversible), and C9.2.4 requires the runtime to act on it. This is the structural version of the advice Chapter 2 keeps giving: gate the irreversible subset, not everything.
• Isolate untrusted data from tool-calling – v1.0-C9.3.5 requires that “components processing untrusted data are isolated from tool-calling capabilities, ensuring that compromised data processing cannot trigger unauthorized tool invocations.” That single requirement breaks the lethal trifecta at its third leg without needing to detect anything.
• Verify externally-named resources before invoking them – v1.0-C9.3.7 requires that resources named in model output be checked against an allow-list before the agent installs or invokes them.

A – Access Control

Separate, scoped credentials per function, enforced outside the model. v1.0-C5, with the agentic identity requirements in v1.0-C9.4.

• Default-deny on every AI resource – v1.0-C5.2.1 covers datasets, endpoints, vector collections, embedding indices and compute instances with explicit allow-lists.
• Carry the end user’s authorization into retrieval – v1.0-C5.2.2 requires retrieval pipelines to enforce the end-user’s authorization context at each retrieval and assembly stage “rather than relying solely on” the service’s. This is the single most commonly missed requirement in RAG systems, and it is the mechanism behind most “the assistant showed me someone else’s document” incidents.
• Filter after inference too – v1.0-C5.2.4 requires post-inference filtering to prevent responses including data the requester is not authorised to receive, because retrieval scoping and generation are different failure points.
• Agents are principals – v1.0-C9.4.1 requires each agent instance to hold a unique cryptographic identity and authenticate as a first-class principal downstream. An agent borrowing a shared service account is unattributable by construction.
• Isolate the policy decision point – v1.0-C5.2.5 requires the agent’s authorization decision point to sit outside the agent’s execution environment. An agent that can reach its own policy engine has no policy engine, which is the same structural error as CVE-2025-53773 below.

Credentials never go in the system prompt, the conversation, or memory. Chapter 2 established that anything in the window is reachable by anyone who can talk to the model.

R – Robust Prompt Hardening

Here the honest framing has changed most, and it is worth being blunt: you are testing the prompt, not trusting it.

The earlier version of this section taught role boundaries “the model cannot be talked out of.” Chapter 2 Section 2 exists to disprove exactly that. Alignment and role adherence are probabilistic, phrasing-sensitive, provider-set properties, and no wording makes a system prompt a boundary. Prompt hardening raises cost. It does not hold.

What survives, and what to verify:

• Adversarial testing as a standing requirement – v1.0-C11 Adversarial Robustness is a chapter, not a technique, and this is where prompt hardening earns its place: you measure whether your phrasing survives, you do not assert it. ATLAS names the same practice AML.M0035 AI Red Team, and Section 9’s loop is how the results stop decaying.
• Output format enforcement – v1.0-C7.1 treats structure as a control: an output constrained to a schema cannot carry a paragraph of leaked instructions.
• Detect hidden and encoded content in outputs – v1.0-C7.3.4 covers homoglyphs, formatting, metadata and structured fields, which is the return path of the evasion families in Chapter 2.

The practical rule: keep the system prompt short, put nothing in it that would hurt if published, and hold your defence in the action scope rather than the wording.

N – Nondisclosure

Inspect what leaves, and constrain what the output can trigger.

• Block system prompt and backend disclosure – v1.0-C7.3.2 requires output filters that detect and block responses disclosing system prompt content or backend data. This is LLM08: Hidden Context Exposure, covered as an attack in Chapter 2 Section 6.
• Classify every response – v1.0-C7.3.1 requires automated classifiers on every response against defined harmful content categories.
• Prevent output from triggering outbound requests – v1.0-C7.3.3, and this one deserves attention out of proportion to its length. It is the EchoLeak control: the exfiltration leg of that attack was a rendered image request to an allowlisted proxy. An output that cannot cause a fetch cannot exfiltrate through a renderer.
• Propagate classification labels downstream – v1.0-C5.2.7 carries data classification into embeddings, prompt caches and model outputs, which is Layer 1’s discipline extended to the artifacts your application creates.

What LEARN Does Not Cover

This is the section that justifies the standard, and leaving it out is how a mnemonic quietly becomes a ceiling.

LEARN’s five letters reach five chapters. Six of the twelve have no letter at all:

Two of these deserve singling out because the course has spent real time on the attacks and never on the checks.

Memory (v1.0-C8). Chapter 2 Section 5 rates ASI06 the worst agentic category to already have – both invisible to the user and indefinitely persistent. The chapter is small and specific: C8.1.3 requires retrieval operations to enforce scope constraints, C8.1.2 makes document metadata tags immutable after the initial write, C8.3.2 requires that memory can be reset, and C8.3.3 requires quarantined content to be retained but excluded from retrieval. That last pair is the incident-response capability for a poisoned memory, and most systems discover they lack it during the incident.

MCP (v1.0-C10). Three of this course’s case studies are MCP incidents – CurXecute, MCPoison, and the postmark-mcp rug pull. The chapter answers them directly: C10.1.2 allow-lists MCP servers, C10.1.3 requires locally launched servers to run in a least-privilege sandbox, C10.2.5 requires access control on every tool invocation validating both the tool and the specific argument values, and C10.2.7 forbids passing client tokens through to downstream APIs.

Worked Example: Verifying an Agent Against v1.0-C9

Take the incident Section 9 closes on and run it the other way – from the attack to the requirements that would have failed the review.

The incident. Injected text in repository content caused GitHub Copilot to write "chat.tools.autoApprove": true into .vscode/settings.json, disabling every confirmation prompt, after which it executed arbitrary commands with the developer’s privileges. Wormable, because the payload could be committed back.

What a v1.0-C9 review would have flagged, before the CVE existed:

Four Level 1 and Level 2 failures, all findable at design review, none requiring knowledge of the specific attack. That is the argument for a verification standard in one table: C9.2.5 was not written in response to CVE-2025-53773 – it describes the class, and any agent that can edit its own approval configuration fails it whether or not anyone has published an exploit yet.

Compare that with what Section 9’s loop could do here. SCAN would have found that the agent follows instructions in files it reads. PROTECT could not have caught the payload as text, because it was an ordinary sentence about a configuration setting. The loop finds the susceptibility; the standard names the structural control. Neither replaces the other, and this incident needed both.

Section 10 → OWASP Mapping

Application-level verification is not a layer, so it does not own categories the way Layers 1-6 do. What it does is give each category a checkable counterpart, which is what the master mapping has been pointing at all along.

Read the third column and the pattern matches every layer section in this chapter: verification establishes that a control exists and is correctly built. It never establishes that the control cannot be beaten. A fully-passing AISVS Level 2 assessment is a strong statement about your engineering and not a statement about your adversary.

Blueprint, LEARN, AISVS: Which to Reach For

The last row is the one to internalise, and it is why this section sits after Section 9 rather than before it. An AISVS assessment is true on the day it is signed. The model gets updated, a retrieval source is added, a tool binding changes – and requirements that passed now describe a system you no longer run. Verification and the continuous loop are the same discipline seen from two ends: the standard tells you what “correct” means, and the loop tells you whether you are still it.