Example: Auditor Agent with cryptographic handoff verification

[tomjwxf]

Problem

Swarm demonstrates lightweight multi-agent orchestration with handoffs. When Agent A hands off context to Agent B, there is no cryptographic proof of what context was transferred, what policy governed the handoff, or that the handoff record hasn't been modified. For production multi-agent systems built on Swarm patterns, this creates an accountability gap.

Proposal

Add an Auditor Agent example that uses Ed25519 receipt signing to cryptographically verify handoff context between swarm agents. Each handoff would produce a signed receipt creating a verifiable chain:

Triage Agent (receipt_001) → Sales Agent (receipt_002, parent=001) → Refund Tool (receipt_003, parent=002)

This transforms the handoff chain from an opaque runtime behavior into verifiable evidence.

Reference

protect-mcp (MIT, v0.5.3) already tracks swarm topology across 11 lifecycle events. Receipt format: IETF Internet-Draft.

This could work as an example in the /examples directory showing enterprise-grade audit patterns for Swarm.

[0xbrainkid]

The Ed25519 receipt chain pattern is exactly right — transforming handoffs from opaque runtime events into verifiable evidence is what makes multi-agent systems auditable at scale.

A few additions worth including in the example to make it maximally useful for production reference:

1. Behavioral trust score on each receipt. The receipt proves what context was transferred and who signed it. Adding a trust score for the receiving agent at handoff time gives the chain a third dimension: not just "Agent A handed off to Agent B" but "Agent A handed off to Agent B, which had trust score 0.87 at that moment." If Agent B later behaves anomalously, the historical trust score in the receipt establishes a baseline for drift detection.

2. Cross-org receipt verification. If the Swarm example shows two agents from the same process, the receipt chain is internally consistent. But for cross-organizational handoffs (the harder and more important case), the verifier needs to trust the signing keys without a pre-existing relationship. Anchoring receipt hashes in a neutral registry (SATP or equivalent) lets third parties verify the chain without trusting either originating organization.

3. Receipt propagation format. The parent receipt reference (receipt_002, parent=001) is the right structure. Encoding it as a JSON-LD object with a proof block (following W3C Verifiable Credentials format) would make it interoperable with existing VC tooling and legal frameworks that already recognize VC format for digital evidence.

The protect-mcp / IETF draft reference is a good anchor — happy to contribute SATP integration into the auditor example if the direction looks right.

[tomjwxf]

0xbrainkid, all three additions are worth folding in. Quick reactions:

(1) Behavioral trust score per receipt. Yes. The receipt format already has a context field that can carry an arbitrary scored object, so adding a trust_score signed at handoff time is a schema addition, not a format change. It keeps the trust state verifiable alongside the handoff rather than stored in a separate out-of-band system. Worth adding to the worked example.

(2) Cross-org verification. Agreed this is the harder case and the more important one. Anchoring receipt hashes in a neutral registry is the right shape. Sigstore Rekor works today for this (inclusion proof + transparency log), and in-toto predicates give you the schema for what goes in the entry. There is a proposal at in-toto/attestation#549 to formalize Decision Receipts as a predicate type; if that lands, Rekor-anchored receipts become a default cross-org pattern. SATP would be another option if it reaches the level of adoption Rekor already has.

(3) JSON-LD / VC format. W3C VC interop is a real ask from legal tooling. The IETF draft keeps the core receipt JCS-canonical and signature-agnostic, so a VC wrapper is a straightforward projection rather than a reformat. Happy to sketch the mapping in the worked example if useful.

On collaboration: the receipt format lives at draft-farley-acta-signed-receipts. A reference verifier (Ed25519 + JCS + chain verification, no vendor dependency, Apache-2.0) is at github.com/ScopeBlind/sb-runtime. Either is fine as an anchor; the point is the chain should verify with any conformant implementation, not one.

[tomjwxf]

Agreed on both. Non-cooperative-agent assumption should be stated explicitly in the worked example. Splitting cross-org verification into its own issue works, that discussion pulls in registry/anchoring (Sigstore Rekor, in-toto #549) that deserves its own thread. Happy to file.

[arian-gogani]

this is exactly the primitive we built at nobulex.

Ed25519 signed receipts over JCS-canonical JSON (RFC 8785) for every agent action, including handoffs. the action_ref (SHA-256(JCS({agent_id, action_type, scope, timestamp_ms}))) serves as the handoff record's primary key. modify anything after the fact and the signature breaks.

for Swarm handoffs specifically:

from nobulex import Agent

agent_a = Agent("triage-agent")
receipt = agent_a.act("handoff", scope="transfer_to_sales_agent:context_hash_abc123")
# receipt.action_ref is the cryptographic proof of the handoff
# receipt.verify() checks Ed25519 signature

the receipt carries:

• which agent initiated the handoff (agent_id)
• what was transferred (scope with context hash)
• when it happened (timestamp_ms)
• which policy governed it (policy_version)
• Ed25519 signature for non-repudiation

the format is cross-validated across 4 JCS implementations (Python, JS, Go, Java), 16/16 byte-for-byte. already being consumed by reputation systems and anchored on-chain.

github.com/arian-gogani/nobulex

happy to contribute this as the Auditor Agent example if there's interest.