[FEATURE] Per-agent compliance covenants with cryptographic audit receipts for multi-agent crews

[arian-gogani]

Feature Area

Core functionality

Is your feature request related to a an existing bug? Please link it here.

NA. This is a new feature request for compliance infrastructure in multi-agent crews. Related cross-framework discussion: langchain-ai/langchain#35691 (12+ teams converging on a shared compliance interface).

Describe the solution you'd like

When a crew of agents collaborates on a task, there's no way to prove which agent did what, under what rules, and whether each agent stayed within its scope. In regulated industries this blocks deployment entirely because auditors can't reconstruct the decision chain across agents.

The ask: a compliance layer where each agent in a crew gets its own behavioral covenant (what it's allowed to do), and every action produces a cryptographic receipt proving the covenant was enforced before execution. When the Researcher agent passes findings to the Writer agent, the handoff itself gets a signed receipt linking the two agents' authorization chains.

An open source protocol for this already exists: Nobulex (MIT licensed, TypeScript). The approach:

• each agent in a crew gets a covenant defining its scope: permit web:search where topic in ["market research"] for the Researcher, permit file:write where path matches "drafts/**" for the Writer
• every tool call goes through enforcement middleware. if the covenant says no, the tool never executes
• each action produces a bilateral receipt (Ed25519 signed pre-execution authorization + post-execution result, hash-chained)
• inter-agent handoffs reference upstream receipts via digest linking, so an auditor can walk the full crew execution path
• the CLI generates compliance reports for EU AI Act, SOC2, ISO 42001, and Colorado AI Act from the receipt data

CrewAI's task delegation and role-based architecture maps naturally to per-agent covenants. Each role already has a defined scope — covenants make that scope cryptographically enforced rather than prompt-enforced.

This is being discussed across frameworks. There's an active LangChain RFC with 12+ independent teams, an IETF Internet-Draft for the protocol, and NIST's AI Agent Standards Initiative is building an Interoperability Profile for Q4 2026 that covers exactly this kind of cross-agent compliance evidence. Happy to help scope a CrewAI integration.

Describe alternatives you've considered

No response

Additional context

Protocol: https://github.com/arian-gogani/nobulex
LangChain RFC: langchain-ai/langchain#35691
IETF Draft: draft-gogani-nobulex-proof-of-behavior-00
Website: https://nobulex.com
EU AI Act enforcement deadline: August 2, 2026

Willingness to Contribute

Yes, I'd be happy to submit a pull request

[dembovvski]

AgentLedger already implements per-agent covenants and cross-agent receipt linking for CrewAI.

AgentLedgerCrewCallback wraps each agent's tools individually — each agent in the crew gets its own signed receipt
chain. Inter-agent handoffs reference upstream receipts via cross_agent_ref, so an auditor can walk the full crew
execution path.

Python-native, works with existing CrewAI task delegation without changing agent code:
https://github.com/dembovvski/agentledger

[Jairooh]

Cryptographic enforcement receipts are a solid approach for per-agent auditability. For regulated industries, you also need runtime compliance infrastructure: audit trails capturing tool calls, costs, inter-agent handoffs, and all enforcement events. CrewAI handles agent-level policy; AgentShield provides the enforcement and audit layer (real-time guardrails, cost tracking, compliance reporting) that regulated teams need.

[dembovvski]

@Jairooh the policy gate in AgentLedger is pre-execution enforcement: the agent cannot proceed if the gate denies, and the DENIED receipt is cryptographically signed and written to the chain before the error is raised — it cannot be suppressed. The audit trail is tamper-evident by construction (Ed25519 + SHA-256 hash chain), verifiable by an independent third party without trusting the operator.

Happy to compare specifics if AgentShield has a published audit trail format — interoperability across enforcement layers is the right direction for regulated environments.

[wfel87]

This is exactly the right ask. The gap most teams hit is that logging what an agent did is not the same as proving the decision was governed before execution. A post-hoc log can be fabricated or reconstructed. The meaningful artifact is a signed record created at the policy decision point before the agent acts with the deny/allow outcome, the policy evaluated, and a verifiable chain that auditors can replay. The tricky layer is making this work across folders or scoped memory boundaries without the governance logic sitting inside agent code (which defeats the purpose). Would it be useful if I shared a reference architecture for how pre-execution signing can be separated from the agent framework itself?

[arian-gogani]

@wfel87 happy to share the reference architecture — this is what nobulex implements, and the pre-execution signing layer sits explicitly outside the agent framework so the governance logic cannot be bypassed by the agent.

Three components:

1. Pre-execution signing service (separate process from the agent runtime). Receives the proposed action + the policy snapshot + the delegation chain. Signs an Ed25519 attestation over JCS-canonical bytes (RFC 8785) committing to that exact tuple at dispatch time. Returns the signature; agent cannot proceed without it.

2. Post-execution binding. After the agent completes the action, a second Ed25519 signature binds the actual result to the pre-execution commitment. The two signatures hash-chain via the previous receipt digest, which is what makes the trail tamper-evident — flipping a single receipt invalidates every receipt downstream.

3. External verifier. Anyone holding the public key replays the chain without trusting the operator. No log file written by the same system that ran the agent counts as proof; the same system can rewrite the log.

The pre/post split is what catches the cases I flagged on Microsoft AGT #276 — approval context drift, inherited OAuth scope, MCP capability vs action-level authorization, policy version replay. If anything in the authorization context changed between approval and dispatch, the signatures fail to compose and the audit trail surfaces the gap.

Happens to be sitting at exactly the convergence the langchain RFC #35691 is circling. Five reference implementations on the same JCS+Ed25519 substrate as of last week (AgentGraph, APS, AgentID, HiveTrust, Nobulex). Apr 30 cross-implementation interop test verifies byte-identical canonical JSON across TypeScript and Python — verified 10/10 byte-match against APS this morning at in-toto/attestation#549 (comment).

The bilateral receipt primitive merged into Microsoft Agent Governance Toolkit last week (PR #1333) so the pattern is now in production at one major framework. CrewAI integration is straightforward — the signing service hooks at the task-dispatch boundary, no changes to crew or agent code. Happy to walk through the integration shape if useful.

Repo: https://github.com/arian-gogani/nobulex

[wfel87]

@arian-gogani Does this architecture produce an enforcement decision that blocks execution, or does it produce a receipt that documents what was permitted? Which problem are these implementations solving?

[arian-gogani]

both, but they are separable and worth distinguishing.

the pre-execution signature is the enforcement gate. the signing service refuses to issue a signature if the proposed action falls outside policy at dispatch time. no signature, no execution, agent halts. that is the blocking decision.

the post-execution signature plus the hash chain is the documentation. after a permitted action runs, the second signature binds the actual result and chains forward. that is what third parties verify.

the reason both matter together: an enforcement gate alone tells you what was permitted but not what actually happened (agents can drift between permission and execution). a chain of receipts alone tells you what happened but not whether the system would have caught a violation in time. the bilateral shape gives you both axes from one primitive.

if a deployment only needs one of the two, the architecture decomposes cleanly. the signing service can run as a pure policy enforcement point with no chain. the chain can run independently as a reputation primitive. most regulated deployments end up wanting both because compliance teams want to verify the gate fired correctly AND that nothing drifted between permission and execution.

[wfel87]

@arian-gogani The drift framing is the honest part of this. Pre-execution signature says ‘this was permitted.’ Post-execution chain says ‘this is what ran.’ The gap between those two statements is where regulated deployments get into trouble. A bilateral receipt architecture documents the gap after the fact. What’s the path from bilateral receipts to that bar?

[arian-gogani]

the path is the same primitive used differently. the receipt chain documents the gap after the fact. the pre-execution signature is the prevention layer.

the signing service refuses to issue a signature unless the proposed action satisfies policy at dispatch time, with the current delegation chain, current OAuth scope, and current evidence state. no signature, no execution.

what bilateral receipts add over a pure enforcement gate is verifiable evidence that the gate fired correctly. a pure policy enforcement point can fail silently or be tampered with by the operator. a signed pre-execution attestation that any third party can verify means a regulator or auditor can confirm the gate worked, not just that the operator says it worked.

for prevention specifically, the decomposition matters. if you only need to block bad actions, run the signing service alone with no chain. if you need to prove to a regulator that you blocked them, the chain proves the absence of unauthorized signatures during the audit window, which is itself evidence the gate was operating correctly.

the bar past documentation is independently verifiable enforcement. that is the property bilateral receipts give you that a logged enforcement decision cannot.

[alex-pathcourse]

When a crew collaborates on a task, there's no way to prove which agent did what or under what rules — exactly the gap your issue describes. PCH's per-agent identity and cryptographic audit receipts slot into CrewAI crews without you building compliance infrastructure from scratch.

Working example: https://github.com/pathcourse-health/pch-integration-examples#crewai

[srotzin]

The pre-execution-signature-as-enforcement vs post-execution-chain-as-documentation distinction in this thread is exactly right, and the drift framing @arian-gogani drew is the honest part. Worth pinning down one more piece because it's where most implementations of this pattern fail audit:

The pre-execution signature only carries enforcement weight if the bytes being signed include the policy state at decision time, not just the proposed action. A signing service that signs (action, delegation_chain, OAuth_scope, evidence_state) but omits policy_hash will happily issue a valid signature against a stale cached policy — the agent halts when the gate fires, but the gate fires against last-revision rules. The receipt looks tamper-evident; the authorization underneath was already revoked.

The fix is binding policy_hash and policy_eval_ts into the canonical signed bytes alongside the action and delegation chain. RFC 8785 (JCS) over that full tuple, Ed25519 signature over the canonical hash. Now the verifier can replay: pull the policy at policy_eval_ts, recompute the hash, confirm the signature was over the policy version actually in force at dispatch.

For per-agent covenants in a CrewAI handoff, this means each agent's receipt carries its own policy_hash (the covenant in force at that agent's signing moment), and the cross-agent reference chain links handoff receipts so an auditor can walk Researcher → Writer and see whether each covenant was current at its evaluation time, not just whether the chain is intact.

A free reference instance with the receipt schema (action + delegation + policy_hash + canonical bytes + signature + regulation_refs) is live at POST https://hivemorph.onrender.com/v1/audit/readiness — useful as a contract test for any covenant implementation.

IMHO the coordination layer should expose policy_hash as a first-class field on the public covenant interface, not as opaque metadata. If it's metadata, two CrewAI integrations will canonicalize differently and verifier interop breaks.

Thanks,
Steve

[wfel87]

@srotzin The point about stale policy is the critical one. A signature over  (action, delegation_chain, scope)  without the policy version in force at evaluation time is not an audit artifact but, it is a log entry with a wax seal. It proves the bytes were signed. It does not prove the authorization was current.

For per-agent covenants in a CrewAI handoff, this compounds: each agent in the chain may have been evaluated against a different policy revision if policies updated mid-run. A chain where every receipt is individually valid but the policy versions don’t form a consistent sequence is not auditable at the crew level.

The fix you described binding  policy_hash and policy_eval_ts  into the canonical signed bytes so a verifier can replay the policy state at each evaluation moment — is exactly the architecture that makes per-agent covenants hold across a full crew run.

We’ve built this at the enforcement layer. Each evaluation signs the policy version in force at that exact moment, and the cross-agent reference chain links handoff receipts so an auditor can walk the full crew sequence and verify policy currency at every hop not just signature integrity.

Happy to share how we handle the per-hop policy version binding if it’s useful to this thread.