Feature: Cryptographic action receipts for enterprise agent governance (AAR)

[Cyberweasel777]

Problem

AutoGen enables multi-agent conversations and workflows for enterprise use cases. Enterprise deployments require verifiable audit trails — not just logs, but cryptographic proof of:

• Which agent was instructed to do what
• What each agent actually executed
• What data was consumed and produced
• Whether outputs were tampered with between agents

Current observability (LLM traces, conversation logs) captures what happened but can't prove it to an external auditor or compliance system.

Proposal: Agent Action Receipt (AAR) Integration

AAR v1.0 provides exactly this:

• Ed25519 signatures over canonicalized JSON (JCS-SORTED-UTF8-NOWS)
• SHA-256 input/output hashing — proves data without revealing sensitive content
• Selective disclosure — share minimum information per party (aligned with Mastercard's Verifiable Intent standard)
• Chain-able receipts — multi-agent conversations produce a verifiable receipt chain

Enterprise relevance

• Mastercard Verifiable Intent (announced March 5, 2026 with Google, IBM, Fiserv) — AAR includes bidirectional mapping
• HIPAA/SOC2 audit requirements → AAR provides non-repudiable action evidence
• x402 (Coinbase) compatible for agent payment verification

SDK

npm install botindex-aar

TypeScript. Single dependency (tweetnacl). Express middleware or manual builder. Python SDK in development.

• Spec: https://github.com/Cyberweasel777/agent-action-receipt-spec
• Landing: https://aar.botindex.dev

Happy to discuss integration approach or contribute a PR. MIT licensed.

[Cyberweasel777]

Update: companion standard shipped — Session Continuity Certificates (SCC).

For AutoGen's enterprise multi-agent patterns, SCC addresses the agent identity continuity requirement: prove that an agent has maintained consistent identity across sessions, with cryptographic key rotation support.

• SCC Spec: https://github.com/Cyberweasel777/session-continuity-certificate-spec
• SCC SDK: npm install botindex-scc
• Full trust stack: AAR (action proof) + SCC (identity proof), bound via sccHash

Same Ed25519 + JCS crypto stack. One keypair for both standards.

[passionworkeer]

Great proposal for enterprise governance. For implementation, consider a pluggable architecture where different receipt formats can be supported. Also, think about backward compatibility with existing agent workflows.

[fjnunezp75]

Interesting timing on this — GPU-Bridge (https://gpubridge.io) is running x402 in production for exactly this use case.

When an agent calls our inference endpoints (LLM, embeddings, STT, image gen), it sends USDC on Base L2 via x402. The HTTP 402 response includes the payment details; the agent settles onchain; the service responds with the result + a signed receipt.

What this gives you for your AAR use case:

• The payment transaction on Base is public and immutable — it proves the agent authorized the call at a specific block height
• The x402 receipt includes the payload hash, so you can verify the request wasn't tampered with
• No shared secret, no API key rotation — the "credential" is just the agent's wallet

The gap I can confirm from production: x402 proves the agent paid, but doesn't natively prove what the service returned. Your AAR spec filling in the output hash/signature side is the missing piece to close that loop.

Our coinbase/x402 ecosystem PR (#1619) has some notes on the flow if useful: https://github.com/coinbase/x402/pull/1619

[aelitium-dev]

The gap @fjnunezp75 pointed out is exactly the missing layer at the LLM boundary.

x402 proves the agent paid.
AAR proves the agent acted.

But between those two events there is an LLM call, and neither spec currently defines what "prove what the model returned" means in verifiable terms.

One approach is to treat the LLM call itself as a verifiable artifact.

For example, an evidence bundle could expose:

{
  "request_hash":  "sha256:...",
  "response_hash": "sha256:...",
  "binding_hash":  "sha256:..."
}

Where binding_hash = sha256(canonical({request_hash, response_hash})).

Verification can be done offline:

aelitium verify-bundle ./bundle
aelitium compare bundleA bundleB

So the AAR evidenceRef field could reference something like:

type: "aelitium/binding-bundle"

This keeps the receipt generic while giving the LLM evidence layer concrete semantics.

Reference implementation (Python, Apache-2.0):
https://github.com/aelitium-dev/aelitium-v3

[fjnunezp75]

The evidence bundle structure you propose closes the gap cleanly. The binding_hash is the critical piece — it ties the payment (x402) to the action (AAR) to the model output, so all three can be verified independently without trusting any single component.

The missing implementation detail: who signs the binding_hash? If it is the provider, you are back to trusting the provider. If it is the agent, the agent cannot sign what the provider returned without the provider cooperating. The only way to make it trustless is if both parties sign — provider signs the response_hash, agent signs the binding (payment_tx + request_hash + response_hash), and both signatures are persisted.

We are building toward this at GPU-Bridge: x402 proves the agent paid, and we are working on HMAC-signed receipts where both the payment and the response hash are included. The bilateral signature model is the right target. Happy to share implementation notes if useful for the AAR spec.

[Cyberweasel777]

@fjnunezp75 — the bilateral signature problem is the right question. You're correct that single-party signing doesn't achieve trustlessness.

AAR v1.1 (just shipped) adds evidenceRef to address exactly this layering:

{
  "evidenceRef": [
    {
      "type": "x402/payment-proof",
      "hash": { "alg": "sha256", "digest": "..." },
      "uri": "base:0xTxHash..."
    },
    {
      "type": "aelitium/binding-bundle",
      "hash": { "alg": "sha256", "digest": "..." },
      "issuer": "provider"
    },
    {
      "type": "agent/binding-countersign",
      "hash": { "alg": "sha256", "digest": "..." },
      "issuer": "agent"
    }
  ]
}

The receipt itself carries the agent's Ed25519 signature (proves the agent attests to the action). The evidenceRef entries point to the provider's signed response hash and the on-chain payment proof. Three independent signatures, three independent verification paths, no single trust root.

The bilateral model you're building at GPU-Bridge is the right target. The spec change we just pushed: Cyberweasel777/agent-action-receipt-spec@0a24988

On the practical side — we also just shipped compliance intelligence endpoints that agents can query before making x402 payments. Regulatory exposure checks, threat radar, jurisdiction risk scoring. If an agent is about to pay for inference from a provider in a sanctioned jurisdiction, it can check first:

GET /api/botindex/compliance/exposure?project=gpu-bridge

That's the full loop: discover the service (Agorion) → compliance check (BotIndex) → pay (x402) → execute → prove it happened (AAR with bilateral evidence).

@aelitium-dev — evidenceRef with type: "aelitium/binding-bundle" is now in the schema. Spec + example: https://github.com/Cyberweasel777/agent-action-receipt-spec/blob/main/examples/evidence-ref-receipt.json

Would be interested in GPU-Bridge's HMAC receipt format — if it can map to an evidenceRef entry, agents get interop across both approaches without choosing one.

[fjnunezp75]

The three-layer evidenceRef structure solves the trust root problem cleanly. Three independent signatures with three independent verification paths means no single party can forge the complete bundle — you need the on-chain tx hash (immutable), the provider signature (their key), and the agent countersign (agent key).

The Ed25519 countersign is the right choice for agents — stateless, fast, no key management overhead compared to secp256k1.

On the GPU-Bridge implementation side: we are currently signing provider responses with HMAC-SHA256 using a per-account secret (simpler to implement, not trustless). The move to provider Ed25519 + agent countersign is the next step, and your evidenceRef structure gives us a clean schema to target.

Two questions on the AAR v1.1 spec:

1. The type — what does it bind specifically? Just response_hash + payment_hash, or does it include the input (prompt/request) hash as well? Including the input is important to prove the provider received and processed the specific request, not just that a payment occurred.

2. On revocation: if an agent key is compromised, how does the spec handle invalidating countersigned receipts? Is there a key rotation mechanism, or does receipt validity become permanently dependent on the original key state at signing time?

Will read through the 0a24988 commit now.

[aelitium-dev]

Good question on the input hash — in AELITIUM the bundle already includes it.

The structure today is:

• request_hash — canonical hash of model + messages (the input)
• response_hash — hash of what the provider returned
• binding_hash = sha256({request_hash, response_hash})

So the bundle proves the specific request ↔ response pairing, not just that a response existed.

That makes it possible to bind the full chain you outlined:

payment_tx → request_hash → response_hash → binding_hash → agent countersign

Signatures can then be layered on top without changing the bundle structure (provider signs response_hash, agent countersigns the binding).

The evidenceRef structure you added maps cleanly to this — the bundle stays deterministic, and the receipt layer handles attestations.

Happy to align field names if useful for the AAR spec.

[fjnunezp75]

The binding_hash approach is clean — sha256({request_hash, response_hash}) creates a deterministic anchor that can be independently verified by anyone with the inputs. The payment_tx → request_hash → response_hash → binding_hash → agent countersign chain is exactly the full audit trail for autonomous agent transactions.

On key rotation: we are implementing this at GPU-Bridge using HMAC-SHA256 with per-account secrets today (simpler, not trustless). Moving to Ed25519 with the binding_hash structure you describe would give us proper trustlessness. The alignment you mention on field names would be useful — we want our receipt format to be compatible with the AAR spec so operators can use standard tooling to verify both.

Specific proposal: if , we could emit it directly in our job response alongside the existing fields. The agent can then countersign it using its own key. The payment_tx is already on-chain via x402 and can be referenced by hash.

Would it make sense to draft a minimal compatibility mapping between the AAR evidenceRef fields and what GPU-Bridge currently emits? We could PR it to the spec repo if useful.

[aelitium-dev]

Good questions.

In AELITIUM the bundle already includes the input as well:

• request_hash — hash of the model + messages
• response_hash — hash of the provider response
• binding_hash = sha256(canonical({request_hash, response_hash}))

So it proves the specific request ↔ response pairing, not just that a response existed.

That fits the chain you described:

payment_tx → request_hash → response_hash → binding_hash → agent countersign

From the AELITIUM side the bundle is deterministic evidence; signatures can be layered on top without changing the bundle structure.

A rough mapping could be:

• evidenceRef.type → "aelitium/binding-bundle"
• evidenceRef.uri → GPU-Bridge job / receipt identifier (if exposed)
• evidenceRef.hash.digest → bundle or binding digest, depending on how the spec wants to point at it

If GPU-Bridge emits a stable response hash with the job result, mapping that into an evidenceRef entry looks straightforward.

Would it help to sketch a minimal example mapping between the GPU-Bridge receipt fields and the AAR evidenceRef structure?

[razashariff]

MCPS (MCP Secure) takes a similar approach — per-message ECDSA P-256 signatures over MCP tool calls and responses, with agent identity passports, nonce binding, and replay protection. MCPS focuses on the transport/message layer while AAR focuses on the action/audit layer — they'd be complementary. Published as an IETF Internet-Draft, 180 security tests, zero dependencies, drop-in middleware for any MCP server. github.com/razashariff/mcps

[razashariff]

MCPS (MCP Secure) provides the cryptographic foundation for tamper-evident action receipts. Every MCP message — tool call or response — gets a signed envelope containing:

• passport_id: which agent made the call (cryptographic identity, not a session ID)
• nonce: unique per-message, prevents replay
• timestamp: bound with a 5-minute window
• message_hash: SHA-256 of the full JSON-RPC body
• signature: ECDSA P-256 binding all fields

The onAudit callback emits a structured event for every verification outcome (accepted / rejected / replay / forgery), providing the building blocks for a tamper-evident audit chain. These events include the passport_id, method, timestamp, and outcome — ready for SIEM ingestion (we provide examples for Splunk, Datadog, ELK, and CloudWatch).

For enterprise compliance, MCPS maps to 23 SOC 2 Trust Service Criteria — CC7 (system monitoring) is directly addressed by the audit event stream.

Published as an IETF Internet-Draft and available on npm as mcp-secure (zero dependencies).

[creatorrmode-lead]

This maps closely to what we built in AgentVeil Protocol:

1. Ed25519 identity — W3C DID (did:key) with challenge-response verification
2. Hash-chained audit trail — SHA-256 chain, anchored to IPFS via Merkle tree proofs
3. EigenTrust reputation — transitive trust from peer attestations, computed via power iteration
4. Dispute resolution — contest unfair attestations, arbitrator resolves, overturned ratings excluded from reputation
5. Sybil detection — collusion clusters, same-owner cross-attestation penalty

Where this differs from AAR: AAR proves a specific action happened (compliance). AVP answers a different question — "should I delegate work to this agent?" — based on cumulative peer attestations and algorithmically computed trust scores.

These approaches are complementary — AAR for per-action audit, AVP as a trust enforcement layer for ongoing agent-to-agent trust assessment.

Production: https://agentveil.dev

[FransDevelopment]

The AAR spec addresses execution-level receipts (proving what an agent did). There's a complementary layer: proving who the agent is before it acts.

The Open Agent Trust Registry (OATR) provides runtime-level identity verification. Agent runtimes register Ed25519 public keys. The registry is a signed JSON manifest that can be verified locally without network calls.

This composes with AAR:

Layer	Question	Approach
Identity (OATR)	Who is this agent and is its runtime authorized?	Ed25519 JWT attestation verified against signed registry
Execution (AAR)	What did the agent actually do?	Cryptographic action receipts with hash chains

Together: OATR proves the agent is authorized before it acts, AAR proves what it did after it acts. The identity binds to the receipt: the same Ed25519 key that signs the OATR attestation can be referenced in the AAR receipt, creating a single cryptographic chain from authorization through execution.

This pattern is already working in production. ArkForge builds execution attestation receipts that include agent_identity (a DID) and delegation_path (referencing the OATR registry). The Agent Identity Working Group recently completed a 5-step conformance test: OATR attestation, encrypted channel, DID resolution, registry verification, and receipt cross-check, all verified by three independent projects using the same Ed25519 key.

MIT licensed, 7 registered issuers, automated CI-verified registration. The npm SDK is @open-agent-trust/registry.

[razashariff]

Update: the message integrity approach for cryptographic action receipts is now in the OWASP MCP Security Cheat Sheet (Section 7, merged this week). Covers signing, nonce-based replay protection, and tool definition pinning.

For enterprise governance specifically, two additions that complement the receipt model:

1. Pre-action trust verification -- before an agent executes a high-stakes action, check its behavioural trust score. A 5-dimension score (code attestation, execution success, behavioural consistency, operational tenure, anomaly history) gives more signal than binary allow/deny.

2. Sanctions screening gate -- for any agent action involving financial transactions or external entities, screen the counterparty before execution. This is a regulatory requirement for human-initiated transactions and will extend to agent-initiated ones.

The trust model is in draft-sharif-agent-payment-trust-00 on the IETF Datatracker.