NIST and OWASP Agentic: Asqav Compliance Receipt Mapping

NIST SP 800-53 Rev. 5, the NIST AI Risk Management Framework, and the OWASP Top 10 for Agentic Applications all call for tamper-evident records of what an AI agent did, when it acted, under whose authority, and what controls ran. This page maps those guidance objectives to the specific fields of an Asqav Compliance Receipt, field by field.

Two points to keep in mind before reading the tables below:

• Mapping direction. Receipt fields provide verifiable evidence of an activity that an audit objective asks you to record. A signed receipt supports an AU-family control objective; it does not certify that you have met every clause of a publication.
• Field source. Every Asqav field cited here is a deployed receipt field. No field in this mapping is invented for the purpose of this page.

NIST SP 800-53 Rev. 5: AU Control Family

NIST SP 800-53 Rev. 5 defines the AU (Audit and Accountability) control family. The controls below apply directly to systems that record AI agent actions. The verbatim control statements are quoted from NIST SP 800-53r5 via CSF Tools, which reproduces the published NIST text.

AU-2: Event Logging

"Identify the types of events that the system is capable of logging in support of the audit function."

NIST SP 800-53 Rev. 5, AU-2

Receipt fields that provide verifiable evidence for AU-2:

• action_type (namespace:verb format, e.g. tool:search, llm:egress, deploy:production) - the categorized event type bound into the signed envelope.
• receipt_type (e.g. protectmcp:decision, protectmcp:lifecycle, protectmcp:observation) - identifies the class of governance event recorded.
• capture_topology (controlled vocabulary: in_process_sdk, network_proxy, ebpf_observer, etc.) - records how the event was captured, so an auditor knows whether the logging mechanism itself was in scope.

AU-3: Content of Audit Records

"Ensure that audit records contain information that establishes the following: (1) What type of event occurred; (2) When the event occurred; (3) Where the event occurred; (4) Source of the event; (5) Outcome of the event; and (6) Identity of any individuals, subjects, or objects/entities associated with the event."

NIST SP 800-53 Rev. 5, AU-3

The six AU-3 fields map directly to receipt content:

AU-8: Time Stamps

AU-8 requires that systems use internal clocks to generate timestamps for audit records and map audit record timestamps to Coordinated Universal Time (UTC). Asqav's issued_at field is a server-attested UTC timestamp bound into the signed receipt. The anchors array carries RFC 3161 and OpenTimestamps inclusion proofs, providing externally-verifiable time bounds that an auditor can verify without trusting Asqav's clock alone.

AU-9: Protection of Audit Information

"Protect audit information and audit logging tools from unauthorized access, modification, and deletion."

NIST SP 800-53 Rev. 5, AU-9

Each Asqav receipt is signed with ML-DSA-65 (NIST FIPS 204) by an operator key held outside the agent's environment. The signature covers the canonical bytes of every field listed in this mapping. A field that is modified after signing produces a verifiable signature failure. The signing key is held by Asqav as a party unaffiliated with the agent's operator, so the recording party cannot undetectably alter or delete a signed record it does not hold the key for.

• previousReceiptHash (SHA-256 of the prior receipt's canonical bytes) - the per-agent hash chain means removing or reordering records breaks every subsequent link, making deletion detectable.
• anchors (RFC 3161 / OpenTimestamps) - durable external witnesses that pre-date any claimed modification time.

AU-10: Non-repudiation

"Provide irrefutable evidence that an individual (or process acting on behalf of an individual) has performed [organization-defined actions]."

NIST SP 800-53 Rev. 5, AU-10

AU-10 is the control most directly served by signed receipts. Asqav binds agent_id, action_type, issued_at, and the complete payload into a single ML-DSA-65 signed envelope. The signing key is held by an unaffiliated party, so neither the agent operator nor the agent itself can deny that a sign call was made without forging a FIPS 204 post-quantum signature. The optional authorized_under_mandate block further records which principal authorized the action, extending non-repudiation to the delegation chain.

AU-11: Audit Record Retention

"Retain audit records for [organization-defined time period] to provide support for after-the-fact investigations of incidents."

NIST SP 800-53 Rev. 5, AU-11

Asqav receipts are exportable as JSON and CSV via the Audit Export capability. The previousReceiptHash chain provides integrity across the retained record set: a retention system can verify that no receipt has been removed or reordered since export. Receipt types protectmcp:lifecycle:risk_acceptance and protectmcp:lifecycle:code_authorship carry their own retention-relevant fields (accepted_at, expires_at, commit_sha, repo_ref) bound into the signed bytes at the time the action occurred.

AU-12: Audit Record Generation

"Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2."

NIST SP 800-53 Rev. 5, AU-12

The controls_evaluated block (server-built, dropped if caller-supplied) records which enforcement controls actually ran on each sign call: emergency_halt, delegation_scope, quorum, mandate, policy, content_scan. An absent key means the control did not run; it does not mean the control passed silently. This design means the audit record generation mechanism itself is auditable - a verifier can confirm whether scanning or policy evaluation was active for any given action without trusting the caller's representation.

NIST AI Risk Management Framework: GOVERN Function

The NIST AI RMF organizes risk management activities into four functions: Govern, Map, Measure, and Manage. The GOVERN function is most relevant to audit logging because it addresses organizational accountability structures for AI systems. The following subcategories are from the AI RMF Playbook.

GOVERN 6.1: Auditability Mechanisms

"Did you establish mechanisms that facilitate the AI system's auditability (e.g. traceability of the development process, the sourcing of training data and the logging of the AI system's processes, outcomes, positive and negative impact)?"

NIST AI RMF 1.0, GOVERN 6.1

Receipt fields that provide verifiable evidence for GOVERN 6.1:

• controls_evaluated - server-built map of which enforcement controls ran on each action, providing traceability of the governance process itself.
• result_digest (SHA-256 of canonical-JSON tool response) - binds the outcome of each action so a downstream incident can be traced to the exact output that triggered it.
• policy_digest (SHA-256 of the policy evaluated) - enables after-the-fact verification that a specific policy version was in effect at the time of the action.
• risk_class (low / medium / high / unknown) - deployer risk classification bound into the signed receipt, supporting impact assessment in the audit record.
• nist_ai_rmf (caller-supplied list of AI RMF function ids: GOVERN, MAP, MEASURE, MANAGE plus subcategories) - self-declared mapping; the framework_mappings_self_declared guard auto-sets to true when populated.

GOVERN 1.4: Documentation Policies

GOVERN 1.4 calls for standardized documentation policies covering scope and usage, testing and validation results, assumptions and limitations, and plans for deployment and change management. The protectmcp:lifecycle:configuration_change receipt type addresses the change-management dimension directly:

• config_manifest_digest (SHA-256 of canonical-JSON MCP server manifest) - required on configuration change receipts; records what configuration was in effect at change time.
• protectmcp:lifecycle:risk_acceptance receipts carry acceptance_reason, approver_id, and accepted_at - documenting the rationale and authorization for accepting a risk, consistent with typical governance documentation policies.

OWASP Top 10 for LLM Applications 2025

The OWASP Top 10 for LLM Applications 2025 identifies the highest-impact application-level risks for LLM-based systems. Several categories produce evidence needs that Asqav receipts address directly. The category descriptions below are from the OWASP GenAI Security Project.

LLM02:2025 Sensitive Information Disclosure

"Sensitive information can affect both the LLM and its application through unintended exposure or leakage."

OWASP Top 10 for LLM Applications 2025, LLM02:2025

The controls_evaluated.content_scan key records that a content scan ran on the action. An absent key means scanning did not run; a present key means it did - and this is part of the signed envelope, so the verification is not contingent on trusting the caller's word. LLM egress actions can be captured via receipt_type=protectmcp:observation:result_bound with a result_digest binding the exact output bytes.

LLM05:2025 Improper Output Handling

"Improper Output Handling refers specifically to insufficient validation, sanitization, and processing of LLM responses."

OWASP Top 10 for LLM Applications 2025, LLM05:2025

The result_digest field (SHA-256 of the canonical-JSON tool response body) binds the exact output of each action into the signed receipt. When a downstream incident occurs, a responder can compare the result_digest on the receipt against the hash of the output that reached a downstream system, establishing whether the output was modified between signing and delivery.

LLM06:2025 Excessive Agency

"An LLM-based system is often granted a degree of agency enabling autonomous actions."

OWASP Top 10 for LLM Applications 2025, LLM06:2025

LLM06 is the category with the most direct field-level mapping in Asqav receipts:

• controls_evaluated (server-built) - records which authority checks actually ran: delegation_scope, quorum, mandate, policy. A caller-supplied value is dropped before signing, so this cannot be forged.
• authorized_under_mandate (mandate_id, issuer_id, scope_digest, verified) - records that the action was signed under a registered mandate. An action outside the mandate's scope is visible in the record.
• risk_class - deployer-assigned risk level bound into the signed bytes. An action classified high that was not reviewed is traceable as such.

OWASP Top 10 for Agentic Applications 2026

The OWASP Top 10 for Agentic Applications 2026 addresses risks specific to autonomous, multi-step AI systems. Several categories map to Asqav receipt fields that provide verifiable evidence of what an agent was authorized to do and what it actually did.

ASI01: Agent Goal Hijack

Attackers manipulate agent decision pathways through indirect means such as documents or external data sources. The controls_evaluated.content_scan key records whether content scanning ran on the action, and the previousReceiptHash chain makes it possible to reconstruct the sequence of actions leading up to a detected hijack. The signed receipt preserves the exact input context and the policy decision, so a responder can determine at which action the agent's behavior diverged from its authorized objectives.

ASI03: Identity and Privilege Abuse

Agents operating without distinct, governed identities while managing permissions dynamically. Asqav binds a cryptographically distinct agent_id into every receipt. The authorized_under_mandate block records the delegation scope under which the agent acted. Together, these fields provide the identity and privilege traceability needed to determine whether an agent acted within its authorized scope or exceeded it.

ASI06: Memory and Context Poisoning

Corrupted long-term memory or retrieval-augmented generation data can bias future agent decisions. The result_digest field binds the exact output of each action into the signed receipt, providing a point-in-time record of what the agent produced at each step. Combined with the previousReceiptHash chain, this enables a responder to reconstruct the output sequence that preceded a detected poisoning event, establishing when and where the corruption first appeared in the audit trail.

ASI07: Insecure Inter-Agent Communication

Intercepted, spoofed, or replayed messages between agents lacking integrity properties. The bilateral receipt capability (receipt_type=protectmcp:acknowledgment, counterparty_binding with SHA-256 digest of canonical request bytes) provides verifiable evidence that a specific message was received and acknowledged by a specific agent at a specific time. This creates a tamper-evident record of inter-agent communication that a responder can verify without trusting either party's own logs.

ASI10: Rogue Agents

Misaligned agents deviating from their intended function. The combination of controls_evaluated (which controls ran), authorized_under_mandate (what the agent was authorized to do), and risk_class (how the deployer classified the action) gives an auditor three independent signals of whether the agent operated within its intended scope. The incident_class field (DORA ITS string or array) supports multi-regime incident classification when a rogue agent action triggers both an internal governance response and an external reporting obligation.

The nist_ai_rmf taxonomy field

Asqav carries an optional nist_ai_rmf wire field on every receipt. It accepts a caller-supplied list of AI RMF function ids (for example GOVERN, GOVERN-6.1, MEASURE-2.5) that the producer asserts the action maps to.

• nist_ai_rmf (list of strings): caller-supplied AI RMF function ids. Optional on the wire. Never mandatory on any receipt_type.
• framework_mappings_self_declared (boolean): server-set guard. Auto-flips to true whenever nist_ai_rmf (or any sibling taxonomy field) is populated, even if the caller passes false.

The field is self-declared: Asqav preserves the caller's classification verbatim and marks it producer-declared. The signed binding means the classification cannot be modified after the receipt is issued without breaking the ML-DSA-65 (FIPS 204) signature. This is the same design as the owasp_llm_top10 field: the signed label, not the content it points to, is what Asqav attests.

What Asqav does not do

Asqav is not an AI risk assessment tool, a policy compliance certifier, or an NIST conformance validator. It does not evaluate whether an organization meets AU-2 through AU-12, does not assess AI RMF maturity, and does not verify that an action was aligned with an organization's AI governance policy. It records, in a signed and tamper-evident receipt, the evidence a compliance team or auditor needs to make those assessments. The NIST and OWASP guidance frames what evidence is needed; Asqav provides the mechanism to generate and preserve that evidence in a form an auditor can verify independently.

Related documentation

• OWASP LLM Top 10 Mapping
• Control Attestation
• Threat-Framework Mapping
• Emergency Halt
• Mandate Binding
• Independent Verification
• Third-Party Notary
• NIST AI RMF