DEV Community: João André Gomes Marques

One Receipt, Nine Regulators

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

The IETF Internet-Draft for AI agent Compliance Receipts grew up. What started as a binding to EU AI Act Article 12 is now a bindings table across nine regulatory regimes: EU AI Act, DORA, NYDFS Part 500, Colorado AI Act, Texas TRAIGA, NIST AI RMF, CIRCIA, HIPAA Security Rule, and SEC 17 CFR 240.17a-4.

The same wire envelope satisfies all of them. The same conformance vectors prove it. The same Audit Pack export carries the regime mapping a regulator needs without the Deployer writing a per-regime adapter.

Three things that follow

One vocabulary, nine retention floors. A receipt that touches a HIPAA-covered Action retains for the floor HIPAA mandates. A DORA-bound Action retains for the DORA floor. The Audit Pack carries the regime tag inline so the cleanup engine does not need to guess.

Cross-jurisdiction queries. A Deployer subject to EU AI Act Article 26 AND NYDFS Part 500 can answer one query - "show me every Article 26-relevant Action that crossed a NYDFS boundary" - against one receipt store, not two.

Forward-compatible. Adding the next regime is a binding-table edit, not an envelope rewrite. The wire format is stable; the regime mapping is data.

What it looks like

A Compliance Receipt is the same JSON envelope across jurisdictions. The regime tag travels in the Audit Pack metadata; the receipt body stays canonical:

{
  "type": "protectmcp:decision",
  "issuer_id": "lei:529900T8BM49AURSDO55",
  "action_ref": "sha256:9f2e...",
  "previous_receipt_hash": "sha256:6c41...",
  "policy_digest": "sha256:b71a...",
  "decision": "permit",
  "risk_class": "high",
  "incident_class": "minor",
  "signed_at": "2026-05-10T09:14:22Z"
}

The reference implementation runs at api.asqav.com. The conformance harness walks the normative clauses against the live cloud and reports per-clause coverage. Verifying any receipt is a single unauthenticated GET.

Try it

pip install asqav
asqav demo          # produces a Compliance Receipt against the live cloud
curl https://api.asqav.com/api/v1/verify/<signature_id>

If you build agent governance, the path from "logs everywhere" to "one verifiable receipt" goes through this draft.

Draft: https://datatracker.ietf.org/doc/draft-marques-asqav-compliance-receipts/

An IETF profile for AI agent compliance receipts

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

We published an IETF Internet-Draft, draft-marques-asqav-compliance-receipts, that profiles the upstream draft-farley-acta-signed-receipts envelope for EU AI Act and DORA bindings. This post explains what the profile does and why each piece is there.

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: six months for high-risk AI Act receipts, five years for DORA receipts.
It mandates dual-anchoring. Every receipt carries an RFC 3161 timestamp and an OpenTimestamps witness.
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, 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 current draft has eleven such bindings, six against the AI Act and five against DORA. 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.

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"
  }
}

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.

PR with the diff: github.com/jagmarques/asqav#141

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 last week 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.

One helper, log_rejected_attempt(db, request, endpoint, failure_reason, ...). Captures IP, User-Agent, X-Request-ID. Truncates user-supplied bytes. Commits its own row. Swallows persistence failures so logging cannot become a 5xx.

Wired today at four sites: GET /verify/{record_id} (signature and approval not-found branches), GET /signatures/{id} and POST /signatures/{id}/replay (not-found and cross-org branches). Sign and countersign sites in routes/agents.py come next.

How operators query it

GET /api/v1/observability/rejected-attempts, Pro+ tier, scoped to your organization. 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.

PR with the diff, the migration, and tests: github.com/jagmarques/asqav#140

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 SignatureRecord 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 MAX(id), 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 record_hash. That catches a deleted row. It does not catch a row mutation that also rewrites its own record_hash.

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

What we shipped

Scope chain heads per-agent.
Re-derive record_hash in the verifier.
Tag legacy cross-agent links as legacy_global rather than treat them as broken.

No backfill in this PR. Old records keep their global-chain values; new records use per-agent from this commit forward.

PR with the diff and tests: github.com/jagmarques/asqav#138

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.

Govern AI agents from your CLI

João André Gomes Marques — Sat, 02 May 2026 13:40:18 +0000

The Asqav CLI used to be a thin wrapper around the Python SDK. As of this release, the CLI is the primary integration surface, with feature parity between the Python and TypeScript distributions and a stable command set you can wire into Makefiles, GitHub Actions, and pre-commit hooks.

Install via pip or npm, both ship the same subcommands:

pip install asqav[cli]
# or
npm install -g @asqav/cli

What you can do without leaving the terminal

The CLI exposes the operations a reviewer or a DevOps engineer needs day-to-day:

asqav preflight runs an action through the policy engine in dry-run mode, prints the decision and the triggering rule, and exits non-zero if blocked. Useful in CI before merging an agent change.
asqav replay reconstructs the receipt timeline for a workflow and verifies every signature against the public key. Works offline against an exported bundle.
asqav budget shows the current per-agent spend, the rate-limit window, and the next reset. Pipes into Slack alerts cleanly.
asqav approve resolves a pending approval card from the terminal. Reason text required, captured into the signed receipt.
asqav compliance export bundles receipts, policy versions, and incident records into a portable archive ready for auditor handoff.

Tier-gated commands, multi-party signing flows, retention policies, and SCITT submission are namespaced under asqav enterprise and surface a clear license-required error on Free.

A short demo session

$ asqav login
Paste API key: sk_***

$ asqav preflight --agent fintech-bot \
    --action wire_transfer --amount 850000 --currency EUR
DECISION: APPROVAL_REQUIRED
RULE:     wire.amount > 500000
NEXT:     asqav approve act_01HZX...

$ asqav approve act_01HZX9 \
    --reason "Verified counterparty + invoice 2026-INV-1812"
RECEIPT:  rcpt_01HZXA2K... (ML-DSA-65)
STATUS:   verified

$ asqav replay trace_q4_payroll
12 actions, 12 signatures verified
0 incidents, 0 budget violations

$ asqav compliance export --since 2026-04-01 \
    --out evidence-2026-04.zip
wrote 1247 receipts, 14 policy versions, 3 incidents

Each command writes to stdout in a parseable shape (--json for machine output) and exits non-zero on policy violation. The CLI is the contract you need for Makefile-driven environments and for build agents that should fail closed when an action is blocked.

Same commands, two languages

The Python and TypeScript CLIs read the same config file (~/.asqav/config.toml), use the same auth scheme, and produce identical output. Pick whichever fits your stack. A Vercel deployment running the TypeScript CLI in a GitHub Action talks to the same backend as a Python service running the Python CLI in a cron job, against the same signed receipts.

Wiring it in

The CLI is meant to be boring infrastructure. Three patterns we use ourselves:

Pre-commit hook: asqav preflight against the staged agent change, blocks the commit if the policy rejects it.
GitHub Action job: asqav compliance export on a weekly schedule, uploads the zip as a release artifact.
On-call paging: asqav replay on the failing trace ID, attached to the incident channel inside two minutes.

Source and docs:

Python CLI: pypi.org/project/asqav
TypeScript CLI: npmjs.com/package/@asqav/cli
Command reference: docs/cli

Open a terminal, run asqav preflight against your next agent change, and the dashboard becomes the optional surface, not the required one.

ML-DSA receipts in COSE for SCITT transparency services

João André Gomes Marques — Sat, 02 May 2026 13:35:11 +0000

SCITT, the Supply Chain Integrity, Transparency, and Trust working group at IETF, is the standards track for append-only logs that hold cryptographic statements about software, models, and now AI agent actions. Transparency services consume signed statements, append them to a Merkle log, and hand back inclusion proofs. The receipts have to be in a format the service understands. That format is COSE.

Asqav now exports any signed receipt as a COSE_Sign1 envelope on demand, so you can submit Asqav-signed agent actions to a SCITT transparency service.

Why SCITT

An organisation that wants third-party-verifiable evidence of agent behaviour does not want to run its own append-only log. SCITT separates the signer from the log operator. The signer says "I claim this happened". The transparency service says "I have witnessed and ordered this claim". A consumer checks both signatures and gets non-repudiable, ordered evidence without trusting either party alone.

For AI Act Article 12 records, DORA operational logs, and SOC 2 system descriptions, this two-party setup is what auditors expect for the next decade. Self-hosted log files do not pass that bar.

What COSE_Sign1 looks like

COSE, RFC 9052, is the CBOR analogue of JOSE. A COSE_Sign1 message is a four-element CBOR array:

protected header, a serialised CBOR map with the algorithm and any required parameters
unprotected header, a CBOR map for hints like the key ID
payload, the bytes being signed (canonicalised receipt JSON)
signature, the raw ML-DSA-65 signature over the Sig_structure

The whole envelope is wrapped with CBOR tag 18, which is how COSE labels a single-signer message. ML-DSA is registered with COSE algorithm identifiers in the IANA COSE Algorithms registry under the post-quantum group. Asqav uses ML-DSA-65, which corresponds to FIPS 204 parameter set 3.

The export endpoint

The on-demand export does not change the original receipt. It re-serialises the canonical JSON payload into a COSE_Sign1 envelope and re-signs with the same ML-DSA-65 key. The original JSON receipt and the COSE form are both first-class records, both verifiable independently.

curl -H "Authorization: Bearer $ASQAV_KEY" \
  -H "Accept: application/cose" \
  https://api.asqav.com/v1/receipts/{receipt_id}/cose \
  -o receipt.cose

The response is the raw COSE_Sign1 bytes. Submit that to your SCITT transparency service of choice and you get an inclusion receipt back.

Verifying it locally

You do not need a SCITT service to inspect what came back. The CBOR is parseable with any COSE library. Here is a check using cbor2 in Python:

import cbor2

with open("receipt.cose", "rb") as f:
    msg = cbor2.load(f)

# tagged value, tag 18 = COSE_Sign1
assert msg.tag == 18
protected, unprotected, payload, signature = msg.value

protected_map = cbor2.loads(protected)
print("alg label:", protected_map.get(1))   # 1 = alg
print("payload bytes:", len(payload))
print("signature bytes:", len(signature))   # ML-DSA-65 sig is 3309 bytes

The payload is the same RFC 8785 canonical JSON object you get from the regular receipt endpoint, so a verifier can re-extract it and compare against the JSON form for free. The signature is over the standard COSE Sig_structure, which means any compliant COSE verifier with an ML-DSA-65 implementation will accept it.

One key, two formats

The ML-DSA-65 key that signs your normal receipts is the same key that signs the COSE form. Auditors only have to learn one public key, and they can pick whichever envelope format their tooling supports. The two are bit-equivalent in payload, only the framing differs.

Where to start

SCITT working group: datatracker.ietf.org/wg/scitt
RFC 9052, COSE: rfc9052
FIPS 204, ML-DSA: csrc.nist.gov/pubs/fips/204
Asqav docs, COSE export endpoint: docs/cose-export

Run a SCITT transparency service in front of your Asqav signer and you have a two-party audit trail that any third party can verify, without contacting either of you.

Audit-trail receipts you can verify offline

João André Gomes Marques — Sat, 02 May 2026 11:07:15 +0000

Buyers ask for an audit trail. You hand them a CSV of timestamps. They ask if the timestamps are tamper-evident. You hand them a SOC 2 report. None of that lets them verify a single agent action without your help.

Asqav now ships a public per-agent profile so anyone with the agent ID can pull the receipt history and check the signatures themselves. No login, no API key, no call back to your stack.

What is in the profile

Every agent registered against an Asqav org gets a stable URL of the form asqav.com/a/. The profile renders three things:

The agent's identity claim, which is the agent name, owner org, and the public key fingerprint used for ML-DSA-65 signatures.
A trust-level badge, L0 to L3, computed from policy coverage, receipt continuity, and incident history.
A reverse-chronological list of recent signed receipts with action type, timestamp, and the verification status.

Each receipt links to the canonical JSON, the COSE_Sign1 form, and a one-click "verify in browser" path that pulls the public key, runs ML-DSA verification in WASM, and shows pass or fail.

The embed badge

The point of a public profile is that other people can point to it. Asqav ships an SVG badge and an iframe so you can drop trust evidence into a README, a docs page, or a procurement portal.

The SVG badge is a static image served from the API. It always reflects the current trust level, which means a regression in policy coverage updates the badge automatically the next time it is fetched.

[

](https://asqav.com/a/agent_abc123)

The iframe is the embed version of the full profile. It renders the latest receipts, the trust level, and the verify-in-browser link. Drop it in your repo or in a vendor security page and reviewers do not need to leave that page to check the signatures.

The embed sends a CSP frame-ancestors response that lets it render in any host. There is no JavaScript reaching out to your stack. The verifier path uses the public ML-DSA key and the canonical receipt format, so a reviewer can save the page and re-verify offline.

Why offline matters

An auditor or a procurement reviewer is rarely on the same network as the producer of the receipts. The whole point of a signed audit trail is that you can hand over the receipts and the public key and walk away. The profile, the badge, and the iframe are all wrappers around that property. There is no privileged endpoint, no rate-limited verification API, and no shared secret. The signatures are checked against a public key.

That is what makes this useful for EU AI Act Article 12 evidence packs, DORA operational resilience reviews, and SOC 2 system descriptions. The reviewer leaves the meeting able to spot-check any line in the trail.

Try it

Public profile: asqav.com/a/demo
Badge for the demo agent: badge.svg
Embed it in your README using the iframe markup above.

The cryptography is the same ML-DSA-65 used everywhere else in Asqav. The new piece is making the verification surface public, so a buyer can check the chain without needing your help.

Asqav TypeScript SDK is live

João André Gomes Marques — Mon, 27 Apr 2026 18:51:51 +0000

If your AI agents run on TypeScript, you have probably noticed every governance and observability tool in the space treats Python as the default and JavaScript as an afterthought. We did the same thing for a while. Today we ship the fix.

npm install @asqav/sdk

Same REST API as the Python SDK, same ML-DSA-65 signatures generated server-side, same audit trail. The npm package is a thin client that hits api.asqav.com - all crypto stays on our infrastructure. Public surface mirrors Python one-for-one so you can write the same code in either language and get the same behaviour.

Thirty-second example

import { init, Agent } from "@asqav/sdk";

init({ apiKey: process.env.ASQAV_API_KEY });

const agent = await Agent.create({ name: "support-bot" });
await agent.startSession();

const sig = await agent.sign({
  actionType: "stripe.refund",
  context: { amount: 1500, reason: "customer dispute" }
});

console.log(sig.verificationUrl);
// https://asqav.com/verify/sig_abc123
await agent.endSession({ status: "completed" });

That signature is real ML-DSA-65 (FIPS 204), anchored to Bitcoin via OpenTimestamps, retrievable from any compliance auditor without needing your infrastructure online. Same guarantees as the Python flow.

What this unlocks

The interesting frameworks for agents in TypeScript right now are Vercel AI SDK, LangChain.js, and Mastra. Each one gives you a tool-calling loop where the model picks an action, you execute it, and the result feeds back. None of them give you a tamper-evident record of what the agent actually did.

With the npm SDK, wrapping a Vercel AI SDK tool to sign every call is six lines:

import { tool } from "ai";
import { Agent } from "@asqav/sdk";

const agent = await Agent.create({ name: "support-bot" });

const refund = tool({
  description: "Issue a refund",
  parameters: z.object({ amount: z.number(), customer: z.string() }),
  execute: async (args) => {
    await agent.sign({ actionType: "stripe.refund", context: args });
    return await stripe.refunds.create(args);
  }
});

Every refund the model decides to issue now has a signature on the way out. Replace the wrapper at the framework level and every tool gets governance for free.

Why we waited

Honest answer: shipping a second SDK doubles the surface to maintain. We held off until the Python SDK API stabilised so the TypeScript port could mirror it cleanly instead of forking immediately. The two are now version-locked at the API level - what works in one works in the other. Releases are independent (py-v0.2.22, ts-v0.1.0) so we can patch one without touching the other.

Install matrix

Both languages, same brand, same backend:

# Python
pip install asqav

# TypeScript / Node / Deno / Bun
npm install @asqav/sdk

Source: github.com/jagmarques/asqav-sdk (monorepo with python/ and typescript/ side by side, MIT). Docs and dashboard: asqav.com/docs. Get an API key at asqav.com and sign your first action in under a minute.

If you are wiring this into Vercel AI SDK or LangChain.js right now and hit a rough edge, open an issue on the SDK repo and we will turn it around fast. The TypeScript surface is fresh and we want to harden it against real usage before more frameworks land on top.

Try asqav in 30 seconds

João André Gomes Marques — Mon, 20 Apr 2026 12:38:26 +0000

Most agent governance tools want you through a signup flow before you see a single screen. We shipped asqav demo so you can see the product without an account.

pip install asqav[cli]
asqav demo

That opens a local dashboard at http://localhost:3030 with four pre-loaded scenarios. No API key, no Docker, no cloud call. The HTTP server runs entirely inside the SDK.

What you see

Four risky agent actions, each with the full context a reviewer would need to decide:

Claude Code wants to rm -rf ~/projects. High risk, destructive filesystem rule fires.
Fintech agent wants to send an 850 000 EUR wire. Amount over threshold triggers HITL.
DevOps agent wants to scale production to zero. Namespace + replicas rule blocks it.
Clinical agent wants to order CT with contrast, allergy not checked. Medium risk, reviewer sees the gap.

Each card renders six fields: action payload, agent reasoning chain, risk classification with reason, triggering policy name and rule, a required reason textarea (minimum ten characters), and an expected diff preview. Approve or Deny produces an HMAC-signed receipt. The dashboard re-verifies each receipt in the browser and shows whether the signature is valid.

Why we built it

Agent governance sits at the top of a long conversation before engineers start wiring SDKs into their code. A demo that runs without a network, without an account, and without a container gives the technical buyer a working artifact to share in thirty seconds. The rest of the integration - real policies, cloud signatures, dashboard - follows once the team agrees this is the shape they want.

What this is not

The receipts in the demo use HMAC over canonical JSON. Production asqav uses ML-DSA-65 (FIPS 204) signatures and RFC 8785 JCS canonicalization. Swap asqav demo for asqav.init(api_key="sk_...") and you get the real cryptography, the multi-party signing, the incidents and compliance reports. The demo is a preview of the UX and the audit flow, not a stand-in for the production trust chain.

Source and docs

asqav demo lives in the SDK, Apache 2.0: github.com/jagmarques/asqav-sdk
Approval card UX in the real dashboard: docs/approvals
Attestation format (third-party verifiable, RFC 8785): docs/attestation

Governance metadata in A2A Agent Cards, shipping the superset

João André Gomes Marques — Sun, 19 Apr 2026 19:56:38 +0000

A2A Agent Cards describe what an agent can do, where it lives, and how to talk to it. What they do not describe is governance posture. Two agents can hold identical cards and behave nothing alike in production.

We shipped a reference implementation under extensions.asqav.governance inside the standard AgentCard envelope. Three fields carry the posture: trust_score, retention_ttl_seconds, and derivation_rights. Signed with the agent's own ML-DSA-65 keypair. Docs at asqav.com/docs/a2a.

The schema

{
  "name": "research-agent",
  "url": "https://agents.example.com/research",
  "extensions": {
    "asqav.governance": {
      "version": 2,
      "agent_id": "agt_x7y8z9",
      "trust_score": 0.82,
      "retention_ttl_seconds": 2592000,
      "derivation_rights": {
        "retention_permitted": true,
        "derivative_works": false,
        "third_party_sharing": false,
        "license_reference": "https://example.com/licenses/research-v1"
      },
      "issued_at": "2026-04-19T12:00:00+00:00",
      "expires_at": "2026-04-26T12:00:00+00:00",
      "signature": "...",
      "public_key": "..."
    }
  }
}

Why trust_score decays

A discrete L0 to L3 grade hides real signal. An agent that ran clean 90 days ago then went silent is epistemically different from one that just handled a thousand signed actions. A decaying score separates them. 45-day half-life on positive evidence: each successful signed action contributes weight 0.5 ^ ((now - t) / 45 days). Negative events (suspensions, revocations) apply full-weight penalties that do not decay. Derivation reads signed records only, so independent verifiers get the same number.

Why derivation_rights needs license_reference

derivative_works: false alone means nothing across organizations. One side reads it as "do not train on my outputs," another as "do not fine tune downstream," another as "do not incorporate into product." The boolean is a coarse intent signal. license_reference pins down the actual contract, whether that is a CC license, a bespoke DUA, or a proprietary TOS. Machine-readable gating and human-readable legal terms in the same envelope.

Key rotation

Each agent signs its own extension with its own ML-DSA-65 keypair. The public key is embedded in the signed envelope at issuance time, not fetched by reference. When a key rotates, old attestations stay verifiable forever because the bytes needed to check the signature are already inside the envelope. A third party that captured an attestation in February does not have to call back to asqav in October to confirm it.

curl https://api.asqav.com/api/v1/public/attestation/agt_x7y8z9

Platform discovery is standard A2A: GET /.well-known/agent.json. Per-agent cards at GET /api/v1/agents/{id}/card. Parse like any A2A card, look inside extensions if you care about posture.

Portable Trust for AI Agents

João André Gomes Marques — Sun, 19 Apr 2026 15:43:38 +0000

When two autonomous agents from different organizations talk to each other, they have to decide whether to trust each other's actions. Today that decision is mostly opaque. One side has its own scoring, the other side has its own thresholds, and reconciliation across providers comes down to whose guardrails you ran through last.

A recent A2A protocol discussion surfaced the underlying gap. If every layer introduces its own score, grade, or tier, two independent systems cannot deterministically arrive at the same decision, even when every individual signal was valid and signed. What is missing is a notion of decision identity, something that lets different representations be verified as equivalent outcomes rather than as locally consistent ones.

Governance Attestation is our answer. It is a single signed JSON per agent that any party can fetch, verify offline with ML-DSA-65, and act on without calling our API. One canonical document, one deterministic trust level, one mapping published in our docs.

What is in an attestation

{
  "version": 1,
  "agent_id": "agt_x7y8z9",
  "issuer": "asqav",
  "trust_level": "L2",
  "capability_manifest_hash": "sha256:3f2a...",
  "policy_digest": "sha256:91c4...",
  "compliance_attestations": ["eu_ai_act_art12", "soc2_audit"],
  "issued_at": "2026-04-19T12:00:00+00:00",
  "expires_at": "2026-04-26T12:00:00+00:00"
}

The body is canonical JSON, signed with the agent's post-quantum ML-DSA-65 key. Signature, public key, and verify URL come back alongside the body. Two independent verifiers recomputing the canonical bytes of the body get the same digest, run the same signature check, and reach the same decision. That is what deterministic trust looks like at the protocol layer.

The trust levels

Four canonical levels, derived deterministically from the agent's state. No subjective scoring.

L0 Unknown - default. No signed activity in the last 30 days.
L1 Monitored - at least one signed action in the last 30 days.
L2 Governed - L1, and the owning organization has at least one enabled policy.
L3 Autonomous - L2, and no revocation or suspension in the last 90 days.

Because the rules are public, an auditor can reconstruct the level from the raw signed records. If they disagree with the outcome, the argument is about the rules, not about whose internal scoring they trust.

The public verify path

curl https://api.asqav.com/api/v1/public/attestation/agt_x7y8z9

No auth. No API key. Any third party fetches the signed envelope. The signature verifies offline against the returned public key using ML-DSA-65. The canonical body tells them the trust level, capability hash, policy digest, and the exact window the attestation is valid for.

A2A Agent Card integration

For agents exchanging Agent Cards through A2A, drop the attestation URL and hash into your card. Recipients verify the governance posture before accepting a request.

{
  "name": "research-agent",
  "governance": {
    "provider": "asqav",
    "attestation_url": "https://asqav.com/attestation/agt_x7y8z9",
    "attestation_hash": "sha256:..."
  }
}

Issuing an attestation

POST /api/v1/agents/{agent_id}/attestation
X-API-Key: sk_live_...

A fresh attestation expires after seven days, at which point you issue a new one. That window is short on purpose. Trust is a function of recent behavior, not a static label attached once.

Why this exists on Enterprise

Governance Attestation is a cross-organization trust primitive. It only pays off when you are operating agents that talk to other organizations' agents, usually under contract, usually with legal and compliance sitting on the other side of the table. That is the shape of Enterprise deployments.

For single-organization setups, audit trails, policy enforcement, and the public verify endpoint still cover everything.

Full docs: asqav.com/docs/attestation