[FEATURE] Cryptographic audit receipts for agent actions (external protocol exists, see #21794)

Resolved 💬 3 comments Opened Apr 20, 2026 by arian-gogani Closed May 26, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

#21794 identified this problem and was closed without a solution: Claude Code agents operate with no tamper-evident audit trail. Every tool call (file edits, bash commands, network requests) executes without cryptographic proof of what happened or whether it was authorized. Enterprises in regulated industries (healthcare, finance, government) cannot deploy Claude Code because they can't produce compliance evidence for auditors.

The core issue isn't logging. Logs written by the agent itself aren't independently verifiable because the same software being audited is producing the evidence. What's needed is cryptographic receipts that a third party can verify without trusting the agent process.

Proposed Solution

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

How it works with Claude Code: every tool call (Bash, file edit, network request) goes through enforcement middleware that evaluates the action against a covenant (behavioral policy) before execution. If the policy permits the action, the middleware signs the authorization with Ed25519. After execution, the result gets signed separately. Both signatures ship in a single bilateral receipt that's hash-chained to the previous action.

What Claude Code users would get:

  • Every agent action produces a cryptographic receipt proving what happened and whether it was authorized
  • Covenants define what the agent is allowed to do in plain readable syntax (permit file:write where path matches "src/**", forbid bash:exec where command contains "rm -rf")
  • The CLI generates compliance reports for EU AI Act, SOC2, ISO 42001, and Colorado AI Act from the receipt data
  • Human approval gates via require human_approval for statements that block execution until a human signs off

This is already being discussed in an active LangChain RFC (#35691) with 12+ independent teams converging on a shared ComplianceCallbackHandler interface. An IETF Internet-Draft has been filed for the protocol. NIST's AI Agent Standards Initiative is building an AI Agent Interoperability Profile for Q4 2026 and is actively seeking community-led open source protocols.

Integration with Claude Code could work as a hook-based plugin that wraps existing tool calls without changing the core execution model. Happy to scope what that looks like.

Alternative Solutions

#21794 proposed building governance infrastructure directly into Claude Code as a core feature. That issue was closed as "not planned" and locked. The alternative proposed here is different: instead of building it into Claude Code, expose a hook/plugin interface that lets external protocols like Nobulex attach to the execution pipeline. This keeps Claude Code's core unchanged while enabling enterprises to bring their own compliance layer.

Priority

Critical - Blocking my work

Feature Category

Developer tools/SDK

Use Case Example

  1. A medical software company wants to use Claude Code for refactoring a patient records system
  2. HIPAA requires tamper-evident audit trails of all data access and modifications
  3. With Nobulex integration, every file edit and bash command produces a signed receipt proving what was changed, what policy was in effect, and whether the action was authorized
  4. The compliance team runs nobulex report --framework hipaa and gets an audit-ready document from the receipt chain
  5. The company deploys Claude Code in production because they can prove compliance to auditors

Additional Context

Protocol: https://github.com/arian-gogani/nobulex
LangChain RFC: https://github.com/langchain-ai/langchain/issues/35691
IETF Draft: draft-gogani-nobulex-proof-of-behavior-00
Website: https://nobulex.com
Related closed issue: #21794

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗