How should AI agents stop memory from authorizing risky tool calls in 2026?

Keep source provenance and confirmation as platform-maintained memory metadata, bind it to the proposed action's relevant arguments, and require authority appropriate to the action risk. A summary may preserve information; it must not become authorization merely by resembling trusted history.

A prompt-injection screen protects the context it sees now. The harder cross-task boundary appears when the agent condenses untrusted content into memory, retrieves it later, and uses it while planning a consequential tool call.

Separate memory usefulness from action authority

An external page, email, document, or tool result can be useful to remember. Anthropic's guidance recommends keeping third-party content distinguishable from instructions, limiting sensitive access, and testing the boundary with adversarial inputs. The question of whether that content is helpful is separate from whether it may support an action that changes the outside world.

Preserve the evidence at write time

The preprint describes memory provenance laundering as consolidation retaining an action trigger while erasing the low-trust source that should constrain its authority. Its proposed pattern keeps platform-maintained provenance and makes authorization depend on the authority of memories relevant to the action.

This envelope is Bonfire operating guidance, not a required schema from the paper. If a source cannot be resolved, do not silently promote the memory to trusted history: deny the consequential action or route it to an explicit review path.

Bind the evidence to actual tool arguments

Provenance on a whole memory record is incomplete. The runtime needs to know which retrieved evidence supports the recipient, account, URL, file, workflow identifier, or other argument that makes a tool call consequential. The proposed support-binding design associates declared action arguments with relevant memory evidence and treats ambiguous or conflicting candidates conservatively.

1. Declare which tool arguments require authoritative support.
2. Record the memory IDs and source references supporting each argument.
3. Evaluate the least authority among relevant support, including unresolved candidates.
4. Compare it with the risk policy for the proposed action.
5. Require a scoped confirmation or deny and escalate when the evidence is insufficient.

The matching algorithm is workflow-specific. What matters is an inspectable record, not a generic claim that the model had a relevant memory. Put that action surface into a production tool contract.

Keep approvals scoped and test the persistence path

The paper's non-amplification formulation says an action-relevant claim does not gain more authority than its least-authoritative support unless a platform-recorded, appropriately bound declassification event exists. In operating terms, a confirmation is a record—not a phrase such as “the user approved this earlier.”

Build a regression that writes an untrusted observation to memory, consolidates it, starts a later task, and attempts the consequential call. The expected result is executable: the evidence may inform reasoning but cannot independently authorize the effect. When evidence is insufficient, use a human approval gate rather than quiet permission.

Keep the research boundary in the design

The authors report no evaluated unauthorized high-risk action passing their gate under fixed-risk policies with intact platform provenance, confirmation, and risk labels. That is evidence for a mechanism under the authors' conditions, not a production guarantee.

The preprint does not establish protection for aggregate low-risk chains, multi-tenant shared memory, inter-agent authority transfer, online learned memory updates, or broad open-ended completion. Useexperience-memory lifecycle controls for usefulness, and keep the authorization decision observable in an agent observability dashboard.

For server-side enforcement alongside the agent boundary, see how a custom MCP server can make authorization, tool policy, and auditability explicit.