A signed agent receipt answers one question well: did this agent perform this action, under this policy, at this time. An auditor or a buyer usually asks a second question right after. Which control does that map to. Which line of NIST, which OWASP risk, which article of the regulation.
Most tooling answers the second question in a separate place. The action log lives in one system and the control-coverage spreadsheet lives in another, and an auditor has to trust that the two line up. Asqav puts the mapping inside the signed receipt, so the answer to both questions travels in one tamper-evident record. This post walks through how that works across four bodies of guidance, and it links the reference pages that carry the full field-by-field detail.
The mapping direction, stated plainly
One thing to fix before the tables. A receipt field provides verifiable evidence of an activity that a control objective asks you to record. It supports that objective. It does not certify that your organization has met every clause of a publication. Asqav records evidence in a form an auditor can verify; the auditor still makes the judgment. Keeping that line clear is what makes the mapping honest rather than a compliance badge.
The taxonomy fields a receipt can carry
Asqav binds caller-supplied control mappings into the signed receipt through seven optional wire fields plus one server-set guard. The seven fields reference the frameworks a compliance pipeline already uses.
| Field | What it carries |
|---|---|
mitre_techniques | MITRE ATT&CK technique ids |
mitre_atlas | MITRE ATLAS ids for AI-system threats |
owasp_llm_top10 | OWASP Top 10 for LLM ids |
nist_ai_rmf | NIST AI RMF function ids and subcategories |
iso_42001 | ISO/IEC 42001 control ids |
eu_ai_act_articles | EU AI Act article ids |
rfc3161_timestamp | Base64 TimeStampResp for offline TSA verification |
framework_mappings_self_declared | Server-set guard, described below |
All seven caller-supplied fields are optional. None is mandatory on any receipt type. A decision receipt with taxonomy binding looks like this.
{
"action_type": "api:call",
"receipt_type": "protectmcp:decision",
"policy_decision": "permit",
"mitre_techniques": ["T1059", "T1078"],
"owasp_llm_top10": ["LLM01", "LLM02"],
"nist_ai_rmf": ["GOVERN-1.1", "MEASURE-2.7"],
"eu_ai_act_articles": ["Article-12", "Article-15"],
"framework_mappings_self_declared": true
}The signed envelope binds every one of these fields. A verifier who recovers the receipt later cannot change any value without breaking the ML-DSA signature. The full field list, the sign-time validation rules, and the SDK snippets are on the threat-framework mapping page.
Self-declared, and marked as such
This is the part that keeps the mapping trustworthy. Asqav does not validate that an owasp_llm_top10 value is a real OWASP id, or that a nist_ai_rmf subcategory exists in the published framework. The values are caller-supplied and preserved verbatim. The producer asserts what the action maps to; Asqav signs the bytes.
To stop a false attestation, the framework_mappings_self_declared guard is set by the server. It flips to true whenever any taxonomy list is populated, even if the caller passes false. A verifier reading the receipt sees the self-declared label plainly, so no one mistakes a producer's own classification for something Asqav checked. It is the same asymmetry Asqav uses elsewhere: the signed label, not the content it points to, is what the receipt attests.
NIST SP 800-53: the AU control family
The AU family in NIST SP 800-53 Rev. 5 covers audit and accountability. It maps onto receipt content closely, because a receipt is an audit record. AU-3, the content of audit records, asks that a record establish six things. Each one lands on a receipt field.
| AU-3 element | Receipt field |
|---|---|
| What type of event | action_type, receipt_type |
| When it occurred | issued_at, anchors |
| Where it occurred | capture_topology, tool_fingerprint |
| Source of the event | agent_id, authorized_under_mandate |
| Outcome | controls_evaluated.result, result_digest |
| Identity of the subject | agent_id, authored_by |
Two AU controls are worth calling out. AU-9 asks you to protect audit information from unauthorized modification. Each receipt is signed with ML-DSA-65 by an operator key held outside the agent's environment, so a field changed after signing produces a verifiable signature failure, and the previousReceiptHash chain makes a deletion detectable. AU-10 covers non-repudiation, and it is the control a signed receipt serves most directly. Because the signing key is held by a party unaffiliated with the agent operator, neither the operator nor the agent can deny that a sign call was made without forging a post-quantum signature.
AU-12 addresses record generation, and it is where the controls_evaluated block earns its place. That block is built by the server and dropped if a caller tries to supply it, so it cannot be forged. It records which enforcement controls actually ran on a sign call, such as policy, mandate, quorum, and content scan. An absent key means the control did not run. That makes the audit mechanism itself auditable, which is a nice property to be able to show a reviewer.
NIST AI Risk Management Framework
The NIST AI RMF organizes work into Govern, Map, Measure, and Manage. Its auditability subcategory under Govern asks whether you established mechanisms that make the AI system's processes traceable. The controls_evaluated map traces the governance process, result_digest binds each outcome, policy_digest lets an auditor confirm which policy version was in effect, and risk_class carries the deployer's risk rating into the signed record. Populate the nist_ai_rmf list and the self-declared guard flips, so the mapping is marked producer-declared right there in the receipt.
OWASP: LLM and agentic risks
The OWASP Top 10 for LLM Applications 2025 and the OWASP Top 10 for Agentic Applications 2026 describe application and agent risks that produce clear evidence needs.
Excessive Agency, LLM06 in the 2025 list, has the most direct field-level mapping. A receipt records which authority checks ran through controls_evaluated, what mandate the action was signed under through authorized_under_mandate, and how the deployer classified the action through risk_class. On the 2026 agentic list, several categories line up cleanly. Agent Goal Hijack and the previousReceiptHash chain let a responder reconstruct the sequence leading up to a detected drift. Identity and Privilege Abuse maps to the distinct agent_id and the mandate binding. Insecure Inter-Agent Communication maps to a bilateral receipt with a counterparty binding. Rogue Agents maps to the three independent signals of controls_evaluated, authorized_under_mandate, and risk_class together. The full mapping, category by category, is on the NIST and OWASP receipt mapping page.
NSA guidance on MCP security
In May 2026 the NSA published a Cybersecurity Information Sheet on Model Context Protocol security (U/OO/6030316-26). It sets out recommendations spanning several product categories. Asqav covers the receipt and audit layer of that guidance and is candid about the parts it does not cover.
On signing and verifying MCP messages, Asqav records a server-issued timestamp, a per-receipt nonce that keys the consumer's own duplicate check, and an expiry on each receipt, signs the envelope with ML-DSA-65, and publishes the verify key at a well-known endpoint. On logging and detection, receipt columns capture the action type, the request digest, the tool fingerprint, and a hash of the result, which is the cryptographic-hash-of-output leg the guidance calls for. The honest half matters just as much: Asqav is not a filtering outgoing proxy, not a data-loss-prevention tool, and not an in-line interception proxy, and four recommendations in the sheet belong to a different product class entirely. The NSA MCP guidance coverage page lays out which recommendations are direct, which are partial, and which are out of scope.
Why the mapping belongs in the receipt
A standalone governance tool keeps a control-coverage spreadsheet next to the action log. An auditor then reconciles two systems and hopes they agree. When the mapping rides inside the signed receipt, there is one canonical chain to check, and the cryptographic binding guarantees the receipt was issued against that mapping, not a later one that papered over a missed control.
None of this makes Asqav a conformance validator. It does not score your AI RMF maturity or decide whether you met AU-9. It records, in a signed and tamper-evident receipt, the evidence a compliance team needs to make those calls, in a form the reviewer can verify without trusting Asqav. The guidance frames what evidence is needed. The receipt is the mechanism that preserves it.
Start with the three reference pages: the NIST and OWASP receipt mapping, the threat-framework mapping, and the NSA MCP guidance coverage. Or create a free account and bind a taxonomy-tagged receipt today.