Memory Provenance
The mechanism by which the gateway attaches signed chain-of-custody to every write to an agent's persistent memory, so subsequent reads can require verified provenance for high-stakes decisions. Memory provenance defeats memory poisoning (OWASP AGENT06) — the attack class in which false facts are written into an agent's persistent memory and acted on by later sessions as if verified. It is the fifth control in the IntentGate authorization pipeline and the only one that operates across sessions rather than within a single session.
Why memory provenance matters
Modern AI agents increasingly maintain persistent memory — a structured store of facts, preferences, prior decisions, and context that survives across sessions and is referenced by subsequent calls. The memory store is what lets an agent "remember" that customer Acme prefers email contact, that ticket #4421 was escalated, that the AP clerk's approval limit is €5,000. Memory makes agents useful but introduces a new attack surface: anything that can write to memory can plant false facts that future sessions will read as truth.
The attacker may be external (a prompt-injection payload that gets the agent to write a fact through a memory-write tool) or internal (a routine session that wrote a fact erroneously, which nobody noticed at the time). Either way, the agent reading the memory in a future session has no signal that the memory is poisoned. The OWASP AGENT06 (Memory & Context Poisoning) risk class captures this surface; OWASP LLM09 (Misinformation) covers the downstream consequence where the agent confidently produces wrong answers grounded in unverified memory.
How IntentGate implements memory provenance
On every write to an agent's persistent memory, the gateway computes an HMAC signature over the memory payload plus contextual metadata: the writing agent's identity, the writing session's intent, the capability token under which the write was authorized, and the timestamp. The signature and metadata are stored alongside the memory entry as its chain-of-custody. Memory written outside the gateway — through direct database access, for example — has no signature and is implicitly flagged as unverified.
On reads, the gateway can be configured to require verified provenance. The verification recomputes the HMAC and compares it to the stored signature; mismatch indicates tampering or origin from a non-gateway write path, and the read fails closed. The metadata is also returned so the agent (or the policy engine) can decide whether the writer's identity, intent, or token chain meets the bar for the current read context.
Selective enforcement on high-stakes reads
Provenance verification is opt-in per read path, not always-on. The reasoning: verification adds latency (typically 10–30 ms for the HMAC plus metadata lookup), and not every read warrants the check. A routine read of customer-preference data for a chatbot response does not. A read of an approval-limit fact that feeds into a transfer_funds decision does — that read should refuse to proceed against unverified memory.
Operators configure which read paths require verified provenance through the gateway's policy engine. The Rego rule for a high-stakes read looks like: require_verified_memory if input.tool == "transfer_funds" and input.memory_source == "approval_limits". The verification then becomes a check that runs before the call proceeds; if the memory's provenance is unverified, the call fails with −32014 and the audit chain records both the read failure and the underlying memory entry's metadata.
What memory provenance does not do
Memory provenance is not factuality verification. The gateway can prove that a memory entry was written by a specific agent under a specific intent — it cannot prove that the fact stored there is true. If the original writer was operating in good faith but had been deceived (by upstream prompt injection, by faulty external data, by user error), the provenance will verify and the false fact will be read as trusted. Factuality is a different problem, addressed by content-eval vendors (Patronus, Galileo, Arize) at a different layer.
Provenance also does not retroactively secure memory written before provenance was enabled. Legacy memory entries with no signature are treated as unverified; depending on operator configuration, they are either flagged for review or excluded from verified-read paths until they are re-asserted by a current authorized agent.
Error code and observability
Memory provenance failures return JSON-RPC error code −32014. The error payload includes the read context (which tool, which memory source), the memory entry's metadata (signed-by, signed-at, intent), and the verification outcome (signature-mismatch, no-signature, metadata-rejected). SIEM adapters route on the error code; operators build alerts for clusters of provenance failures, which usually indicate either an in-progress memory-poisoning attempt or a legacy-data migration issue.
Related controls
Memory provenance complements intent enforcement by extending the trust boundary into persistent storage: intent enforcement says "the agent must act on the user's declared intent," provenance says "the memory the agent reads must be traceable to authorized intent at write time." See the Agent Runtime Authorization category page for the full pipeline.
Frequently asked questions
What is memory poisoning and why does it matter?
Memory poisoning (OWASP AGENT06 in the Agentic AI list) is an attack in which false facts are written into an agent's persistent memory store, so later sessions read those facts and act on them as if verified. The attacker may be external (writing through a compromised tool) or internal (an earlier benign error). Without provenance, the agent has no way to tell verified memory from poisoned memory; with provenance, high-stakes reads can require a verified chain-of-custody before trusting the memory entry.
Is memory provenance always-on or opt-in?
Opt-in. Provenance verification adds latency to reads (typically 10–30 ms for the HMAC verification) and not every memory read warrants the check. Operators configure which read paths require verified provenance — typically the high-stakes ones — and leave routine reads ungoverned. The signing on writes is always-on; the verification on reads is selective.
How does this relate to traditional database integrity?
Traditional database integrity (referential constraints, transactional atomicity, schema validation) protects against malformed or inconsistent data. Memory provenance protects against semantically valid but factually false data — a perfectly well-formed memory entry that contains a lie planted by an earlier attacker. Database integrity is necessary but does not address the trust-of-content question; memory provenance does.