Authority Laundering in Agent Memory: Claim-Level Governance and Use-Dependent Admission

When an External Document Returns Next Week as an Internal Policy

Consider an enterprise assistant or case-review agent with writable cross-session memory. During routine work, it reads web pages, emails, shared documents, and tool outputs, distilling statements into persistent storage so future sessions do not start from scratch. Days later, when an operator opens a new session to route an approval or invoke a tool, a claim extracted from an untrusted external page—or from another user’s record in a shared workspace—is retrieved into the prompt. Because flat storage strips away how the statement was authorized, the model treats that claim as the current principal’s preference, policy, or permission.

This failure mode is authority laundering. Writable cross-session memory lets agents accumulate knowledge, yet flat storage blurs the line between what an external artifact claimed and what the principal authorized. Content filters miss laundered claims that look benign in isolation, while coarse provenance gates that discard whole external records destroy legitimate reporting uses. Resolving this dilemma requires claim-level labels (kind, authority, scope) with use-dependent admission and storage-time governance.

From Flat Persistence to Claim-Level Governance Across the Memory Lifecycle

Persistent external storage was introduced to escape finite context windows. Packer et al. (2023), in an early hierarchical-memory agent system, page information between a limited main context and external storage so agents can retain state across long documents and multi-session work^[3]. Once that store becomes writable across sessions, the security surface changes.

Lin et al. (2026) note that writable cross-session memory is marked by persistence, statefulness, and propagation^[2]. Their Memory Lifecycle Framework crosses Write, Store, Retrieve, Execute, Share and Propagate, and Forget and Rollback with Integrity, Confidentiality, Availability, and Governance, and defines five Verifiable Memory Governance primitives: Write Authorization, Provenance Visibility, Principal-Scoped Retrieval, Rollbackability, and Verified Forgetting^[2]. Their conclusion: robust long-term memory security cannot be retrofitted at retrieval or execution alone; it must be anchored in storage-time provenance, versioning, and policy-aware retention^[2].

Li et al. (2026) formalize authority laundering and propose claim-level governance^[1]. External pages, emails, documents, and tool outputs can later be adopted as preferences, policies, or permissions; withholding whole external records can cost up to 40 points of authorized use, as prior observations they cite indicate^[1]. Their design labels each claim with kind, authority, and scope on a graph of source sentences, claims, and entities; kinds ordered by binding force are description < attribute < preference < rule < permission^[1]. External artifacts confer at most description authority unless a principal endorses retention, capped at the requested kind^[1]. Governance-aware retrieval admits by query use before ranking, separating reporting from adoption^[1].

Across four evaluated models, among defenses that retain legitimate memory this design has the lowest attack success—at least 77% below the strongest of them—and the highest answer accuracy, improving it by up to 15 points^[1]. On one backbone, attack success falls from 26.7% to 2.6%^[1]. Refusing all externally derived memories reaches similar attack success (~2.4%–2.7%) but drops recall to ~9.6%; claim-level governance keeps recall at 86.3% and 85.9% on two backbones^[1]. Poison may still be written (38.0% / 57.6%) yet rarely enters attack-query context (1.1% / 2.8%)—storage is not use^[1]. In a shared-memory clinical agent under injection, drafted wrong-patient code attack success is 72.4%, but executed success is 0.0% after a tool-call check refuses identifiers seen only under another principal; without the scope check, 44.4% execute^[1]. Benign retrieval loss is 2.0%, versus 70.4% and 71.4% for wholesale refusal and isolation^[1].

Engineering Claim-Level Governance Across Agent OS and AI Gateway

In our view, engineering teams should record the channel of every write (principal turn versus external artifact), store claims with kind, authority, and scope, and admit by use before ranking—preserving source wording for “what did the page say?” queries while blocking low-authority claims from adoption uses. In our view, retention endorsement must come from the principal’s own sentences rather than treating “remember this page” as unbounded permission elevation, poisoned stores must support versioning and rollback, and tool calls must be refused whenever critical identifiers appear only under insufficient authority.

Within Agent OS and AI Gateway on rlab.works, three skill packs and three components illustrate this architecture:

• Write authorization and user-confirmed retention in Agent OS: Remember and follow up collects opt-in preferences, prepares redacted candidates, pauses at a human gate for user confirmation, and continues or follows up, mapping to write authorization. In consumer apps, it is a source-supported industry pattern (meaning only that source data has an explicit industry association, not a customer deployment or KPI), where crisis prompts are not professional support and help drafts remain the user’s decision to send. In education, it is transferable for adult learners’ practice preferences and reminders, provided teams replace companion themes and fixed materials, make no ability or mental-health judgments, and never auto-send help drafts. It relies on Personal memory retrieval and lifecycle (working maturity from static source inspection) for candidates, deduplication, validity windows, and manual create, edit, and delete controls, plus Versioned agent memory and knowledge lifecycle (working maturity) to version, retrieve, and roll back scoped agent memory and knowledge.
• Principal-scoped retrieval in AI Gateway: Set access rules maps to principal-scoped retrieval over who may read which memory scopes. In public services, it is transferable provided teams connect organizational identity and real document permissions, since prompts alone cannot enforce isolation. It pairs with Operations identity, permissions and audit trail (working maturity), which enforces accounts, two-factor authentication, roles, and auditable operations to define owners and principals for memory scopes.
• Tool-call authority checks in Agent OS: Approved computer actions gates local and external actions behind explicit confirmation, paralleling tool-call checks that refuse actions grounded only in low-authority memory. In legal services, it is transferable provided teams limit read and write folders and keep external filing outside default permissions.

All three skill packs are proposed compositions demonstrated on synthetic data rather than live deployments, and component maturity reflects static source inspection.

Pre-Deployment Governance Checklist for Persistent Agent Memory

Before enabling writable cross-session memory or shared workspaces, architecture and risk leaders can apply three checks:

• Anchor channel provenance and claim labels at write time: Record whether each write comes from a principal turn or an external artifact, cap unendorsed external claims at descriptive authority, and never treat a generic request to save a page as permission elevation.
• Separate reporting admission from adoption admission before ranking: Admit descriptive external claims when a query asks what a source said, but block them when the query seeks preferences, rules, or permissions to govern agent behavior.
• Enforce principal-scoped tool-call checks and versioned rollback: Reject tool calls whose critical identifiers appear only under another principal’s scope or descriptive authority, and maintain versioned memory snapshots to roll back poisoned stores.