Integration: @scopeblind/crewai — Ed25519 signed receipts for crew task execution

[tomjwxf]

We publish @scopeblind/crewai (MIT) which adds Ed25519-signed receipts to CrewAI task execution. Wanted to flag this for deeper integration.

What it does today

Every crew task delegation and tool call produces a cryptographic receipt:

• Ed25519 signature on the decision payload (JCS-canonicalized)
• Cedar policy evaluation — per-tool allow/deny/rate-limit rules
• Receipt chain — hash-linked, tamper-evident ordering across task delegations
• Offline verification — npx @veritasacta/verify checks signatures without any server

Why this matters for multi-agent crews

When Agent A delegates to Agent B who calls Tool C:

1. The delegation receipt proves A authorized B
2. The tool call receipt proves B called C with specific arguments
3. The policy receipt proves Cedar allowed the call under the active policy set
4. The chain proves ordering — B's call happened after A's delegation

Unsigned task logs can't provide any of these guarantees.

How it differs from other proposals

I've seen several audit trail proposals in the issue tracker. Key differences:

• No blockchain, no token, no consensus mechanism — receipts are portable JSON files with Ed25519 signatures
• Already standardized — receipt format is an IETF Internet-Draft
• Already integrated elsewhere — merged into Microsoft Agent Governance Toolkit
• Published and installable today — npm install @scopeblind/crewai

Integration depth

The current @scopeblind/crewai package wraps task execution externally. A deeper integration could hook into CrewAI's task delegation pipeline directly — signing at the Crew.kickoff(), Task.execute(), and tool invocation boundaries.

Happy to build a PR if there's interest in native receipt support.

npm: https://www.npmjs.com/package/@scopeblind/crewai
Examples: https://github.com/ScopeBlind/examples

[aeoess]

Solid work. JCS canonicalization for receipt signing, hash-linked chain for ordering, and Cedar for policy evaluation is a clean stack. The IETF Internet-Draft (draft-farley-acta-signed-receipts) as the receipt format basis is the right call for interop.

Two areas where this intersects with what we've been building:

Receipt format convergence. APS produces Ed25519-signed receipts with JCS-canonicalized payloads and hash-linked chains (the previousReceiptHash field chains receipts into a tamper-evident sequence). The format is structurally close to what ScopeBlind produces. The question is whether we can converge on a shared receipt schema that both systems emit, so a verifier consuming CrewAI task execution logs doesn't need to implement two different verification paths depending on which governance layer produced the receipt.

The minimum interoperable receipt would need: signer public key, JCS-canonicalized payload, Ed25519 signature, previous receipt hash, timestamp. Both systems already produce all five fields. The divergence is in the policy evaluation payload: ScopeBlind carries Cedar policy results, APS carries delegation scope + spend constraints + floor principle evaluations. A shared extensions field could carry policy-specific data without breaking the common verification path.

Delegation chains upstream of task receipts. ScopeBlind's receipt proves "Agent B called Tool C with arguments X." APS adds the layer above: "Principal Alice authorized Agent A, Agent A delegated to Agent B with scope [code_execution] and spend limit $500, and Agent B's call to Tool C was within that delegation's scope." The delegation chain is what makes the receipt meaningful to an auditor who wants to trace authority back to a human principal.

The composition: APS produces the delegation chain and enforces scope/spend at the gateway. ScopeBlind produces the execution receipt with Cedar policy evaluation at the tool boundary. Both sign their respective artifacts. A complete audit trail carries both.

On the Microsoft AGT merge (PR #667): the AGT integration validates that the receipt format works across governance frameworks. APS has a separate AGT PR that was recently merged (#598) covering the delegation chain side. If ScopeBlind and APS both have AGT integrations, that's a natural test bed for receipt format convergence.

SDK: npm install agent-passport-system (v1.34.0). The CrewAI adapter is at src/adapters/crewai.ts with governedToolCall() and taskCallback() hooks. Happy to align on receipt schema if you want to compare field mappings.

[tomjwxf]

@aeoess - this is a thoughtful analysis and the layered composition is exactly right. APS handles delegation authority and scope enforcement upstream. protect-mcp handles execution receipts and Cedar policy evaluation at the tool boundary. Both sign their respective artifacts. A complete audit trail carries both.

On receipt format convergence: the five common fields you identified (signer public key, JCS-canonicalized payload, Ed25519 signature, previous receipt hash, timestamp) are already specified in draft-farley-acta-signed-receipts (IETF Internet-Draft). Rather than aligning two moving targets bilaterally, I would suggest converging on the draft as the normative base. It gives both systems (and any future implementer) a single verification path.

The extensions approach you proposed maps cleanly to this:

Common envelope (IETF draft):

• payload - JCS-canonicalized per RFC 8785
• signature - { alg: "EdDSA", kid, sig }
• payload.previousReceiptHash - chain linking
• payload.issued_at - timestamp
• payload.issuer_id - signer identity

ScopeBlind extensions (inside payload.extensions.scopeblind):

• cedar_decision - permit/deny from Cedar WASM evaluation
• policy_digest - SHA-256 of active Cedar policy set
• tool_input_hash - SHA-256 of raw tool input bytes (privacy-preserving binding)
• mode - shadow or enforce
• tier - trust tier classification

APS extensions (inside payload.extensions.aps):

• delegationChain - principal authority path
• scope - capability constraint
• spend - budget tracking
• finality - lifecycle state
• intentSignature / decisionSignature - 3-signature chain components

A single verifier checks the envelope signature. Policy-specific validation layers on top. Extensions are covered by the signature (tamper-evident) but not part of the verification contract.

Field mapping against the draft

IETF Draft Field	ScopeBlind	APS ExecutionEnvelope
payload	payload (Passport envelope)	Root object fields
signature.alg	"EdDSA"	signature.algorithm: "Ed25519"
signature.kid	"sb:issuer:..."	signature.public_key (hex)
signature.sig	Hex string	signature.value (hex)
receipt_id	Content-addressed (sha256:...)	Random (rcpt_ + hex)
issued_at	ISO 8601	timestamp (ISO 8601)
issuer_id	sb:issuer:<fingerprint>	agent_did
previousReceiptHash	edges[].receipt_id (typed DAG)	previousReceiptHash (linear)
spec	draft-farley-acta-signed-receipts-01	schema: "execution-envelope.v0.1"
Canonicalization	JCS (RFC 8785)	JCS (RFC 8785)

The main structural question for convergence is chaining. ScopeBlind uses typed edges forming a directed acyclic graph (supports branching delegation chains and multi-causal decisions). APS uses linear previousReceiptHash. The IETF draft specifies linear chaining, which is a subset of the DAG model. Both can coexist: a receipt can carry both previousReceiptHash for linear compatibility and typed edges for richer topology.

Concrete interop example

I put a reference envelope in the examples repo: interop/interop-envelope.json

It shows a single receipt following the draft, with an extensions object carrying both ScopeBlind and APS domain-specific fields. The companion README includes the full field mapping table.

AGT as test bed

Both ScopeBlind (#667) and APS (#598) are merged into the Microsoft Agent Governance Toolkit. If both systems emit receipts following the same IETF draft envelope, a single AGT verifier handles both. That is the natural place to test format convergence with real tool calls flowing through both governance layers.

Verification for any receipt following the draft envelope:

npx @veritasacta/verify@0.2.5 receipt.json --key <issuer-public-key-hex>
# Exit 0 = valid, 1 = invalid (tampered), 2 = error (malformed)

Happy to dig deeper into the field mapping. The draft is the stable reference point.

• IETF Draft
• Interop example
• Verifier (Apache-2.0, offline, zero-dependency)

[aeoess]

The field mapping table is exactly what was needed to move from "these two systems should interop" to "here is how they interop."

Three things that confirm convergence:

1. Canonicalization alignment. Both systems use JCS (RFC 8785). This means byte-identical canonical forms for the same payload across implementations. The interop envelope in your examples repo should produce identical hashes when processed by either agent-passport-system or @veritasacta/verify. That's testable today.

2. The chaining question is resolved by layering. Linear previousReceiptHash (IETF draft, APS) is a subset of typed DAG edges (ScopeBlind). A receipt can carry both: previousReceiptHash for linear verifiers that only need chain integrity, and edges[] for topology-aware verifiers that need causal structure. Neither breaks the other. The IETF draft's linear model is the interop baseline; the DAG is the richer view for systems that support it.

3. AGT is the right test bed. Both merged — APS #598, ScopeBlind #667. A single AGT workflow that emits receipts from both governance layers, verified by npx @veritasacta/verify, proves format convergence with real tool calls. I'll set up a test scenario on the APS side: issue passport → create delegation → execute tool call through ProxyGateway → emit receipt in the draft envelope format. If your verifier accepts it at exit 0, we have interop.

On the extensions namespace: payload.extensions.aps is clean. The APS fields that belong there: delegationChain, scope, spend, finality, intentSignature, decisionSignature. These are covered by the envelope signature (tamper-evident) but opaque to non-APS verifiers. Correct separation.

Next concrete step: I'll produce 3 test receipts in the IETF draft envelope format from real APS ProxyGateway executions and post them to the interop examples repo. If they verify against @veritasacta/verify, we have cross-system receipt compatibility.

[aeoess]

IETF Draft Envelope Receipts — APS Test Vectors

Three signed receipts in draft-farley-acta-signed-receipts-01 format, generated from real APS ProxyGateway execution paths:

Receipt	Scenario	Finality
receipt-permit.json	Permitted tool call (code_execution)	executed
receipt-deny.json	Denied tool call (admin:delete scope violation)	denied
receipt-commerce.json	Commerce preflight ($49.99 within budget)	executed

All three are chained via previousReceiptHash. Each is Ed25519-signed over the JCS-canonicalized (RFC 8785) payload with APS extensions (delegation chain, scope, spend, finality, intent + decision signatures).

Verify

git clone https://github.com/aeoess/agent-passport-system
cd agent-passport-system/examples/interop/ietf-envelope
bash verify.sh

APS Extensions

The extensions.aps block in each receipt includes:

• delegationChain — links to the APS delegation that authorized the action
• scope — what the delegation covers
• spend — commerce tracking
• finality — executed or denied
• intentSignature — agent's Ed25519 proving intent
• decisionSignature — gateway's Ed25519 proving evaluation

Full directory: examples/interop/ietf-envelope/

[tomjwxf]

@aeoess - all three of your APS test vectors verify against @veritasacta/verify@0.2.5. Exit code 0 on every one:

$ npx @veritasacta/verify@0.2.5 receipt-permit.json --key 63b6e763...
✓ Signature: VALID
  Format:   passport
  Kid:      did:aps:z6MkmAWAje6E2baGbKY7vNUAhDdAEkJFXn4Q6fhhZ7xsUaXA

$ npx @veritasacta/verify@0.2.5 receipt-deny.json --key 63b6e763...
✓ Signature: VALID

$ npx @veritasacta/verify@0.2.5 receipt-commerce.json --key 63b6e763...
✓ Signature: VALID

That is cross-system receipt interop. Two independent implementations (APS ProxyGateway and protect-mcp), same IETF draft envelope format, one verifier accepts both. The JCS canonicalization alignment means byte-identical hashes across implementations, as you predicted.

The extensions.aps blocks (delegationChain, scope, spend, finality, intentSignature, decisionSignature) are covered by the envelope signature but opaque to the verifier, exactly as intended. The verifier checks the math; policy-specific validation is layered on top.

Next step from my side: I will add your three test vectors to the ScopeBlind/examples interop directory alongside the ScopeBlind test vectors, so there is a single cross-system corpus. Any new implementer can verify both sets against the same IETF draft spec.

For the AGT test bed: once both sets of receipts are in the interop corpus, a single AGT workflow emitting receipts from both governance layers is the natural next demonstration.

[aeoess]

@tomjwxf — that's the first independent verification of APS receipts by an external tool. Three vectors, three passes, zero modifications needed on either side. The JCS alignment was the bet — if both implementations canonicalize identically, the signatures are portable by construction.

The architecture you described is exactly right: the envelope signature covers the extensions.aps block but the verifier doesn't parse it. Governance-specific semantics (delegation chains, scope narrowing, spend tracking) are layered on top by consumers who understand APS. A generic IETF envelope verifier just checks the math. This means any new governance layer can add its own extensions block and get the same property: signed, opaque to other verifiers, parseable by its own tooling.

Adding the vectors to the ScopeBlind interop corpus makes sense. A single directory where any implementer runs npx @veritasacta/verify against both APS and ScopeBlind receipts and gets exit code 0 on all of them. That's the interop proof that matters — not a compatibility matrix, but a shared test corpus with a single verification command.

For the AGT test bed: a workflow that emits receipts from both governance layers exercising the same tool call would demonstrate the composition model. One tool call, two governance evaluations (APS delegation scope + ScopeBlind policy), two receipts, both verifiable by the same envelope verifier. The receipts chain to different policy engines but share the same cryptographic envelope.

The test vectors are at examples/interop/ietf-envelope/. SDK: npm install agent-passport-system@1.36.2 — the createIETFEnvelope() function produces the envelope format, verifyIETFEnvelope() validates it.

[tomjwxf]

@aeoess the independent verification confirms the architecture works as designed. Three vectors from APS ProxyGateway, verified by an external tool (ScopeBlind verifier), zero modifications on either side. The JCS alignment is what makes this possible by construction rather than by coordination.

Adding the APS vectors to the ScopeBlind interop corpus now. The single-directory, single-command verification story is the right proof of convergence for anyone evaluating which governance layer to adopt. They don't have to choose - both work with the same envelope.

For the AGT composition test: one tool call, two governance evaluations (APS delegation scope + ScopeBlind Cedar policy), two receipts, one verifier. That demonstrates the full stack. Happy to coordinate on the scenario.

[aeoess]

@tomjwxf — the composition test is the right next step. One tool call producing two independent governance evaluations from two different engines, both verifiable with one command, proves the architecture better than any spec document could.

For the scenario: pick something concrete. A CrewAI task execution where the agent calls a tool with spend implications. APS checks delegation scope + spend limit. ScopeBlind evaluates Cedar policy on the same call. Both produce receipts. The verifier checks both receipts against the same action_ref without needing to understand either governance engine's internals.

The action_ref is the anchor. If both receipts reference the same action by the same hash, a verifier knows they're talking about the same event. If either receipt is missing or invalid, the verification fails for that layer without affecting the other.

I can produce the APS side (delegation + evaluation + receipt) for whatever tool call scenario you pick. You produce the ScopeBlind side (Cedar policy + receipt). We publish both alongside a verifier script that checks both in one pass. That's the demo.

[tomjwxf]

@aeoess good framing. For the scenario: a CrewAI task execution where the agent calls a tool that makes an API request with spend implications. Something like:

• Tool: `execute_api_call`
• Action: POST to a paid API endpoint
• Spend: $0.50
• APS checks: delegation scope includes `tools:api_call`, spend within $500 budget
• ScopeBlind checks: Cedar policy permits API calls for this agent tier, rate limit not exceeded

Both receipts reference the same `action_ref` (SHA-256 of the tool call input). The verifier script checks both in one pass without understanding either engine's internals.

Will set up the ScopeBlind side after shipping a product demo this week. The action_ref anchoring is the key design decision - agreed that it should be a content hash of the tool invocation, not a random ID.

[aeoess]

@tomjwxf — that scenario maps perfectly. The action_ref as content hash of the tool invocation is what makes bilateral verification work: both engines (APS delegation + ScopeBlind/Cedar policy) independently evaluate the same action, produce independent receipts, and the verifier links them by hash without needing to understand either engine.

For the CrewAI integration point: the natural hook is the tool execution layer. Before execute_api_call runs, the CrewAI task runner computes action_ref = sha256(agent_id + tool_name + canonical(args)), sends it to both engines, gets two receipts back, and proceeds only if both permit. The receipts go into the task's audit trail.

The SDK function for this is computeActionRef() — takes agent_id, action_type, and scope, returns the deterministic hash. Available in agent-passport-system@1.36.4 on npm.

No rush on the ScopeBlind side — ship the demo first. When you're ready, the interop fixture format at agent-passport-system/interop/fixtures/ has examples of the receipt chain structure.

[creatorrmode-lead]

We've been running a similar receipt/attestation model in production at AgentVeil Protocol. Ed25519 signed attestations with hash-chained ordering and IPFS anchoring for tamper evidence. One thing we ran into: receipt chains work great for honest actors, but you also need a layer to handle collusion. Agent A and B mutually inflating each other's trust is a real attack vector. We ended up adding EigenTrust graph analysis on top of the raw attestation data.

If you're interested in interop testing against another Ed25519 attestation implementation, happy to share our schema. SDK is MIT: pip install agentveil

[aeoess]

@creatorrmode-lead — the EigenTrust point on collusion is right. Bilateral signatures prove agreement, not accuracy. We handle this through the Bayesian reputation model: cosigned outcomes adjust mu (mean trust) but the sigma (uncertainty) reduction is weighted by counterparty diversity. Two agents that only cosign with each other get diminishing sigma reduction regardless of quality scores.

On interop testing: yes. If AgentVeil produces Ed25519-signed attestations with content-addressed action references, the verification path is straightforward. Our computeActionRef() produces sha256(agent_id + action_type + canonical(scope)) — if your attestations reference the same action by the same hash, a verifier can check both independently.

The interop fixture format is at github.com/aeoess/agent-passport-system/tree/main/interop/fixtures. If you publish a sample AgentVeil attestation, I'll run it through our verification path and report results.

[creatorrmode-lead]

aeoess - Appreciate the detailed breakdown of the sigma reduction approach; solid trade-off.

The action reference mapping looks compatible in principle. We're focused on a few other priorities right now, but interop is on our radar. Will circle back when timing works.

[tomjwxf]

@aeoess -- demo is shipped (sigil.scopeblind.com). Ready to build the ScopeBlind side of the composition test.

Scenario: execute_api_call tool, POST to a paid endpoint, $0.50 spend.

I'll produce the ScopeBlind receipts:

• Cedar policy evaluation (permit: agent tier allows API calls, rate limit check passes)
• Execution receipt (tool name, input hash, output hash, policy digest)
• action_ref = SHA-256 of the canonical tool invocation

Both receipts will follow the IETF draft envelope with extensions.scopeblind carrying the Cedar-specific fields. Your APS side produces the delegation receipt with extensions.aps carrying scope + spend.

ETA: ScopeBlind side pushed to the interop directory by end of week. The combined verification script will run npx @veritasacta/verify against both APS and ScopeBlind receipts for the same action_ref.

Question on action_ref: should we use computeActionRef() from agent-passport-system@1.36.4 for the hash, or define it in the IETF draft? If it's going to be the anchor for cross-engine correlation, it probably belongs in the spec rather than in either implementation.

@creatorrmode-lead -- the collusion/Sybil concern is valid. Receipt chains prove ordering and integrity but don't inherently prevent trust inflation between colluding agents.

In the architecture aeoess and I have been building, the collusion defense comes from the delegation chain: Agent B can only act within the scope that Agent A delegated, and Agent A can only act within the scope that a human principal authorized. Inflating trust scores doesn't help if the scope boundary is enforced cryptographically at each delegation step.

That said, I'd be interested to see your attestation schema for an interop comparison. If it follows Ed25519 + JCS canonicalization, the @veritasacta/verify CLI should handle it without modifications. That would make three independent implementations producing interoperable receipts.