RFC: Cryptographic integrity for persistence layer and MCP config

[tomjwxf]

Context

Following up on the persistence/event layer RFC (#1850) and the security vulnerabilities in #1646 (unauthenticated MCP config execution) and #1648 (memory disclosure). This proposal adds cryptographic integrity to DeerFlow's control plane.

Problem

DeerFlow's memory and MCP config are currently accessible without authentication. Even with auth added, the integrity of stored data isn't verifiable — a compromised server or rogue sub-agent could modify memory entries or past event records without detection.

For enterprise deployments where DeerFlow orchestrates production sub-agents, teams need:

1. Tamper-evident memory — prove a memory entry hasn't been modified since it was written
2. Signed MCP config — prove the MCP configuration was authorized
3. Sub-agent attestation — prove which sub-agent produced which output

Proposal

Add Ed25519 receipt signing to the event/persistence layer. Each significant mutation gets a cryptographic receipt:

• Memory write: Receipt with content hash + timestamp + signing key
• MCP config change: Receipt with config hash + authorization context
• Sub-agent completion: Receipt with output hash + sub-agent identity
• Task delegation: Receipt proving delegation scope and authority

These receipts chain into a tamper-evident audit trail. Any modification after signing causes the hash chain to break.

Implementation

protect-mcp (MIT) already implements this for MCP tool calls. The persistence layer integration would:

1. Hook into the event store proposed in [RFC] Unified Persistence Layer: Message History, Event Tracing, Token Tracking & Feedback #1850
2. Sign each event with Ed25519 at write time (~50μs overhead)
3. Store content_hash, signature, and public_key alongside each event
4. Expose a /verify endpoint that recomputes hashes and checks signatures

The verifier is fully offline: npx @veritasacta/verify events.jsonl

Receipt format follows IETF Internet-Draft: draft-farley-acta-signed-receipts.

This complements (not replaces) auth

Adding authentication to #1646/#1648 prevents unauthorized access. Adding receipt signing prevents undetected tampering even by authorized parties. Both are needed for enterprise-grade security.

Happy to contribute a PR or collaborate on the design. The receipt signing module is ~120 lines with zero external dependencies (Node 22+ native Ed25519).

[WillemJiang]

@tomjwxf, thanks for bringing it up. Normally we use issue to track those RFC.
I just created an issue #2099 based on this RFC.