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.xyz) 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: coinbase/x402#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