Attestation

A Governance Attestation is a portable JSON evidence pack that states an agent's current trust posture. Every attestation is hash-chained to the underlying event log and anchored externally with an OpenTimestamps Bitcoin commitment. Enterprise attestations also carry an RFC 3161 timestamp.

Third parties fetch without authentication, verify offline, and read the canonical trust level from the body. Two independent verifiers reach the same decision because the derivation rules are public, the body is deterministic, and the external anchor is independently re-checkable.

Why external anchoring matters

Internal hash-chained audit logs are tamper-evident only against outsiders. An insider with log-server access can still rewrite the chain end-to-end. Microsoft's own EU AI Act checklist flags this gap verbatim: “No external commitment (e.g., Merkle root anchoring to a timestamping service) prevents full chain rewrite.” (source).

Asqav closes that gap. Every attestation carries an OpenTimestamps Bitcoin anchor, a free and independent time proof. On Enterprise, when the external witness is reachable, the attestation's external anchor is a qualified timestamp token from an EU Trusted List QTSP, which under eIDAS Regulation 910/2014 Art 41(2) enjoys “the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and the time are bound.” Art 41(3) extends that presumption across EU member states. Asqav signs the attestation server-side as a party unaffiliated with the agent's operator, so the recorded party cannot backdate or alter its own evidence.

Regulatory mapping

EU AI Act Regulation 2024/1689 Art 12(1) requires high-risk AI systems to “technically allow for the automatic recording of events (logs) over the lifetime of the system.” Art 26 places operational logging duties on deployers. The regulation calls for log integrity, and an external timestamp paired with a hash-chain commitment provides verifiable evidence of it.

DORA RTS 2024/1774 Art 24 requires financial entities to protect log information “against tampering, deletion, and unauthorised access.” The requirement is technology-neutral. An external timestamp paired with a hash-chain commitment is one implementation that supports it, and Asqav ships it out of the box. On Enterprise, when the external witness is reachable, that timestamp is a qualified token carrying the eIDAS Art 41 presumption.

Attestation fields map to these regulatory needs. The compliance_attestations list surfaces the specific article ids (for example eu_ai_act_art12, eu_ai_act_art26_deployer, dora_rts_2024_1774_art24) the attestation was generated for.

Why

When agents from different organizations communicate, each side has its own scoring and thresholds. Reconciliation is opaque. Attestation replaces that with one anchored document: canonical trust level, capability hash, policy digest, compliance list, issued-at / expires-at, and an external timestamp proof. Fetch once, verify offline, act on it.

Trust levels

Level	Meaning
`L0`	Unknown
`L1`	Monitored
`L2`	Governed
`L3`	Autonomous

The trust_level is a controlled-vocabulary value carried in the signed attestation body. A verifier reads it from the envelope. It does not recompute it.

Attestation body

json

{
  "version": 3,
  "agent_id": "agt_x7y8z9",
  "issuer": "asqav",
  "trust_level": "L2",
  "trust_score": 0.6234,
  "capability_manifest_hash": "sha256:3f2a...",
  "policy_digest": "sha256:91c4...",
  "policy_decision": "permit",
  "authorization_ref": null,
  "compliance_attestations": ["eu_ai_act_art12", "soc2_audit"],
  "retention_ttl_seconds": 31536000,
  "derivation_rights": {
    "retention_permitted": true,
    "derivative_works": false,
    "third_party_sharing": false,
    "license_reference": null
  },
  "issued_at": "2026-04-19T12:00:00+00:00",
  "expires_at": "2026-04-26T12:00:00+00:00"
}

The body is serialized as RFC 8785 (the JSON format spec) bytes. Two verifiers recompute byte-identical output in any language, so the signature check succeeds deterministically. Pre-v3 attestations used sort-keys sorted JSON. The dual-path verifier in the SDK accepts both so old signatures stay valid.

Schema v3 additions

Version 3 adds two fields so the signed receipt chains to the upstream authorization decision, not just the agent execution. Additive change only. A v3 envelope is a superset of v2.

policy_decision

Core profile: "permit" or "deny". Present in every v3 body. An attested agent is always permit because denied actions do not reach the signing path. The field exists so third-party verifiers can fail-closed when it is absent or malformed.

authorization_ref

Optional pointer to the upstream policy violation or approvals-queue approval that authorized the underlying action. Shape is null by default and a URL or opaque id when populated. Chain-of-custody: principal -> delegation -> policy decision -> executed action, all four signed.

Key rotation

Each attestation is signed with the agent's own ML-DSA-65 keypair, not a platform-wide signing key. This means rotation is per-agent and does not invalidate historical attestations.

When an agent rotates its key:

A new agent version is created with the new public key. Prior versions remain referenceable.
New attestations embed the new public key in the envelope.
Prior attestations remain independently verifiable against the public key that was embedded at issuance time.

A verifier does not need to query Asqav to re-verify old attestations. The signed envelope is self-contained: body, signature, public key, issued_at, expires_at all travel together.

Schema v2 extensions

Schema version 2 adds three fields that align Asqav with the A2A Agent Card governance proposal and the derivation-rights work emerging on that thread.

trust_score

Normalized 0.0 to 1.0, carried in the signed attestation body. A verifier reads the value from the envelope.

json

"trust_score": 0.6234

retention_ttl_seconds

How long a receiving agent may retain this attestation. Derived from the issuing org's tier retention (Free 30d, Enterprise custom).

json

"retention_ttl_seconds": 31536000

derivation_rights

Explicit scope for what a receiver may do with the attestation and any data derived from interacting with this agent. Three booleans:

retention_permitted: may store the attestation past the current session.
derivative_works: may use the attestation to vouch for derived data.
third_party_sharing: may share the attestation with parties outside the original transaction.
license_reference: optional URL pointing to the license text that defines what derivative_works means in this context. Resolves the ambiguity where two agents interpret "derivative" differently.

json

"derivation_rights": {
    "retention_permitted": true,
    "derivative_works": false,
    "third_party_sharing": false,
    "license_reference": null
}

Issuing an attestation

Requires an API key with the agents:write scope (or the * wildcard).

http

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

Response:

json

{
  "body": { "version": 1, "agent_id": "agt_...", "trust_level": "L2", ... },
  "signature_b64": "base64(ML-DSA-65 signature over canonical body bytes)",
  "signature_id": "att_...",
  "public_key_b64": "base64(agent public key)",
  "verify_url": "https://asqav.com/attestation/agt_..."
}

Attestations expire after seven days. Re-issue on a schedule that fits your trust window.

Public verify

No auth. Any third party fetches the latest attestation and verifies offline.

A second public endpoint GET /api/v1/agents/{id}/card returns an A2A-compatible Agent Card with the same governance metadata embedded under extensions.asqav.governance. For direct A2A interoperability, see the A2A Agent Card doc.

bash

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

Both public endpoints return 410 once the attestation has expired (seven days from issuance, see above) or the agent has been revoked or decommissioned, and 403 while the agent is suspended or quarantined. See the A2A Agent Card doc for the full status-code contract.

Post-apply attestation

Asqav already proves intent (sign), authorization (countersign and HITL). Post-apply attestation adds proof of execution: the downstream service that actually carried out the action signs back, the server verifies the signature over the canonical bytes, and the verbatim attestation is stored on the SignatureRecord.

http

POST /api/v1/signatures/{signature_id}/applied-attestation
{
  "applied_at": "2026-05-03T15:30:00",
  "outcome": "success",
  "error_code": null,
  "executor_pubkey_b64": "...",
  "executor_algorithm": "ML-DSA-65",
  "signature_b64": "..."
}

outcome is one of success, fail, or partial. error_code is a free-form short string when outcome is not success.

Counterparty pinning

At sign time, the original signer can pin the executor by passing expected_executor_pubkey_b64. When set, the applied-attestation endpoint rejects an attestation signed by any other key with executor_key_mismatch, and the rejection is persisted to the rejected-attempts log. See Observability.

A2A Agent Card integration

If your agent advertises an A2A Agent Card, include the attestation URL and hash. Counterparties check governance before accepting a request.

json

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

Dashboard

Each agent row shows a trust-level pill (L1 / L2 / L3) next to its name once attested. The action bar gains an attest button which issues a fresh attestation in one click. L0 is hidden.

The public verify endpoint is open to everyone, so once an org issues an attestation on an agent it is immediately verifiable by any third party.