AI can remember your habits. Authority needs a separate record.

Analysis | November 7, 2026

The November 5 Memory Trap preprint reports that memories formed in benign interactions can induce out-of-scope behavior in later simulated tasks. It does not measure production incident rates. Paper

The product question is not merely how accurately an assistant preserves a user's words. It is what those stored words are allowed to decide. Our view is that memory can improve service without being the sole authority for changing the outside world. What follows is Open Market Notes' design analysis, not a claim that any particular product implements these controls.

Personalization and permission need different paths

Consider a hypothetical purchasing assistant. Its user prefers fewer questions, familiar suppliers and concise emails. Those preferences can help rank quotations, organize explanations and prepare drafts. Placing an order requires different answers: what may be bought, from whom, within what limit, for delivery where, and whether renewal is permitted. A detailed account of someone's habits cannot supply missing authorization conditions.

When both kinds of information are stored as natural-language notes, an important distinction can disappear. A preference ranks acceptable choices; permission determines whether a choice is executable at all. Treating a dislike of repeated confirmation as a waiver of every confirmation lets a service-quality preference alter the transaction boundary. That is our architectural concern, not a description of an observed customer incident.

A better design would let the model propose an action and an independently maintained permission record determine whether execution is allowed. That record need not be elaborate, but it must identify the operation, target, limits and applicable conditions. Permission might cover recurring purchases or one order. Explicit standing approval should not require repetitive questions, while missing authority should not be inferred from conversational tone.

Account access is not approval for every business action

Claude's memory-tool documentation places storage and execution of file operations in the application. Documentation Application designers therefore have an opportunity to control the gap between a model request and its execution, rather than relying entirely on interpretation of history.

The MCP authorization specification concerns transport-level access to restricted servers on resource owners' behalf. Specification We distinguish a further question: a technical connection that allows a service call does not establish approval for the current order, recipient or sharing destination. Connection permission answers what a client can access. Business permission must also answer what it may do now.

A calendar assistant, for example, might need continuing access to read schedules and create meetings. That is convenient for internal recurring meetings. Sending an external invitation containing an unreleased project's name still requires checking the intended recipients and permitted disclosure. This is a design exercise, not a demand for manual approval of every external meeting. The permission must cover the current facts, not merely a generic tool name.

Batch work needs explicit handling of exceptions

Businesses buy agents partly to reduce coordination. Asking about every operation can return automation's gains as approval overhead. Useful control therefore needs more than a choice between allowing everything and asking about everything.

We propose separating items that meet authorization conditions from items whose material details have changed. Imagine approval to send billing reminders to existing customers. Normal records within that scope can proceed. A record involving a new payment account, a disputed amount or a different recipient should pause individually. It should neither stop the whole queue nor disappear beneath blanket approval. A subsequent decision should resolve the identified exception, not silently expand authority for the entire task.

The system must retain the conditions that held at execution. A record saying only “approved” cannot explain what happened later. Useful audit information includes the approval's source, intended target, limits, material changes and resolution of exceptions. Users do not need every internal detail, but should be able to ask why one item proceeded without another question while another did not.

Measure boundaries, not completion alone

A purchasing test could give normal and exceptional orders similar wording, keeping product and supplier unchanged while varying the spending ceiling, delivery address or renewal terms. The desired outcome is not universal hesitation. Authorized work should continue, with only genuinely out-of-scope items raised.

We would track three measures together: execution without sufficient authority, repeated questions despite valid approval, and time during which exceptions block unrelated normal work. These are our proposed measures, not results reported in the paper. Optimizing only the first can reward refusing everything; optimizing only completion can reward excessive inference. Their combination better tests whether control improves service.

Permission changes need testing too. After automatic purchasing authority for a supplier is withdrawn, old summaries, queued work and another agent's paraphrase should not restore it. The check belongs immediately before execution, not only at planning time. A long-running task should still act under currently valid conditions at its final step.

The preprint deserves attention, but cannot by itself validate a permission architecture. Teams must test their own tools, data and exceptions. The practical goal is an assistant that remembers how to help a person while explaining the authority for each consequential action. Keeping those responsibilities separate offers a way to reduce both needless interruptions and unauthorized execution.