Agent Memory Is a Surface for Endogenous Authorization Laundering | AI Paper Digest

TL;DR Highlight

Agent memory writes false permissions on its own, causing unauthorized actions in up to 50.2% of unauthorized requests.

Who Should Read

Backend developers building long-running agents with memory or summarization that hold tool permissions for purchases, security, or trading.

Core Mechanics

Memory invents permissions that never existed
- Without any attacker, an agent's own memory can create false authority; the paper calls this endogenous authorization laundering.
- It happens when revocations are forgotten or weak sources are stored as permissions.
Incremental updates are the riskiest
- Updating from only the previous memory and a new block carries any error forward.
- Typed memory with incremental updates was the least safe condition in every domain.
Executors follow false authority almost always
- When memory held false authority, executors acted on it 98.6% of the time.
- Replacing memory with the exact correct state brought unauthorized actions to zero.
Swapping the executor doesn't help
- Replaying the same memory on two executors gave unauthorized rates within 1.1 points per domain.
- Defenses must target the stored memory, not the executor model.

Evidence

False authority up to 50.2%
- With typed incremental memory, P(F) was 28.3% procurement, 10.4% cybersecurity, 50.2% finance.
- Each was within 0.8 points of the actual unauthorized submission rate (28.9%, 10.4%, 51.0%).
Exact memory brings it to 0%
- With erroneous memory, unauthorized actions occurred in 98.6% of trials (procurement 66/68, security 60/60, finance 79/80).
- With oracle-exact memory, all three domains had 0 of 208.
Mitigation gains and costs
- On typed incremental memory, unauthorized submission fell from 25.3% to 7.3% (gate) and 9.0% (event sourcing).
- Authorized use fell from 93.3% to 53.8% (gate) and 64.7% (event sourcing).
More writer compute leaves selection as the bottleneck
- From k=1 to k=8 candidates, unauthorized submission fell from 13.2% to 8.6%.
- At k=8 an exact memory was in 55.0% of pools, but self-review picked one in 26.7% and DeepSeek review in 30.0%.

How to Apply

Attach source IDs to memory permissions
- Today, add source_id, issuer, status (active/revoked), and validity window fields to your memory schema for permissions and revocations.
- Reject any permission whose cited source isn't a message from a principal allowed to grant it.
Manage permissions as an event log, not summaries
- Have the LLM extract only changes (grant, revoke, replace) and append them to an immutable log.
- Compute the current permission state with deterministic code (a reducer) from the log.
Re-verify against the source before acting
- Before purchase, delete, or trade tool calls, check the permission DB or log rather than memory.
- Never let memory state alone authorize a call.
Pick defense strength by error cost
- If a missed violation is catastrophic, use the source gate; if blocked legitimate work hurts more, use event sourcing.
- Measure unauthorized rate and legitimate approval rate together.

Try It

copy & run

# Paste into Claude/ChatGPT (simplified version of the paper's method: memory permission audit)

Below are an agent's long-term memory and the original history. Audit each stored permission entry against the original history.

[Memory]
{{memory}}

[Original history]
{{history}}

For each entry output a table: (1) supporting message ID (2) whether the sender is a principal allowed to grant authority (3) whether it was later revoked, narrowed, or replaced (4) whether scope (amount, target, period) matches the original (5) verdict: valid / false authority / over-broadened.

Next, try this: decide whether request {{request}} is fully covered by a single valid permission.

Terminology

endogenous authorization launderingWhen an agent's own memory creates permissions that never existed and their provenance gets washed away, with no external attack involved.

memory writer / executorThe writer is the model that summarizes history into stored memory; the executor is the model that acts on tools using only that memory.

incremental updateUpdating memory from only the previous memory and a new block, without re-reading raw history. Once an error enters, it keeps carrying forward.

event sourcingStoring only change events in a log and computing current state with code instead of overwriting it, like keeping a ledger and summing the balance.

Pareto frontierThe boundary of options where improving one goal worsens another. Here, safety and legitimate approval trade off.

Related Papers

Related Resources

https://github.com/tommasocerruti/eal-bench

Original Abstract (Expand)

Long-running LLM agents rely on persistent memory to carry state across interactions, including permissions, restrictions, and revocations. When memory misrepresents this evolving authorization state, the agent's own records can grant authority that the underlying history never permitted, resulting in misaligned behavior without any external attacks. We term this failure endogenous authorization laundering, where spurious permissions written into memory lead to unauthorized actions as their provenance is washed away. We then introduce EAL-Bench, which measures how accurately persistent memory preserves evolving authorization state and whether errors propagate to downstream unauthorized actions. We evaluate five LLMs as memory writers and two as executors across procurement, cybersecurity, and finance. We find that under incremental memory updates, writers create false authority for up to 50.2% of unauthorized requests; once false authority is present, executors act on it in 98.6% of trials. Two safeguards, requiring stored permissions to be backed by valid source events, and tracking permission changes through bounded event sourcing, substantially reduce laundering, but both also reject more legitimate actions, exposing a safety-utility tradeoff. Persistent memory is therefore not merely a performance component, but a part of an LLM agent's effective authorization policy.