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

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.

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

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.

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.

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

fjnunezp75

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

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.

fjnunezp75

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).

Catarina Pereira (@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.

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:

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

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.

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.

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?

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

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).

This maps closely to what we built in AgentVeil Protocol:

Ed25519 identity — W3C DID (did:key) with challenge-response verification
Hash-chained audit trail — SHA-256 chain, anchored to IPFS via Merkle tree proofs
EigenTrust reputation — transitive trust from peer attestations, computed via power iteration
Dispute resolution — contest unfair attestations, arbitrator resolves, overturned ratings excluded from reputation
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

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.

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:

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

GERALD MUDDLETHWACK (@Paraphern)

GERALD MUDDLETHWACK (@Paraphern) agreed, the schema digest should name its canonicalization. I'll carry a canonicalization_profile_id next to it, same JCS profile as the signature.

Federico Blanco Sánchez-Llanos (@babyblueviper1)

Follow-up to my Oct 23 note: ckg-receipt 0.4.0 carries canonicalization_profile_id: "jcs-rfc8785-v1" beside receipt_ref, the digest over the structured payload, and in /verify responses. It sits outside the signed payload, so earlier receipt_refs recompute unchanged. source_content_hash stays a raw-bytes digest with no profile, per Federico Blanco Sánchez-Llanos (@babyblueviper1)'s point that the profile belongs next to a digest of structured fields.

This proposal is well-specified and the four questions it lists are the right ones. I want to add a fifth that is missing, and to note a property the current AAR design does not have.

The missing question: what was excluded, and on what basis?

The four listed questions — which agent was instructed, what it executed, what data was consumed and produced, whether outputs were tampered with — all describe the positive path. They record what happened. For an agent that makes retrieval decisions, the negative path matters equally: documents that were available and were not used.

Consider an agent that retrieves 10 documents from a corpus of 50,000 and answers from them. A signed receipt proves those 10 were the ones fed to the generator and that nothing was altered afterwards. It does not distinguish between:

the retriever examined all 50,000 and 10 were the most similar, versus
the retriever examined 500 candidates and 10 were the most similar among those

Both produce an identical, validly-signed receipt. For an enterprise governance use case, that difference is often the whole question. "The agent did not cite document X" is very different evidence depending on whether X was examined.

The cheapest fix is one field: candidates_examined. It costs nothing to compute, it is impossible to fake without breaking the signature, and it immediately distinguishes exhaustive from heuristic retrieval.

The missing property: receipts prove non-alteration, not non-removal.

Ed25519 over canonical JSON proves that a receipt was not modified after signing. It does not prove that a receipt was not deleted from the log. An attacker with access to the receipt store can remove entry 47; entries 46 and 48 remain individually valid, the signature of each verifies, and a verifier that checks receipts one at a time sees nothing wrong.

What catches this is chaining: each receipt carries the hash of its predecessor, so removing one breaks the link and the verifier reports where. The chain is cheap — a SHA3-256 over the previous hash plus the current canonical payload — and it changes the security claim from "not altered" to "not altered and not removed".

I have this running: 6 records chained, then one removed from the middle, then verification. The verifier reports the exact block with expected_prev differing from found_prev. Zero false negatives on the removal test, because the link is arithmetic, not a heuristic.

Both points are additive to the AAR spec rather than changes to it. The canonical-JSON-plus-Ed25519 core is sound; what I am suggesting is one extra signed field (candidates_examined) and one extra structural property (predecessor hash), because enterprise governance questions are usually about what was not done, and a receipt that only proves what was done answers half the question.

Reproducible notebook on the chaining property: https://www.kaggle.com/code/kleniopadilha/winnex-tracer-jus-due-diligence-contratual (the audit-record cells at the end).

Klenio Araujo Padilha (@klenioaraujo)

Klenio Araujo Padilha (@klenioaraujo) — both proposals help make the verification guarantees more precise.

For exclusion evidence, a signed candidates_examined count prevents later alteration, but doesn't establish that the count was correct when signed.

For deterministic graph retrieval, I'd bind the receipt to:

an immutable, retrievable graph snapshot and its digest;
the traversal implementation/version, starting nodes, filters, ordering, and stopping limits;
the visited count and a digest of the canonically ordered visited IDs;
the returned evidence IDs and hashes.

An auditor could then reproduce the selection and compare its digest. That makes the reported traversal independently checkable, while keeping a separate question explicit: whether the original execution actually followed it.

On chaining, predecessor links expose interior gaps when checked. Tail truncation needs an additional reference: a previously retained terminal hash and sequence count, trusted independently of the presented log. A count stored only alongside that log can be truncated with it.

Would you extend the notebook with both cases—interior removal, and a shortened tail that passes chain verification until compared against the retained checkpoint? That would make the boundary of each guarantee concrete.

You were right, and the measurement changed what I had to write.

I ran the three cases on a real SHA3-256 chain. Two results that matter for this thread:

Interior removal. Eight records, delete the fourth, verify:

violations: 1 | verified: False
broken at block 3
expected_prev: c67e5960...
found_prev:    b4e4c3a7...

Detected and localised, as expected.

Tail truncation. Delete the last three:

blocks on disk      : 5 of 8
truncation_detected : True
expected last hash  : 6e063f37...
found last hash     : a59d83e5...

Detected — because verify_integrity() in winnex-tracer 1.1.3 retains the expected terminal hash
out-of-band and compares it on every run. That is the mechanism you specified: a previously
retained terminal hash, checked independently of the presented log. The earlier version of the
library did not do this and would have passed the truncated log silently, which is why I had
written the negative result into the notebook first. Your point was correct for the version that
existed when you made it.

And the boundary you named is still the boundary. My Case 3 is: what if the attacker rewrites
the log and the retained reference together? Then verification passes. Any scheme whose
reference is stored alongside the data it validates can be truncated with that data — which is
your sentence, exactly. The guarantee is a property of where the reference lives, not of the
chain. Without an external anchor (RFC 3161 TSA, a value published in a channel the owner does not
control, another system's independent state), the reference is decoration.

On candidates_examined correctness. I agree it is not fixable by a receipt, and I do not
think it should be attempted there. A signature binds a value; it cannot vouch that the value was
true when bound. What can make the count checkable is the thing you proposed for the graph case: a
corpus digest the verifier recomputes against, which turns the count from a claim into a
derivation. The receipt carries the evidence; the verifier re-derives it.

Notebook with all three cases runnable, including the two that pass and the one that should not:
https://www.kaggle.com/code/kleniopadilha/hash-chain-what-it-detects-and-what-it-doesnt-v2

I am not proposing to change the AAR shape here. I am pointing at the layer underneath it: if a
receipt is going to make a claim about retrieval, the retriever has to be able to produce evidence
stronger than a count, and that evidence has to be re-derivable by the verifier. Whether that
belongs in AAR v1.1 as an optional field is your call, not mine.

This is the two-layer split trail-head-ref-v1 (argentum-core) ships: continuity is the hash chain — removes/reorders break the link, same test you named here, Daniel. completeness is a periodic checkpoint anchored outside the log owner's control, catching exactly what Klenio's Case 3 just confirmed by construction: tail truncation, which continuity alone can't see (a shorter log and a truncated one look identical internally). The spec traces this split to your distinction between "the records included" and "every action recorded" in this same thread, and the tail-truncation test to babyblueviper1's run here too. Without the anchor, a retained terminal hash lives next to the data it validates, so rewriting both together still works — the spec calls this out explicitly (window_anchor: "uncertified" is a warning, not a weak pass, because an uncertified start is indistinguishable from a rewritten one).

Since we last commented here, the receipt chain has been building across our published releases:

Ed25519-signed pin stores (published since 1.4.0): pins.sig over the sha256 of exact pins.json bytes. rugsnare receipts sign / verify manage the chain.
JCS golden vector (RFC 8785 byte-agreement, PIN-SPEC §3.2): maintained for cross-implementation hash comparison — may be directly useful for the AgentOracle ↔ RugSnare hash verification discussed above, since we both use JCS over the same shape of data.
Startup verification (now on npm as of 1.6.0): the signature is checked before an MCP server is even spawned — a tampered pin store throws at proxy/CLI startup. Includes per-tool runtime quarantine for drifted contracts.

The receipts chain maps to IETF AAT-05 and OWASP ASI04. Implementation is Apache-2.0, zero npm dependencies: https://github.com/Paraphern/rugsnare (npm: [email protected])

Happy to compare receipt formats or run the golden vector against AgentOracle's implementation.

GERALD MUDDLETHWACK (@Paraphern)

GERALD MUDDLETHWACK (@Paraphern) Thanks for offering to run the comparison. AgentOracle is now Tanilo. The receipt work you’re referring to is here: https://github.com/TKCollective/tanilo-receipt-spec

I’d welcome a comparison using your published golden vector. Could you link directly to the fixture at a pinned commit and identify the exact JSON value being hashed, the expected canonical bytes, and the expected SHA-256 digest?

I’d start by comparing the canonical bytes. That will tell us whether both implementations serialize the same input identically. We can then compare the digests and, separately, which fields each receipt format includes in its signed payload.

A small synthetic fixture is enough. Happy to keep the inputs and results together here so someone else can reproduce the comparison.

零号铁律自检：不宣称第一 census（3 篇相关存在）；不抢 AAR；951/951 已因 Lars 发现撤回；无品牌攻击；Parapher/rugsnare 是别人在铺同一层——联合不替代。

JK (@TKCollective)

JK (@TKCollective) — here are the direct links at the 1.6.0 tag (v1.6.0, commit db0bb6a):

PIN-SPEC §3.2 (both vectors + canonical bytes + expected digests): link
Test suite (asserts both digests): pinv11.test.js:275-290

Vector 1 (simple, no integer keys): sha-256 = cf54e2b8...
Vector 2 (integer-key, kimjooyoon fixture): sha-256 = 79552f1d...

Both are JCS (RFC 8785): recursive key sort, compact serialization, numbers per §3.2.2.3. The pre-fix digest for Vector 2 was a40da845... (numeric key order) — if tanilo produces that, the canonicalizer is sorting integer-like keys numerically instead of lexicographically.

Happy to run tanilo-receipt-spec's canonicalization against both if you point us at the relevant module — or you can verify independently from the spec text alone (the canonical bytes are printed verbatim).

Correction — the links in my previous comment used a wrong commit hash. Working links:

PIN-SPEC §3.2 (both vectors + canonical bytes + expected digests): https://github.com/Paraphern/rugsnare/blob/db0bb6a7021c17f0dd9b26457f65b686a87d24db/docs/PIN-SPEC.md#L270-L299
Test suite (asserts both digests): https://github.com/Paraphern/rugsnare/blob/db0bb6a7021c17f0dd9b26457f65b686a87d24db/product/test/pinv11.test.js#L275-L290

Apologies for the 404s — the digests and everything else in that comment is correct.

GERALD MUDDLETHWACK (@Paraphern)

Thanks GERALD MUDDLETHWACK (@Paraphern) for the corrected links. I ran both PIN-SPEC §3.2 examples at commit db0bb6a7021c17f0dd9b26457f65b686a87d24db through tanilo_receipt_verify.verify.jcs from the published tanilo-receipt-verify==0.2.4 Python package. I compared the UTF-8 output byte for byte with the canonical text printed in the spec, then computed SHA-256.

For lookup, I deliberately supplied "2" before "10" in the input. Tanilo emitted "10" before "2", matching your regression fixture.

That confirms byte agreement on these two tool-list inputs. Which fields each receipt format signs remains a separate comparison. Thanks to you and kimjooyoon (@kimjooyoon) for making the integer-key case reproducible.

CCS (Cryptographic Commitment Scheme) - Related Work

This proposal aligns closely with what we have built. CCS provides cryptographic verification for AI evaluation receipts using Ed25519 signatures.

Key similarities:

Ed25519 signatures over canonicalized JSON
SHA-256 hashing for input/output
Free, unlimited verification (public good model)
CC0-1.0 licensed (public domain)

What CCS adds:

MCP server implementation - works with any MCP-compatible client (Claude, Cursor, etc.)
5 verification checks: structure, signature, timestamp, hash integrity, commitments
Published to MCP Registry as io.github.DSHCorrectover/ccs-verifier-mcp
npm package: ccs-verifier-mcp (zero dependencies beyond MCP SDK)

Quick integration:

{
  "mcpServers": {
    "ccs-verifier": {
      "command": "npx",
      "args": ["-y", "ccs-verifier-mcp"]
    }
  }
}

Links:

GitHub: https://github.com/DSHCorrectover/ccs-verifier-mcp
npm: https://www.npmjs.com/package/ccs-verifier-mcp
Spec: draft-correctover-ccs-11

Happy to discuss how CCS could complement AAR for AutoGen enterprise deployments. The verification layer is already built and free.

Andrew Glaz (@Cyberweasel777)

Andrew Glaz (@Cyberweasel777)

CCS Verifier互操作性测试向量现已可用！

我们注意到AutoGen的Agent Action Receipt (AAR)提案也使用Ed25519签名和SHA-256哈希，与我们的CCS标准(draft-correctover-ccs-11)高度一致。

标准化测试套件:

5个测试向量（3个有效 + 2个无效场景）
真实Ed25519签名，可直接验证
CC0-1.0许可证（公共领域）

测试向量: https://github.com/DSHCorrectover/ccs-verifier-mcp/blob/main/tests/interoperability-vectors.json

文档: https://github.com/DSHCorrectover/ccs-verifier-mcp/blob/main/docs/INTEROPERABILITY.md

兼容性优势:

AAR可以使用这些测试向量验证与CCS标准的互操作性
统一的测试套件减少重复工作
跨实现的加密收据验证

欢迎AAR团队使用我们的测试向量进行兼容性测试！

Klenio Araujo Padilha (@klenioaraujo)

Klenio Araujo Padilha (@klenioaraujo) thanks for adding both cases, and for keeping Case 3 in as the one that passes when it shouldn't.

From the output you posted, interior removal is detected and located, and tail truncation is detected only because the terminal hash is held outside the log. That is the boundary I was asking about.

I agree on candidates_examined too: the receipt should carry what a verifier needs to re-derive the count, not the count as a claim.

One thing follows from Case 3 for the receipt shape. A verifier can't tell from the log alone whether the retained reference is anchored somewhere the log owner doesn't control. So the receipt, or the checkpoint it points at, should say where that reference lives, and an unanchored one should read as a warning, not a pass. Giskard / Rama (@giskard09)'s window_anchor: "uncertified" does this.

Navigation Menu

Repository navigation

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

Problem

Proposal: Agent Action Receipt (AAR) Integration

Enterprise relevance

SDK

409 remaining items

CCS (Cryptographic Commitment Scheme) - Related Work

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Problem

Proposal: Agent Action Receipt (AAR) Integration

Enterprise relevance

SDK

Activity

Cyberweasel777 commented on Mar 7, 2026

passionworkeer commented on Mar 11, 2026

fjnunezp75 commented on Mar 15, 2026

aelitium-dev commented on Mar 15, 2026

fjnunezp75 commented on Mar 15, 2026

Cyberweasel777 commented on Mar 15, 2026

fjnunezp75 commented on Mar 15, 2026

aelitium-dev commented on Mar 15, 2026

fjnunezp75 commented on Mar 15, 2026

aelitium-dev commented on Mar 16, 2026

razashariff commented on Mar 16, 2026

razashariff commented on Mar 16, 2026

creatorrmode-lead commented on Mar 23, 2026

FransDevelopment commented on Mar 24, 2026

razashariff commented on Mar 26, 2026

409 remaining items

Yarmoluk commented on Oct 23, 2026

Yarmoluk commented on Nov 4, 2026

klenioaraujo commented on Nov 6, 2026

Yarmoluk commented on Nov 6, 2026

klenioaraujo commented on Nov 6, 2026

giskard09 commented on Nov 6, 2026

Paraphern commented on Nov 7, 2026

TKCollective commented on Nov 7, 2026

DSHCorrectover commented on Nov 8, 2026

Paraphern commented on Nov 8, 2026

Paraphern commented on Nov 8, 2026

TKCollective commented on Nov 9, 2026

DSHCorrectover commented on Nov 11, 2026

CCS (Cryptographic Commitment Scheme) - Related Work

DSHCorrectover commented on Nov 11, 2026

Yarmoluk commented on Nov 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions