OWASP Top 10 for LLM And Agentic Apps: Asqav Receipt Mapping

The OWASP Top 10 for Large Language Model Applications ranks the highest-impact application-level threats to LLM and agentic systems: prompt injection, sensitive-information disclosure, excessive agency, and the rest.

Asqav does not block those threats in line. It records, in a signed and tamper-evident receipt, the evidence a security team needs to detect, triage, and prove its response to them.

What this page maps: the OWASP LLM risk categories that produce auditable evidence, against the Asqav owasp_llm_top10 taxonomy field, the controls_evaluated.content_scan key, and the enforcement primitives, all already shipping in production.

Where the line sits: Asqav is the evidence and notary layer. The owasp_llm_top10 entries on a receipt are caller-supplied, not Asqav-verified.

The `owasp_llm_top10` taxonomy field

Asqav carries an optional owasp_llm_top10 wire field on every receipt. It is a list of OWASP Top 10 for LLM ids (for example LLM01, LLM02) that the producer asserts the action maps to.

owasp_llm_top10 (list of strings): caller-supplied OWASP Top 10 for LLM ids. Optional on the wire. Never mandatory on any receipt_type.
framework_mappings_self_declared (boolean): server-set guard. The cloud auto-flips it to true whenever owasp_llm_top10 (or any sibling taxonomy field) is populated, even if the caller passes false.

The field is self-declared. The cloud preserves the caller's classification verbatim and marks it producer-declared, so a verifier knows the mapping came from the producer, not from Asqav. The signed binding guarantees the receipt was issued against THAT classification, which is what lets an auditor trust that an incident was not re-labelled after the fact.

The field is published on /.well-known/governance.json and specified in draft-marques-asqav-compliance-receipts on the IETF Datatracker.

Mapping OWASP LLM categories to Asqav

LLM01 Prompt Injection

OWASP LLM01 covers direct and indirect prompt injection. When content scanning runs on a sign call, the server-built controls_evaluated.content_scan key records that the scan executed (an absent key means scanning never ran on that action). This key is part of the signed envelope, so a verifier can confirm whether scanning was active without trusting the caller's word. Asqav records the scan verdict. It is not an in-line interception proxy that strips the injected prompt before it reaches the model.

LLM02 Sensitive Information Disclosure

OWASP LLM02 covers leakage of sensitive data through model output. The controls_evaluated.content_scan key records that scanning ran on the action (no per-finding verdict field exists). POST /api/v1/observations/llm-egress accepts batched egress rows compatible with Splunk HEC, Elastic Logstash, and Datadog logs intake, so the egress stream lands in the same audit chain a SIEM rule queries.

LLM06 Excessive Agency

OWASP LLM06 covers agents that act beyond their intended authority. Asqav binds the principal's then-granted authority and the controls that actually fired into each receipt:

controls_evaluated (server-built): a map whose keys appear only when that control genuinely ran on the sign (emergency_halt, delegation_scope, quorum, mandate, policy, content_scan) plus the allow result. An absent key means the control never ran, never that it passed silently. A caller-supplied value is dropped before signing.
authorized_under_mandate (server-built): {mandate_id, issuer_id, scope_digest, verified} when the action was signed under a registered mandate, so an action outside the mandate's scope is visible in the record.

The org-wide emergency-halt kill-switch fails closed: when halt is engaged, the sign path refuses, and the refusal is itself recorded. This is the enforcement primitive an OWASP LLM06 control reaches for when an agent must be stopped and the stop must be provable.

LLM05 Improper Output Handling and downstream review

OWASP LLM05 covers unvalidated model output flowing into downstream systems. signature_records.result_digest (SHA-256 of the canonical-JSON tool response body) binds the outcome of each action, so a downstream incident can be traced to the exact output that triggered it.

How an auditor or responder uses the mapping

A responder holding the receipt works through four steps:

Read the owasp_llm_top10 lists plus framework_mappings_self_declared from the signed envelope.
Confirm the self-declared flag matches the populated lists.
Map each id against the canonical OWASP reference.
Cross-check controls_evaluated.content_scan for the action.

The signed binding means none of those values can be mutated without breaking the ML-DSA-65 (NIST FIPS 204) signature.

What Asqav does not do

Asqav is not a prompt-injection firewall, a guardrail model, or an in-line proxy. It does not block an injected prompt before the model sees it, and it does not validate that an owasp_llm_top10 id is real or that the action belongs in that category. It records the scan verdict, the controls that fired, and the producer's classification inside a tamper-evident envelope. The OWASP categories are a way for the producer to label the evidence. Asqav signs the evidence and the label.