AIUC-1 Evidence: How Asqav Receipts Serve The AI Agent Security Standard

AIUC-1 is a certification standard for AI agents, organised across six domains: Data and Privacy, Security, Safety, Reliability, Accountability, and Society. It asks an organisation deploying agents to log agent activity, plan for failure, document its controls, and produce evidence on audit that those controls operate.

Asqav does not certify against AIUC-1 and does not run your agent platform. It produces the signed, tamper-evident activity record an AIUC-1 audit reads when it checks the logging and accountability requirements.

What this page maps: the AIUC-1 domains that call for an auditable activity record, against the Asqav receipt types, control-attestation fields, and audit trail, all already shipping in production.

Where the line sits: this is a mapping page, not a new Asqav capability. Asqav is the evidence and notary layer underneath an AIUC-1 deployment.

Where Asqav fits in an AIUC-1 audit

AIUC-1's domains split into two kinds of work:

Control work (input filtering, adversarial testing, harmful-output prevention) lives in your agent platform and your security program.
Evidence work (logging agent activity, documenting which controls ran, recording who accepted a residual risk) is what an auditor inspects.

A self-attested activity log is weak evidence because the audited party also controls the log.

Asqav signs each agent action into a receipt the producing party cannot later edit, and it publishes the verify key independently of the producer. The auditor reads an activity record whose integrity does not rest on trusting the audited party's storage. That is the structural property the AIUC-1 Accountability domain needs.

Mapping AIUC-1 domains to Asqav

Domain E Accountability: log AI system activity

The Accountability domain asks the organisation to log AI system activity and maintain compliance documentation. Asqav's signed receipt is the activity record:

signature_records columns: action_type (namespace:verb token from /.well-known/governance.json), action_hash, payload_digest, agent_id, signed_at (UTC, server-issued), receipt_type, capture_topology.
signature_records.result_digest (SHA-256 of the canonical-JSON tool response body) binds the outcome of each action, not only its request.
Per-agent ML-DSA (NIST FIPS 204) identity signs each receipt. The verify key is at GET /.well-known/jwks.json, exposed independently of the producer.
asqav audit-pack export produces an offline tarball with the receipts, the verify key, and the IETF receipt-format reference, so an auditor verifies activity without live access to your platform.

Domain E Accountability: AI failure plan and residual-risk records

The Accountability domain asks for failure planning and documented handling of harmful outputs and hallucinations. Where the deployment accepts a residual risk rather than blocking, Asqav records it inside the signed chain:

protectmcp:lifecycle:risk_acceptance: a signed receipt that records who accepted which risk and when, so an accepted residual is a record, not a verbal decision.
protectmcp:lifecycle:configuration_change: a signed receipt binding the before-and-after manifest digest when a control configuration changes, so failure-plan changes leave a trail.

Domain B Security: which controls actually fired

The Security domain asks for access-privilege enforcement and adversarial robustness. Asqav records which enforcement controls genuinely ran on each action, with an omission-over-false design:

controls_evaluated (server-built): a map whose keys appear only when that control 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} records that an action was signed under a registered mandate, so an out-of-scope action 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 recorded. The Security domain's "stop the agent" requirement becomes provable.

Domain D Reliability: safe tool-call restrictions

The Reliability domain asks for safe tool-call restrictions. signature_records.tool_fingerprint anchors which tool actually ran, and signature_records.config_manifest_digest (SHA-256 of the active tools/list manifest) lets an auditor detect silent capability drift between successive receipts.

Cross-framework alignment

AIUC-1 references several frameworks an organisation already maps against, including the NIST AI Risk Management Framework, ISO/IEC 42001, MITRE ATLAS, and the OWASP Top 10 for LLM. Asqav carries optional self-declared taxonomy fields for each (nist_ai_rmf, iso_42001, mitre_atlas, owasp_llm_top10) and a server-set framework_mappings_self_declared guard that auto-flips to true when any is populated. A receipt can therefore carry the AIUC-1-adjacent framework ids the producer asserts, inside the same signed envelope as the activity record. The Threat-Framework Mapping page documents the taxonomy fields and the self-declared honesty model.

What Asqav does not do

Asqav is not an AIUC-1 auditor and does not issue or hold AIUC-1 certification. It does not run adversarial testing, filter inputs, prevent hallucinations, or author your AI failure plan. It does not validate that a self-declared framework id is real. AIUC-1 certification is issued by an accredited auditor after a review. Asqav supplies the signed activity evidence that review reads, it does not replace it.