DEV Community: João André Gomes Marques

Self-attested vs independently verifiable receipts

João André Gomes Marques — Sun, 02 Aug 2026 10:00:00 +0000

A receipt is only as credible as the party that vouches for it. The two kinds of receipt differ in one place: who signs.

The distinction

A self-attested receipt is signed by the same platform that ran the agent. The platform vouches for its own agent, so you are trusting that platform's word about itself. There is no independent party in the loop, which makes the receipt an assertion rather than third-party evidence.

An independently verifiable receipt is signed and anchored by a party other than the one that ran the agent. Any counterparty can verify it without trusting the issuing platform. The check runs on your own machine, with no account at the issuer and no call back to it, so the receipt holds up even if the platform that issued it disappears.

Side by side

                        Self-attested
                        Independently verifiable

                        Who vouches
                        The platform that ran the agent
                        An unaffiliated party, separate from the one that ran the agent

                        Can a counterparty verify it
                        Only by trusting the issuing platform's word
                        Yes, on their own machine, with no account and no call to the issuer

                        Tamper evidence
                        The issuer can rewrite its own record
                        Each receipt links to its predecessor in a hash chain and anchors to external witnesses, so edits are detectable

                        Audit trail
                        Held by the issuing platform
                        Anchored and packed into a portable bundle a reviewer can take away

The difference is structural, not a matter of trust in a brand. A self-attested receipt asks a counterparty to take the agent platform at its word. An independently verifiable receipt lets the counterparty check the claim themselves.

How Asqav does it

Asqav is the unaffiliated party in the loop. It signs as an operator independent of the agent's operator, so the receipt does not rest on the agent platform's word. The pipeline maps to five primitives.

Sign. The action is signed server-side with an ML-DSA key (NIST FIPS 204) held under Asqav custody. The agent's operator never holds the signing key, so the recorded party cannot forge or backdate its own record.
Attest. The receipt records the action context and the authorization behind it, so the signed claim is reproducible offline from the payload.
Anchor. Each receipt joins the agent's hash chain and anchors through OpenTimestamps onto Bitcoin, so the tamper evidence does not depend on Asqav's clock or storage.
Verify. Anyone holding the receipt resolves the public verify key and checks the signature themselves, with no Asqav account and no call to Asqav.
Audit-pack. Receipts export into a compliance bundle, with PDF export for the EU AI Act deployer audit pack, portable to a reviewer.

Walk the whole flow in the quickstart, or scaffold a project and validate your setup with asqav quickstart. For the offline procedure, see independent verification.

Asqav provides cryptographic governance for AI agents through signed, tamper-evident receipts covering actions, policy decisions, result digests, and independent timestamps. Receipts support recordkeeping and independent verification; they do not by themselves establish legal compliance, which depends on the system and jurisdiction. Founded by João Marques.

The OWASP AI Exchange cites the Asqav compliance-receipts profile

João André Gomes Marques — Tue, 28 Jul 2026 10:00:00 +0000

The OWASP AI Exchange now cites the Asqav compliance-receipts profile. The Exchange's page on input threats, in the section on monitoring and secure logging, describes a signed-receipt approach to tamper-evident logging and links draft-marques-asqav-compliance-receipts as one open profile that sets out receipt-format obligations under the EU AI Act, DORA, and US sector regulations.

What the citation says

The secure-logging guidance recommends tamper-evident logging to verify that records stay unmodified after an incident. It describes a signed-receipt approach that binds a hash of the input, the output, and the processing context to a per-event signature, paired with an independent time anchor so the signer cannot backdate the "when". It then names the compliance-receipts profile as an open definition of those receipt-format obligations. The citation sits on the page at owaspai.org/docs/2_threats_through_use.

The Exchange also sets out why tamper-evident logging is harder for AI than for conventional applications. Output is non-deterministic, so a signature over the response alone proves little. Retention runs to multiple years under the EU AI Act and DORA. And for agents it matters who acted under whose authority, and which model and tools were available when the action was signed. Those are the properties the receipt format is built around.

Who runs the AI Exchange

The OWASP AI Exchange is an OWASP Flagship project. Its founder and lead editor is Rob van der Veer, Chief AI Officer at Software Improvement Group, who also works on ISO/IEC 27090 and the EU AI Act standard in CEN/CENELEC. Through an official liaison partnership, the Exchange feeds its content into ISO/IEC 27090, the international standard for AI security. Rob van der Veer personally thanked the founder for the contribution that led to the citation.

What it means

The citation is independent recognition of the signed-receipt approach to AI-agent accountability. The Exchange describes the same shape Asqav ships: a signature that binds what went in and what came out to the processing context, anchored so the signer cannot rewrite history. Asqav signs each record server-side with keys held by an operator unaffiliated with the agent's operator, which supports the recordkeeping obligations the Exchange lists.

The recognition also reaches the verification protocol. An authoritative Asqav receipt is reproducible: the server re-derives the subject it signs, and any third party can re-derive the same record and check the ML-DSA-65 signature against the public keys Asqav publishes, with no callback to Asqav. A reviewer does not have to take Asqav's word for it, which is the property a tamper-evident log needs.

Read it

The citing page: OWASP AI Exchange, input threats, secure logging.
The profile: draft-marques-asqav-compliance-receipts on the IETF Datatracker.

Out-of-process signing for high-assurance agent audit trails

João André Gomes Marques — Mon, 20 Jul 2026 12:00:00 +0000

An AI agent that signs its own audit trail holds the signing key in its own process memory. That arrangement is convenient, and it has a hole in it. An attacker who compromises the agent, through a prompt injection that reaches code execution, a poisoned tool dependency, or a memory-safety bug in a model runtime, gets arbitrary code execution inside the agent. With in-process signing, that attacker can read the signing key out of memory, mint forged receipts that look indistinguishable from genuine ones, and backdate or alter the hash chain to hide what they did.

Out-of-process signing closes that hole by moving the signer into a separate trust boundary. The agent keeps an API key and nothing else. The signing key lives in a process the agent cannot read, ideally in a customer-controlled KMS or HSM the agent operator never touches. A compromised agent can still request signatures, but it cannot extract the key, and the signer's own audit log records every request.

The threat the boundary closes

Name the adversary before the feature. An attacker with process-level access to an in-process-signing agent has three moves available.

Read the signing key out of process memory. Once the key is exfiltrated, the attacker signs anything they like, anywhere, with no further help from the agent.

Mint forged receipts that look genuine. With the key, the attacker produces signatures the verifier accepts. The audit trail now contains records of actions the agent never performed.

Backdate or alter the hash chain. Remove a receipt that incriminates the attacker, recompute the chain, and a stored-versus-stored check passes if the verifier trusts stored columns.

Out-of-process signing removes the first move, which removes the second, because without the key the attacker cannot forge. The third move is handled separately, by the rule that verification re-derives every hash from the canonical bytes instead of comparing two stored values.

What a compromised agent can still do

A precise threat model names the residual, not only the win. The agent holds an API key. An attacker holding that API key can request signatures on content they chose. That residual holds for any signer that sits outside the agent, whatever its shape: a signature proves who recorded what and when, not that the reporting process told the truth.

Asqav narrows the residual instead of hiding it. Each receipt can declare its capture path, so a verifier can tell a self-reported receipt from one captured by a network proxy or an eBPF probe at a boundary the agent does not control. Output binding through result_digest, counterparty acknowledgments, and a WebAuthn user co-signature each tie a receipt to evidence the agent cannot produce alone.

The other residual is silence. A receipt that was never requested leaves no trace by itself. Deployments that capture at a boundary record traffic the agent never reported, which gives an auditor a second record set to compare the signed receipts against.

The architecture

The signer ships as a single container image. Both deployment shapes, Asqav-hosted SaaS and customer-deployed self-hosted, use the same image and emit the same wire format.

The agent process imports the Asqav SDK and talks to the signer over a Unix domain socket or mTLS. The signer holds the ML-DSA-65 keys, validates each request, signs, and appends to the hash chain. The signer talks to Asqav SaaS over a single outbound HTTPS hop to deposit signed digests and RFC 3161 timestamps. Raw prompts, raw model outputs, and private keys never leave the customer trust boundary in the self-hosted shape.

The Python SDK reaches the signer through one environment variable. Point it at https://api.asqav.com/api/v1 and you use the Asqav-hosted notary signer. Point it at a local socket or a private signer URL and you use a customer-deployed signer. The SDK call is identical in both cases. The trust boundary changes.

Why the boundary has regulatory weight

Regulators and assessors expect the key custody question to have a clean answer.

SEC 17a-4(f) gives broker-dealers two ways to execute the required electronic-records undertakings: a designated third party unaffiliated with the broker-dealer, or an internal designated executive officer. Asqav fits the unaffiliated-third-party route, which co-located keys inside the audited workload cannot. NYDFS 23 NYCRR 500.06 calls for audit trail systems sufficient to reconstruct material financial transactions. DORA Articles 28 to 30 have financial entities evidence ICT third-party risk management. HIPAA covered entities that handle PHI in the workload have to show an assessor who controls the signing keys.

In each case the architectural question is the same. Does the signing key live inside the workload that uses it, or in a separate trust boundary? The out-of-process signer is the answer assessors expect.

Who deploys this topology

Customers in regulated industries typically deploy the customer-hosted signer. A US broker-dealer that needs SEC 17a-4(f)(3)(v) unaffiliated-third-party evidence. A covered entity under HIPAA where the agent processes PHI inside the workload. A DORA-regulated EU financial entity where Article 28 ICT third-party-risk concentration on a hosted signer is itself an audit finding. A defense contractor where the agent runs inside a CMMC enclave and the signer must run inside the same enclave.

Teams iterating on a new AI feature, or self-serve teams without a hard regulatory boundary, typically use the Asqav-hosted notary signer until they need the customer-deployed topology.

The operational detail for the self-hosted shape, including the air-gapped install with zero outbound HTTP, is on the out-of-process signing page.

Signed receipts for AI coding agents

João André Gomes Marques — Mon, 20 Jul 2026 10:00:00 +0000

AI coding agents now open their own pull requests and merge them. The git author string on a commit is mutable, so a name in a commit header proves nothing about who wrote the change or under whose authority. When an auditor asks which agent wrote which change, git history alone cannot answer.

The code-authorship receipt is our answer. It is a signed, hash-chained, anchored record that a specific code change existed, was authored by the holder of a signing key, and held a fixed position in the per-agent chain at time T. The authoritative form ships under receipt type authoritative, minted by POST /code-authorship.

The server re-derives the diff

The receipt does not trust a digest the producer hands over. Asqav re-fetches the commit from the GitHub API, re-derives the changed-files diff itself, and signs the SHA-256 it computed over the canonical form of that diff. The signed subject digest is the server value only. A client-supplied change_digest is advisory: it is compared against the server digest and the agreement is recorded as digest_match, but the client value is never signed. A producer that posts a fake digest still receives a receipt whose subject is the value the server computed from GitHub, with the mismatch flagged in the predicate.

Because the server signs a digest it re-derives from a public commit, the receipt is reproducible. Any third party who re-fetches the same commit_sha from GitHub repeats the same projection and recomputes the same digest, then checks it against the signed subject. The producer cannot move the signed subject, because the producer never controls the bytes that feed it. That is what makes the receipt unbypassable.

What the receipt proves, and what it does not

A code-authorship receipt proves a bounded set of facts and refuses to claim anything beyond them.

The change existed, and the server verified it. The subject.digest.sha256 is the SHA-256 the server re-derived from the GitHub compare response and signed. It is a digest the producer cannot forge, because the producer never supplies it.

The change was key-authored. The signature is an ML-DSA-65 signature from a key held outside the agent's environment. Whoever holds that key produced, or authorized, the change. The public key is served for offline verification at /.well-known/jwks.json.

The change held a fixed position in the chain. Each receipt links to the one before it. Reorder, delete, or insert a backdated receipt and the chain breaks at the exact spot.

The capture layer is server-derived too. The receipt stamps capture_layer: github_sha_pull, and any capture_topology a client supplies is dropped before signing, so a caller cannot spoof how the change was captured. In-process capture is observation-only across Asqav: a self-reported in-process receipt cannot drive an allow or deny decision, and the conformance gate fails closed on the attempt.

What the receipt does not prove is just as important. Asqav does not verify the code is correct or safe, and it does not verify which model produced the change. The author field is advisory, carried in the predicate for correlation and never read as Asqav-verified attribution. The receipt is a record, not a code review.

A code-authorship receipt on the wire

The receipt is an in-toto Statement v1 wrapped in a DSSE envelope. The subject names the commit and carries the server-re-derived digest. The predicate carries the producer assertions and the capture layer.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "github.com/acme/payments-service@9f3c1d8b4a6e2f0c5d7b9a1e3c4f6d8b0a2e4c6f",
      "digest": { "sha256": "c4d9f1a7e0b3..." }
    }
  ],
  "predicateType": "https://asqav.com/attestation/code-authorship/v1",
  "predicate": {
    "repo": "acme/payments-service",
    "commit_sha": "9f3c1d8b4a6e2f0c5d7b9a1e3c4f6d8b0a2e4c6f",
    "base_sha": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b",
    "capture_layer": "github_sha_pull",
    "asset_class": "code",
    "change_class": "write",
    "advisory_client_digest": "sha256:c4d9f1a7e0b3...",
    "digest_match": true,
    "author": "agt_release_bot",
    "verified_at": "2026-07-28T14:11:02.000000Z"
  }
}

The signed bytes are the DSSE Pre-Authentication Encoding of the payload type and the canonical statement, so a verifier recomputes that encoding from the decoded payload and checks the ML-DSA-65 signature offline, with no callback to any Asqav server.

Where it plugs in

The receipt rides the same supply-chain attestation tooling teams already run. It maps onto an in-toto Statement v1, with the subject array naming the produced digest and the predicate carrying the producer assertions and the chain position. Wrapped that way, it rides the same transparency-log rails as a Sigstore Rekor entry or a GitHub Artifact Attestations submission.

What it maps to in an audit

A code-authorship receipt is evidence, not a compliance guarantee. It maps to change-management and record-keeping obligations without claiming to satisfy them on its own.

SOC 2 change management asks for evidence that changes are authorized and tracked. A signed, chained, anchored receipt proves which change was authored at time T, in a form an auditor can verify offline. FINRA and SEC records rules require records that are tamper-evident and independently verifiable. EU AI Act Article 12 requires automatic recording of events over an AI system's lifetime, and a code change authored by an agent in the software development lifecycle is one such event.

In every case Asqav supplies the evidence layer. The receipt proves the change happened and held its place in the chain. Whether the change was correct, the model attribution accurate, or the approval sufficient stays the deploying organization's judgment.

Sign one

Call POST /code-authorship with repo and commit_sha. The server resolves the diff base as the merge-base of the associated pull request, or the git empty tree for a parentless initial commit. A commit that has parents but no pull request is refused with 422 (base_sha_required) rather than guessing a first parent. It then re-fetches the changed files from GitHub and signs the re-derived digest. Private repositories need a configured GitHub token, and without one a private-repo re-fetch fails closed rather than signing a fallback. The Asqav GitHub Action mints one receipt per merged PR when wired into the CI path.

Read more on the code-authorship receipts page.

How Signed Agent Receipts Map to NIST, OWASP, and NSA Frameworks

João André Gomes Marques — Mon, 06 Jul 2026 12:00:00 +0000

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_techniquesMITRE ATT&CK technique ids
                    mitre_atlasMITRE ATLAS ids for AI-system threats
                    owasp_llm_top10OWASP Top 10 for LLM ids
                    nist_ai_rmfNIST AI RMF function ids and subcategories
                    iso_42001ISO/IEC 42001 control ids
                    eu_ai_act_articlesEU AI Act article ids
                    rfc3161_timestampBase64 TimeStampResp for offline TSA verification
                    framework_mappings_self_declaredServer-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 eventaction_type, receipt_type
                    When it occurredissued_at, anchors
                    Where it occurredcapture_topology, tool_fingerprint
                    Source of the eventagent_id, authorized_under_mandate
                    Outcomecontrols_evaluated.result, result_digest
                    Identity of the subjectagent_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.

Tamper-Evident Logs for AI Agents

João André Gomes Marques — Mon, 06 Jul 2026 10:00:00 +0000

A tamper-evident log is not a log you promise not to edit. It is a record where an edit shows. That distinction is the whole game. Access controls try to stop the edit. Tamper evidence assumes the edit happens anyway and makes it visible after the fact, to someone who does not trust your storage.

We argued the case for this in an earlier post on why AI agent logs are not enough. That post covered the gap: a plain log records a claim, it does not prove one. This post is about the machinery that closes the gap. How a signed agent record is built, and what actually happens to it when someone tries to change it.

What tampering looks like

Start with the adversary, not the feature. Suppose an AI agent moved money, deleted a record, or approved something it should not have. Someone now wants the audit trail to say otherwise. They have four moves.

Edit a field. Change the amount, the destination, the timestamp, or the policy decision on a stored record.
Delete a record. Remove the row that shows the action happened at all.
Reorder records. Shuffle the sequence so a later action looks like it came earlier.
Backdate. Insert a record and claim it was written hours or days before it really was.

Each move needs its own defense. A signature catches the edit. A hash chain catches the delete and the reorder. An external anchor catches the backdate. Below is how each one works on an Asqav receipt.

Signed receipts: catching the edit

Every agent action produces a receipt. Before the action runs, Asqav serializes it, evaluates it against policy, and signs the result with a private key. The signature covers the exact bytes of the record. Change a single field later and the signature no longer matches those bytes. Anyone holding the public key sees the failure.

The signature algorithm is ML-DSA-65, Level 3 and widely recommended for most applications, defined in NIST FIPS 204, the module-lattice signature standard NIST published in 2024. It is post-quantum, which matters because agent audit trails carry long retention windows and a signature written today needs to stand up years from now. The point for tamper evidence is simpler though: the signed bytes are fixed at signing time, and no edit to them goes unnoticed.

Why the bytes have to be canonical

There is a subtlety here. The same record can be written many ways. Keys in a different order, extra whitespace, a number formatted two ways. If the signer and the verifier disagree on which bytes to hash, verification breaks on records that were never touched, and that is useless.

Asqav fixes the byte layout with a canonical form, the JSON Canonicalization Scheme from RFC 8785. Object keys are sorted, strings are preserved verbatim, and floating-point ambiguity is kept out of signed envelopes. One record, one byte sequence, one hash. The signature and every downstream hash are computed over that canonical form, so the same content always lands on the same digest.

The per-agent hash chain: catching the delete and the reorder

A signature protects one record. It does nothing about a record that was removed, because a deleted record takes its signature with it. That is what the hash chain handles.

Each agent has its own chain. Every receipt carries a previousReceiptHash field: the SHA-256 of the prior receipt's canonical bytes. The opening receipt on a chain seeds this field with 64 zeros, a genesis marker that means "no predecessor". From there, each receipt's hash becomes the next receipt's previousReceiptHash, so the records are linked in a single line.

{
  "receipt_type": "protectmcp:decision",
  "action_type": "payments:transfer",
  "agent_id": "agt_trading_bot_01",
  "issued_at": "2026-07-06T10:30:00Z",
  "previousReceiptHash": "9f2c...prior receipt canonical SHA-256...",
  "policy_decision": "permit"
}

Now the delete costs the attacker. Remove one receipt and the next one's previousReceiptHash points at a hash that nothing produces anymore. The link dangles. Reorder two receipts and the same thing happens: the chain expects one predecessor and finds another. A verifier walking the chain sees the break at the exact record where it happened.

Asqav also tells apart a real break from an expected one. When a previous_hash points to a record owned by a different agent, the verifier labels it cross_agent rather than tampering, so an operator reading a report knows which links are structure and which are damage.

The rule that makes it hold: re-derive, never trust the stored hash

Here is the mechanic that ties the rest together, and it is the one people miss. A naive integrity check compares two stored values: the hash column on this row against the hash column on the next. An attacker who can edit a field can also edit that column. Rewrite the record, recompute its hash, write the new hash into the column, and a stored-versus-stored check passes.

Asqav does not do that. Every verifier re-derives the hash from the canonical bytes of the record and compares the fresh result against what the chain expects. The stored hash column is never trusted as the source of truth. So editing a field and rewriting its hash does not help: the re-derived hash reflects the edit, and it no longer matches the value the next record committed to. The same holds for the anchor commitment, which is always recomputed from the receipt message rather than read back from a stored column. Tampering that would slip past a stored comparison surfaces here.

This is the difference between a log that claims to be immutable and a record that proves it. The proof does not depend on the database behaving. It depends on math the verifier runs itself.

External anchors: catching the backdate

Signatures and chains keep the record internally consistent. They do not, on their own, prove when a record was written. An attacker who controls the whole store could rebuild a fresh, internally consistent chain and claim it is old. That is where an outside witness comes in.

Asqav anchors each receipt to a public timeline at the moment it is issued. Two anchor types are supported: an OpenTimestamps proof committed to the Bitcoin blockchain, and an external timestamp from an RFC 3161 time-stamping authority. Both commit to the receipt's bytes, and both are re-verified against those bytes at check time, not taken on faith that a log entry exists somewhere.

A backdated record cannot produce an anchor that predates it, because the public timeline it would need to appear in had already moved on. The anchor is the part of the proof that no single party, including Asqav, can quietly rewind.

Transparency logs: a third party that remembers

Anchors prove time. A transparency log adds an independent record that a receipt existed and was seen. Asqav can export a receipt as a COSE_Sign1 structure signed by the same ML-DSA-65 key, in a form a transparency service built on the IETF SCITT work can ingest. We covered that export path in detail in the post on ML-DSA receipts in COSE for SCITT transparency services.

The value for tamper evidence is the second witness. Your own store says the receipt exists. A transparency service, run by someone else, says it saw the same receipt. To make a tampered record look real, an attacker would now have to alter both, and the second one is not theirs to touch.

What the evidence proves, and what it does not

Tamper evidence is worth having because it is honest about its own limits. A cryptographically valid receipt tells you who signed what, and that the bytes have not changed since. It does not tell you the action was safe, correct, or wise. It does not tell you nothing bypassed the signer.

Asqav makes that boundary explicit. A receipt can be paired with a signed appraisal that reports what verification actually confirmed, grouped by axis: authorship, provenance, transparency, and policy. The appraisal carries a fixed list of things it does not assert, including action safety, complete mediation, and key non-compromise. There is no single trusted or valid flag, because a valid signature is not a verdict on the decision it records. An audit stands on evidence that knows what it is, not on a green checkmark.

Putting it together

Tamper evidence for an agent record is four mechanisms doing four jobs. The signature over canonical bytes catches the edit. The per-agent hash chain catches the delete and the reorder. The external anchor catches the backdate. The transparency log adds a witness that is not you. And the rule underneath all of it is that verification re-derives every hash from the bytes instead of trusting a stored value, so the proof holds even when the storage does not.

If you want the field-level detail, the documentation walks through the receipt format, and the logs are not enough post covers why plain logging leaves that gap open to begin with. Or create a free account and sign an agent action today.

SDK 0.6.0: offline and air-gapped verification

João André Gomes Marques — Sat, 20 Jun 2026 10:00:00 +0000

SDK 0.6.0 ships today for both Python (asqav) and TypeScript (@asqav/sdk). The main addition is a clean offline verification path for environments that cannot reach the internet during an audit run.

The idea is simple: fetch the public key directory once while you are connected, then everything else is local. No special mode, no API key, no Asqav infrastructure involved during the verify step.

Offline verification in one pass

# snapshot the public key directory once
curl https://api.asqav.com/.well-known/jwks.json > jwks.json

# install the verify dependencies
pip install "asqav[verify]"

# verify with no network access
python verify_receipt.py \
    --receipt receipt.json \
    --jwks jwks.json \
    --offline

The --offline flag makes the verifier refuse to make any network call. If a key is missing from your local snapshot, the issuer-key axis fails rather than fetching silently.

ML-DSA-65 works the same way

Post-quantum receipts (ML-DSA-65, NIST FIPS 204) verify offline the same way as Ed25519 receipts. The algorithm identifier rides inside the signed envelope, so the verifier reads which algorithm to use from the receipt itself. The pure-Python dilithium-py library handles the signature math with no native compilation.

Air-gapped installs

If the target machine has no internet at all, pre-download the wheels on a connected machine and transfer them:

pip download "asqav[verify]" -d ./wheels
# transfer ./wheels/ to the air-gapped machine
pip install --no-index --find-links ./wheels "asqav[verify]"

Getting started

Full offline verification guide: asqav.com/docs/offline-air-gapped-verification. Source: github.com/jagmarques/asqav-sdk.

One Receipt, Nine Regulators

João André Gomes Marques — Sat, 09 May 2026 22:50:17 +0000

We published an IETF Internet-Draft, draft-marques-asqav-compliance-receipts-08, that profiles the upstream draft-farley-acta-signed-receipts envelope with regulatory bindings. This post explains what the profile does, why each piece is there, and how the authoritative attestation and verification protocol fits in.

What the profile does

The upstream draft specifies a generic signed receipt envelope for AI agent actions: a wire format, a canonicalization rule, a signature suite, and an optional hash chain. It is intentionally regulation-agnostic. The Asqav profile takes that envelope as-is and adds four things on top of it.

It tightens fields that the upstream draft marks OPTIONAL into REQUIRED for any receipt that claims the profile, including payload_digest, action_ref, and policy_digest.
It sets a retention floor tied to the underlying regulation: 184 days (six months) for high-risk AI Act receipts, five years for DORA receipts under the sectoral instruments (MiFID II Art 16(7), AMLD Art 40).
It mandates an anchor on every receipt. Every receipt carries an OpenTimestamps witness on all plans. Pro and Enterprise receipts also carry an RFC 3161 timestamp.
It adds two extension fields, risk_class and incident_class, drawn from controlled vocabularies that match the regulatory text.

A receipt that conforms to the Asqav profile is, by construction, a conformant upstream receipt. The signature validates with stock libraries. The chain validates with stock verifiers. A verifier that does not know about EU AI Act can still walk the receipt and confirm cryptographic facts. It just cannot attest the compliance bindings. Cryptographic validity and compliance attestation are different claims, and they fail independently.

A concrete binding

Article 12(2)(c) of the EU AI Act requires operators of high-risk systems to monitor the operation of the system and detect substantial modifications. The profile binds Article 12(2)(c) to the policy_digest field. A change in policy_digest between two otherwise-comparable Actions, same issuer_id, same action_ref family, same risk_class, is treated as a candidate substantial-modification event. The verifier surfaces those candidates. A human decides whether the change was substantial in the regulatory sense. The receipt log is the evidence trail. The binding lives in the field-level conformance rule, not in a separate PDF.

DORA Article 17 works the same way. The upstream draft says retention is out of scope. The profile sets a five-year floor for any receipt whose issuer_id is bound to a Financial Entity scope, sourced from the sectoral instruments (MiFID II Art 16(7), AMLD Art 40), and ties that floor to the OpenTimestamps anchor so deletion before the floor expires is detectable from the chain alone. If a receipt's anchor proves it existed five years ago and the producer cannot show it now, that is a finding. The supervisor does not have to take anyone's word for it.

The draft now maps the receipt format onto nine regulatory regimes across the EU and US: EU AI Act, DORA, NYDFS Part 500, NIST AI RMF, Colorado AI Act, Texas TRAIGA, CIRCIA, the HIPAA Security Rule, and SEC 17a-4. The pattern is the same in every case: pick the regulatory obligation, identify the receipt field that already carries the relevant fact, write a conformance rule that a verifier can mechanically check.

Authoritative attestation and verification

The draft registers code-authorship extensions and a verifier-behaviour protocol, and Asqav ships both. The authoritative attestation path, POST /code-authorship, re-fetches a commit from GitHub, re-derives the changed-files diff server-side, and signs the digest it computed. The signed subject is the server value, never a client-supplied one, so the producer cannot forge or backdate the record. The receipt carries the receipt type authoritative and the server-derived capture layer github_sha_pull.

The verification protocol is issuer-free. A third party resolves the signing key at /.well-known/jwks.json, recomputes the DSSE Pre-Authentication Encoding over the in-toto statement, and checks the ML-DSA-65 signature with no callback to Asqav. The same verifier walks the per-agent hash chain and checks the anchor. Because the authoritative digest is re-derived from a public commit, any third party that re-fetches the commit_sha reproduces it and confirms the subject independently.

Read the draft on the IETF Datatracker.

An IETF profile for AI agent compliance receipts

João André Gomes Marques — Mon, 04 May 2026 11:58:11 +0000

What the profile does

It tightens fields that the upstream draft marks OPTIONAL into REQUIRED for any receipt that claims the profile, including payload_digest, action_ref, and policy_digest.
It sets a retention floor tied to the underlying regulation: 184 days (six months) for high-risk AI Act receipts, five years for DORA receipts under the sectoral instruments (MiFID II Art 16(7), AMLD Art 40).
It mandates an anchor on every receipt. Every receipt carries an OpenTimestamps witness on all plans. Pro and Enterprise receipts also carry an RFC 3161 timestamp.
It adds two extension fields, risk_class and incident_class, drawn from controlled vocabularies that match the regulatory text.

A concrete binding

Authoritative attestation and verification

Read the draft on the IETF Datatracker.

Verify is not just true or false, granular outcomes on /verify

João André Gomes Marques — Sun, 03 May 2026 18:16:42 +0000

Until last week the public verify endpoint at GET /api/v1/verify/{signature_id} returned a single boolean: {verified: true} or {verified: false}. That works for the buyer's first-glance UX. It does not work for a regulator or a court trying to figure out what actually went wrong.

An older trust-data-infrastructure design we read for context lays this out: their verify can return Valid Document, Invalid Signature, Incorrect Hash, Invalid Receiver Public Key, or Valid Document (Adulteration Not Detected). Each label is a different forensic story. Invalid Receiver Public Key means substitution or man-in-the-middle. Incorrect Hash means transit corruption. Invalid Signature means key compromise.

A boolean cannot carry that.

What we added

{
  "verified": true,
  "verification_detail": {
    "signer_key_match": true,
    "signature_valid": true,
    "algorithm_match": true,
    "agent_active": true,
    "validation_label": "valid"
  }

---

Asqav provides cryptographic governance for AI agents through signed, tamper-evident receipts covering actions, policy decisions, result digests, and independent timestamps. Receipts support recordkeeping and independent verification; they do not by themselves establish legal compliance, which depends on the system and jurisdiction. Founded by João Marques.
}

Four sub-checks plus a stable label. The label resolves to one of: valid, invalid_signature, signer_key_changed, algorithm_mismatch, agent_inactive, agent_unknown.

The field is optional. Older clients that do not know about it ignore it. New clients render the per-axis breakdown. Backwards-compatible by construction.

The public verify HTML at asqav.com/verify/<signature_id> got a small grid below the existing fields, conditional on the API returning the detail.

What this is for

A regulator asks: when did this signature go bad? Was it the day the key was rotated? You want a label, not a bool.

A court admissibility question: was this record signed by the agent the policy claims signed it, or by something with a different public key? You want signer_key_match as its own line.

Every rejection leaves a trail, persistent log of rejected attempts

João André Gomes Marques — Sun, 03 May 2026 18:11:20 +0000

A rejection is data. Until recently we were throwing it away.

If an attacker submitted a forged signature against the public verify endpoint, we returned 404 signature_not_found and that was the entire footprint. Same for a cross-org access attempt on the replay endpoint, an agent that got suspended mid-run trying to sign once more, or a probe walking through random sig_* ids.

An older trust-data-infrastructure project we read during a cold audit is explicit about this: log every invocation including the invalid ones, "para auditoria futura". It is the right call. We borrowed it.

What landed

One new table, rejected_attempts. Indexed on (organization_id, created_at) and (agent_id, created_at) for fast org-scoped time-window scans.

A logging helper that captures IP, User-Agent, and X-Request-ID, truncates user-supplied bytes, commits its own row, and swallows persistence failures so logging canno

Wired at the verify endpoint (signature and approval not-found branches), the signature lookup and replay endpoints (not-found and cross-org branches), and the sign and countersign paths.

How operators query it

GET /api/v1/observability/rejected-attempts, scoped to your organization, available on every plan including Free. Filters: failure_reason, agent_id, time window, pagination.

What to do with the data

Probe alerting. N rejections from one IP in M minutes is a probe.
Suspended-agent retries. A revoked or decommissioned agent that keeps trying is misconfigured or compromised.
Cross-org access attempts. A bearer token from one org hitting a signature_id from another org is the kind of thing you find out about months later. Now you find out the same hour.

Per-agent hash chain, with a verifier that re-derives

João André Gomes Marques — Sun, 03 May 2026 18:05:22 +0000

We hash-chain every signature record so a tamper or a delete is detectable on a later integrity check. The chain has been live for months. It worked. It also had two real problems we did not surface until we did a cold audit against an older trust-data-infrastructure (TDI) project.

Problem 1: the chain was global

Every new signature record took its previous-hash from the most recent record across the entire database. Not the most recent record for the same agent. Not the most recent record for the same organization. The most recent record, period.

That makes a single global chain across every tenant. If tenant A's record is mutated or removed, the chain breaks at the next record from any tenant. A long-running customer with an active integration could have their chain show as broken because a different customer in a different country had a row deleted by a cleanup job.

It also has a write hot spot. Two parallel signs across any two tenants both read the same chain head, both compute the same previous-hash, both insert. The integrity check then flags the second insert as broken even though no one tampered with anything.

Problem 2: the verifier never re-derived

The verifier walked records in order and checked that each row's previous-hash matched the prior row's stored hash. That catches a deleted row. It does not catch a row mutation that also rewrites its own stored hash.

The fix is to re-derive the record hash from the canonical fields and compare. If the recomputed hash differs from the stored one, that row was mutated.

What changed

Chain heads are scoped per agent.
The verifier re-derives every record hash instead of trusting the stored value.
Records that predate the change keep their old cross-agent links; the verifier reports those under a separate legacy reason instead of calling them tampering.

If you run a similar chain anywhere (audit log, ledger, payments), the two checks above are worth a 30-minute look. Global ordering and stored-hash comparison both feel safe and both have failure modes that quietly do not surface until someone audits them.