A shared MCP memory server is now a common organ for multi-agent systems. It stores what agents believe. Belief is not evidence. When Agent B retrieves a vector from that server, it cannot tell whether the content came from a real observation, a hallucinated summary, or an artifact planted by a compromised peer. In a multi-agent deployment, the audit log is not a post-mortem report. It is the only court — and it must enforce law at runtime, not after the blast radius has propagated.
The crisis: memory as a contagion vector
One poisoned memory read does not stay contained. Agent B acts on it, writes new memory, Agent C reads that. Each hop makes the corruption look more legitimate. Cosine similarity will not save you. The forcing function is governance as code: make the ledger a prerequisite for every memory-related tool call.
Mechanism 1: Signed append-only tool log
Wrap every MCP tool call with a recording layer that captures: agent_id, session_id, tool_name, input_hash, output_ref, a hybrid logical clock — never wall time — and parent_entry_hash. Append entries into a Merkle DAG whose root is signed by a key held outside the agent runtime, e.g., a vault sidecar. The operating rule: no write is committed to the shared memory store unless its value references a gov:entry_id; no entry is accepted without a valid parent_entry_hash back to the previous signed root.
json
{
"gov:entry_id": "3f9a...e1",
"agent_id": "agent-b",
"tool_name": "memory_write",
"input_hash": "sha256:1a2b...",
"output_ref": "blob:4c5d...",
"hlc": "2025-01-10T14:22:01.000+05:00",
"parent_entry_hash": "sha256:9d8e..."
}
---
#maref #ai #opensource #machinelearning
<script async src="http://localhost:3001/script.js" data-website-id="30b552af-b93c-4bbb-855c-b10b45efaa52"></script>
<img src="http://localhost:3001/api/send?website_id=30b552af-b93c-4bbb-855c-b10b45efaa52&platform=devto" height="1" width="1" style="display:none" alt=""/>
Top comments (0)