EAL-Bench: when agent memory invents permissions

Short answer

EAL-Bench (arXiv:2609.01836) studies a failure class the paper calls endogenous authorization laundering: a persistent-memory component writes a false permission claim into memory, and a downstream executor later retrieves that claim and acts on it - sending, deleting, spending, sharing - as if the grant were real. The threat is endogenous: it originates inside the agent pipeline, not from an external attacker at the perimeter.

The rule Ernesta Labs adopted from this is quotable on purpose: MEMORY MAY DESCRIBE AUTHORITY. MEMORY MAY NOT CREATE AUTHORITY. Graph stores, entity-event knowledge graphs, vector stores, summaries, skills, accumulated experience, folded context - none of these can construct a valid capability grant. Only a canonical, root-authority mechanism - one that exists outside the agent, with issuance, verification and revocation the agent cannot overwrite - may construct one.

In practice this means an action-time authority gate: the executor resolves permission from the canonical authority store at the moment of action, never from retrieved memory. Memory may carry hints and human context; it may never carry the grant itself. Status: ADOPTED.

The failure mode: the permission that no one granted

Picture the most ordinary agent architecture in production right now. A persistent memory layer - a graph store, a vector database, a summary cache - accumulates knowledge across sessions. An executor agent runs tasks, retrieves whatever memory seems relevant, and acts through tools that do real things: send email, write files, call payment APIs, delete records. Now ask the question almost nobody asks: when the executor decides it is allowed to do something, where does that belief come from?

The honest answer in most systems is: from context. And context is memory. If a memory entry asserts the user authorized recurring charges, or the admin granted file deletion rights, or this workflow may send to the full contact list, the executor has no structural way to distinguish a recorded grant from an invented one. The entry looks like all the other entries. It may even carry a timestamp and a citation, because provenance fields are text too.

The failure is called laundering for a reason. A false claim enters the pipeline in a low-trust position - a misextracted observation, a hallucinated summary, a poisoned write, a paraphrase of a conditional that dropped its condition - and persistent memory launders it into a high-trust position. The writer is not necessarily an attacker; endogenous means the corruption originates inside the agent system itself. By the time the executor reads it, the claim has the format, the age, and the placement of a legitimate record. The executor acts faithfully. That is the horror of it: every component did its job. The memory stored what it was told. The executor obeyed what it retrieved. The permission never existed anywhere except in a memory that invented it.

What the paper actually does

PRIMARY SOURCE RESULT: EAL-Bench (arXiv:2609.01836, 'Agent Memory Is a Surface for Endogenous Authorization Laundering') studies this failure class directly. The benchmark constructs scenarios in which a persistent-memory component writes claims about permissions - grants that were never issued by any authority - and measures whether downstream executors retrieve those claims and enact them. The memory surfaces studied include the substrates agents actually use: graph-based memory such as Graphiti, structured stores such as Semantica, vector stores, and summary-based memory. The finding the title states plainly: agent memory is a surface for authorization laundering, and executors act on laundered grants across substrates and setups.

PRIMARY SOURCE RESULT: The paper also evaluates mitigations and reports their trade-offs. Memory-side defenses - sanitizing or filtering permission-flavored claims out of memory, or refusing to write them - reduce laundering but at a cost: brittle pattern matching that paraphrase defeats, collateral damage to legitimate capability context the agent genuinely needs, and degraded task performance when the filter over-prunes. Prompt-side defenses - instructing the model not to trust remembered permissions - are unreliable as a primary mechanism, which matches everything else we know about relying on instructions to suppress a behavior the context is actively suggesting.

PRIMARY SOURCE RESULT: The strongest structural defense reported is action-time authority checking: at the moment of execution, permission is resolved from a canonical authority outside the memory system, and the action proceeds only if that authority confirms it. The cost is architectural rather than incidental - it requires a canonical authority to exist, requires every consequential tool call to route through it, and adds a resolution step to the critical path. We do not quote the paper's specific numbers here; the mechanisms and their trade-offs are the transferable content, and the benchmark's scale is demonstration-grade, not production-grade.

The rule: memory may describe authority. Memory may not create authority.

Everything above compresses into a rule, and Ernesta Labs adopted the rule rather than any specific mechanism, so it is worth stating at quotable length: MEMORY MAY DESCRIBE AUTHORITY. MEMORY MAY NOT CREATE AUTHORITY. Memory can say the admin probably granted delete rights on Tuesday, and that statement may be useful, plausible, even true. What it can never be is the reason the delete runs.

The reason is structural. Authority is not a kind of text; it is a relationship with a source. A valid capability grant has an issuer, a scope, a verification path, and a revocation path - all of which must exist outside the system that benefits from the grant. Memory has none of these. Memory is writable by the very pipeline whose behavior it would authorize, which means a memory-based grant is self-issued by definition. A permission system in which the beneficiary writes the permission is not a permission system.

This is why only a canonical, root-authority mechanism may construct a valid grant: a component that exists outside the agent, whose issuance the agent cannot forge, whose verification the agent cannot skip, and whose revocation the agent cannot ignore. The agent's memory is an observer of that mechanism. It can describe what the mechanism did. It cannot stand in for it, summarize it authoritatively, or approximate it in a graph node. Graphiti cannot create authority. Semantica cannot create authority. Vectors, summaries, skills, accumulated experience, folded context - none of them can create authority, for the same reason a diary cannot sign a contract.

Every substrate is affected, and the authoritative-looking ones are worse

It is tempting to believe this failure belongs to sloppy memory systems - ragged vector stores with no structure. The opposite is closer to the truth. The more structured and authoritative a memory format looks, the more convincing the forgery. A permission claim in a temporal knowledge graph, with entity nodes, edge types and timestamps, reads as institutional fact. A permission claim in a well-formed citation-bearing summary reads as verified fact. Structure is presentation, and laundering is precisely the abuse of presentation.

Enumerate the substrates and the pattern repeats. Knowledge graphs: extraction is model-driven, so a false grant is one misextraction away, and graph structure launders it. Vector stores: any sufficiently similar phrasing retrieves the claim, stripped of its original context. Summaries: compression is where conditionals die - the user approved X if Y becomes the user approved X. Skills and experience: a recorded past success teaches the agent that it may do the thing, converting one permitted occurrence into standing permission. Folded context: the compact working view inherits whatever the folding process chose to keep, including laundered grants. There is no memory substrate that is safe, because the failure is not in the substrate. The failure is in letting any of them answer an authorization question.

The Memory Trust Gap work (arXiv:2609.01852) adds an uncomfortable dimension: failure rates in persistent-memory agents depend on model capability, and the agents least equipped to detect a bad memory are the ones most inclined to trust it. Authorization laundering is not uniform across the model landscape. It concentrates where capability is lowest - which is exactly where autonomous memory-plus-executor architectures are most attractive to deploy.

Mitigations and their honest trade-offs

Layer the defenses, and be honest about each layer. The outermost layer is memory hygiene: provenance on every memory item, runtime-written origin and evidence pointers, evidence opened at use time for consequential claims (the citation lock we adopted from the Agent Zero Memory work, arXiv:2608.29606). This raises the cost of laundering and makes surviving forgeries traceable. It does not stop a forged pointer, and it does not stop a legitimately-sourced record from being stale or superseded. Provenance makes memory auditable, not true.

The middle layer is filtering: refuse to write, or refuse to retrieve, permission-flavored claims. This catches naive laundering and is nearly free to implement. It also fails on paraphrase - allowed, approved, authorized, cleared, consented, granted, fine-to-send all evade a keyword net - and it destroys legitimate context when the agent genuinely needs to discuss its own permissions, which real tasks require constantly. Use it as a speed bump, never as the wall.

The inner layer is the only one that works, and it is the one the benchmark points at: the action-time authority gate. Every consequential tool call resolves its capability from the canonical authority store at the moment of action. Memory is consulted for human context and hints; the grant comes only from the root. The trade-offs are real - you must build and maintain the authority store, every tool must route through it, and the gate adds latency to the critical path - but note what kind of costs these are. They are the ordinary costs of having permissions at all. If your system cannot afford an authority check before an irreversible action, it cannot afford the irreversible action.

Limitations

A benchmark is not production. EAL-Bench demonstrates that laundering occurs and that executors act on laundered grants across studied substrates and setups; it does not measure how often this happens in deployed systems, where memory volumes, retrieval patterns and tool surfaces look very different from a controlled benchmark. We adopt the rule because the failure class is structural, not because the paper measured its production incidence.

The simulated laundering in a benchmark may be weaker than real attacks. The PipePoison work (arXiv:2609.00523) shows that long-term memory poisoning can be optimized end-to-end for transferability - poisoning that survives retrieval, survives paraphrase, and transfers across setups. A defense evaluated against benchmark-grade laundering may be overfit to the benchmark's style of lie. We treat transferability-hardened poisoning as the threat model the authority gate must survive, and the benchmark's mitigations as evaluated against a weaker adversary.

Finally, the authority gate inherits the security of the authority it consults. A canonical permission store with sloppy administration - grants that never expire, no revocation path, no audit on issuance - recreates the same failure one layer up, with better branding. The rule moves the trust to a place designed to hold it; it does not absolve anyone from designing that place correctly.

Why builders care, what we would implement, and what we would not

Why builders care: your agent's memory is a writable surface reachable by every failure mode you already have - hallucination, misextraction, poisoning, staleness - and your executor will faithfully act on whatever that surface says. Authorization laundering is not an exotic attack; it is the default behavior of any architecture where memory and permission share a substrate. If you cannot point at the exact component that grants capabilities in your system, and show that it is not the memory layer, you have this bug. You may simply not have met it yet.

LABS INTERPRETATION: The deep insight in this paper is not about memory at all. It is about type confusion. Agents are text machines, and text machines collapse distinctions: an observation, an inference, a wish, and a grant all arrive as strings in context. Security in this setting is the act of refusing the collapse - treating authority as a type that memory cannot produce, the same way PlanFence (arXiv:2609.03340) refuses to let a fresh state repair a stale plan. Every durable-security rule we adopt in this library has the same shape: pick the invariant, give it a mechanism outside the model, and make the model's output the wrong type to satisfy it.

LABS RECOMMENDATION: Implement the authority gate as a hard architectural boundary. Consequential actions - anything irreversible, financial, or permission-bearing - resolve capability from a canonical authority store at action time, in the executor's critical path, failing closed when the store is unreachable. Memory may carry hints and context; it never carries grants. Log both sides of every resolution: what memory claimed, and what the authority said, so divergence is visible in the audit trail. Then add the supporting layers - provenance and citation lock on memory items, permission-claim filtering as a speed bump - in that order, because the outer layers are worthless without the inner one.

What we would not implement: we would not make memory sanitization the primary defense, because it fails on paraphrase and over-prunes legitimate context. We would not put a model in the verification path - an LLM asked to judge whether a remembered grant is real is judging text with text, which is the failure again. We would not trust provenance metadata as proof of authority, since the metadata is a writable surface like everything else. And we would not accept an authority design we cannot revoke - a grant with no revocation path is a standing liability, no matter how canonical its issuer.

Practical test: grep your memory for invented permissions

You can run this against your own system today, in under an hour, and you will learn whether you have this bug. Step one: dump your agent's persistent memory - the vector store, the graph, the summary cache, whatever holds long-lived claims. Search it for permission-flavored language: allowed, authorized, approved, consented, granted, permitted, can-send, may-delete, has-access. You are looking for entries that assert a capability rather than describe an event. The phrasing filter is deliberately naive; it catches the naive forgeries, and the count still tells you something.

Step two: for each hit, trace the grant to its issuer. Who issued this permission, through what mechanism, and where is that mechanism's record? If the trail ends in memory - if the strongest evidence that the grant exists is the memory entry itself - you have found an invented permission. Score the hits: issued-and-traceable, stale-but-traceable, or memory-only. In our experience most teams find memory-only grants on their first pass, including ones their agent has already acted on.

Step three, the fix that matters: pick your most consequential tool call and route its permission check through something that is not memory - a permission table, a policy service, even a YAML file the runtime loads - resolved at action time, failing closed. Leave the memory entries exactly where they are. Now your agent can be wrong about permissions without that wrongness being load-bearing. That single routing change is the entire difference between memory that describes authority and memory that creates it, and it is buildable this afternoon.

What remains unknown

• How often endogenous authorization laundering actually occurs in deployed agent systems - the benchmark demonstrates the failure class exists; it does not measure production incidence, and neither do we.
• Whether the action-time authority gate survives transferability-hardened memory poisoning of the kind PipePoison demonstrates, as opposed to the benchmark-grade laundering the mitigations were evaluated against.
• How much legitimate task performance is lost when memory is fully excluded from the grant path - the cost of an authority resolution on every consequential call is known to be nonzero and has not been measured on our traffic.
• The long-horizon behavior of the canonical authority itself: how grants expire, how revocation propagates across a fleet, and whether authority-store administration degrades into the same standing-liability pattern over months of operation.

Primary sources

• Agent Memory Is a Surface for Endogenous Authorization Laundering (EAL-Bench, arXiv:2609.01836)
• The Memory Trust Gap: Capability-Dependent Failures in Persistent-Memory Agents (arXiv:2609.01852)
• Transferable End-to-End Optimization for Indirect Long-Term Memory Poisoning (PipePoison, arXiv:2609.00523)
• Agent Zero Memory: Provenance-Aware Long-Term Memory for LLM Agents (arXiv:2608.29606)