AI Agent Memory Poisoning on Phones: Ask AI, Audit, Recovery

What AI Agent Memory Poisoning Is

AI agent memory poisoning is the attempt to place an untrusted instruction, preference, or biased fact into an assistant's persistent memory so it can influence later answers, recommendations, or actions. The key risk is persistence. A bad one-off answer ends when the chat ends. A poisoned memory can keep shaping future decisions after the user has forgotten the original source.

On a phone, the most practical example is recommendation bias. A page, app, email, document, or button sends content to an assistant and tries to make the assistant remember that one company, product, or service should be preferred later. Microsoft calls this pattern AI Recommendation Poisoning when the goal is to bias future recommendations through memory-like behavior. Actual effectiveness depends on the assistant, memory settings, safeguards, user approval, and whether the attempted instruction is stored at all.

We look at this from a builder's perspective because phone agents blend context, convenience, and action. Personal context can make a phone agent more useful, but only when the user can understand what context entered the system and how it may be reused. For the broader opportunity side of personal context, Personal Context AI Agent for Phone Actions: What Matters covers what useful context should do. This guide focuses on the security path: hidden prompts, saved memory, provenance, inspection, and recovery.

How a Hidden Ask AI or Summarize with AI Prompt Reaches Memory

The risky path usually starts with something that looks helpful. A website may show an Ask AI, Summarize with AI, compare with AI, or recommend with AI button. The visible label sounds harmless, but the underlying link can carry more than a destination. Microsoft observed specially crafted URLs that included prompt parameters, meaning the assistant could receive prefilled text when the user clicked the button.

The non-operational path is enough to understand the defense. A user taps a friendly AI button. The button opens an assistant with a prepared prompt. The prompt includes ordinary-looking summarization text plus an attempted instruction to remember or prioritize a company. The user sees a useful answer and moves on. Later, if the assistant's memory system accepted the instruction, the same assistant may treat the biased preference as part of the user's context during a recommendation task.

This does not make every AI button malicious. Buttons that send selected text to an assistant can be useful. The problem is provenance: the user may not know who wrote the prompt, what text was sent, whether memory was requested, and whether the assistant will reuse any of it later. On phones, the small screen makes this harder because URLs, prompt parameters, copied content, and share-sheet destinations are often hidden behind compact UI.

Our practical rule is simple: treat prefilled AI prompts like prefilled payment details or message drafts. They can save time, but the user should see what will be sent before it becomes part of an assistant conversation or memory.

Memory Poisoning Versus Prompt Injection and Training-Data Poisoning

Memory poisoning, prompt injection, and training-data poisoning are related security topics, but they are not the same diagnosis. Prompt injection tries to influence the current model interaction by placing instructions inside content the assistant reads. It may affect one summary, one tool call, or one answer without becoming persistent.

Memory poisoning targets stored user context. The attacker's goal is to make the assistant save a preference, fact, instruction, or persona-like detail that will be used later. Training-data poisoning happens upstream, before the deployed assistant responds to a user, by influencing the data or process used to train or tune a model. This guide is about the middle case: persistent memory and recommendation influence inside an assistant experience.

A suspicious recommendation alone does not prove which mechanism happened. The useful first step is to ask whether the assistant has a saved memory, personalization setting, or reusable context entry that explains the behavior.

What Microsoft Found and What the Numbers Do Not Prove

Microsoft's AI Recommendation Poisoning research is the clearest current public signal for this topic. Microsoft reported more than 50 unique prompts from 31 companies across 14 industries that attempted to bias future recommendations. The observed technique used crafted URLs behind AI-facing buttons to prefill attempted persistence instructions.

The important word is attempted. The finding shows that companies and promoters tried to influence assistants through prompt paths. It does not prove that every observed prompt successfully changed persistent memory, worked across every assistant, or remained effective after safeguards changed. Microsoft also stated that it deploys mitigations in Copilot and that some earlier behavior no longer reproduced. Those protections belong to Microsoft's environment and should not be generalized to every assistant or phone agent.

MITRE ATLAS memory poisoning catalogs the threat as AML.T0080, which helps teams name the problem precisely. The value of the taxonomy is that it distinguishes compromise of an AI system's memory from ordinary output error. For phone users and builders, that distinction changes the investigation: look for stored state, personalization scope, memory source, and edit controls rather than only arguing with the latest answer.

We treat the Microsoft numbers as a warning about a realistic path, not as proof that every Ask AI link is dangerous. The response should be measured: inspect prompts, verify important recommendations independently, and give users a way to review what their assistant remembers.

Why Memory Provenance, Versions, and Scope Matter

Useful memory needs provenance. If an assistant remembers that the user prefers a certain brand, route, doctor, app, or vendor, the user should be able to inspect where that memory came from. Was it stated directly by the user, inferred from behavior, imported from a document, copied from a webpage, or supplied by a third-party button? Without origin and scope, memory becomes hard to trust and hard to repair.

Architecture examples make this concrete. TencentDB Agent Memory models Chat Memory, Skills, Wiki, and CodeGraph as governed memory assets with ownership, versions, status, visibility, usage counts, and agent bindings. Its documented memory layers preserve raw conversations at L0, then derive L1 atoms, L2 scenarios, and L3 core or persona memory above them. That project is not a phone defense product and it is not evidence of FoneClaw behavior, but it shows the shape of inspectable memory governance.

For phone agents, the practical version is smaller. Every reusable memory should have an owner, a source, a scope, a timestamp or version, and a way to disable, edit, or remove it where the assistant supports memory controls. A preference used for restaurant suggestions should not quietly become a rule for medical, financial, or work decisions. A memory created from a webpage should not carry the same trust as a preference the user explicitly saved.

Provenance does not prevent every injection attempt, but it makes recovery possible. If the user can see which memory influenced a recommendation, the product can help them remove the wrong entry and retest the task with a cleaner context. For deeper memory architecture tradeoffs, Hy-Memory Server Status vs Local Agent Memory: What Phone Users Should Know offers a deeper comparison of hybrid and local memory designs.

A Phone Checklist Before Sending Content to an AI Assistant

Ask AI button security starts before the assistant answers. On a phone, the user often sees a short label, a share-sheet target, or a browser preview rather than the full content that will be sent. A label does not reveal URL prompt parameters, hidden copied text, or instructions embedded in a page. That makes inspection a habit, not a one-time setting.

Use this checklist before sending content to an assistant:

• Check the destination: confirm which assistant, app, account, or browser flow will receive the content.
• Preview the prompt: look for prefilled wording that asks the assistant to remember, prefer, rank, ignore, or always recommend something.
• Separate content from instruction: tell the assistant to summarize the content, not to adopt instructions found inside it.
• Limit context: send only the page, paragraph, image, or screen needed for the task.
• Watch memory prompts: if the assistant asks to save a preference, decide whether that preference truly belongs in future conversations.
• Use direct sources for important choices: verify medical, financial, legal, employment, and purchase recommendations outside the assistant.

Screens, copied text, emails, documents, QR links, and browser buttons can all carry untrusted instructions. Visual inspection helps, but it does not catch every hidden encoding or URL parameter. The safer habit is to avoid sending suspicious prefilled prompts and to review assistant memory controls after any interaction that tries to shape future recommendations.

This is also where local and cloud boundaries matter. AI Agent Trust: Local Android Phone Control vs Cloud Security explains the broader decision between local phone control and online model services. The narrow rule here is context minimization: send less, inspect more, and keep durable memory deliberate.

How to Contain and Recover After Suspected Memory Poisoning

When a recommendation suddenly feels biased, repetitive, or oddly specific after an Ask AI interaction, start with containment. Stop using that assistant context for consequential decisions. Record the page, button, document, or app path that triggered the suspicion. Keep the investigation low-risk; do not paste suspicious payload text into another assistant just to see what happens.

1. Review the assistant's saved memory, personalization, or custom-instruction controls where the platform provides them.
2. Look for entries that mention a company, product, preference, ranking rule, source, or instruction you did not intentionally save.
3. Remove or disable suspicious entries using the assistant's official controls.
4. Start a clean session and ask a neutral version of the recommendation question without the suspect source attached.
5. Compare the answer with independent sources, especially for purchases, health, finance, legal, work, or travel decisions.
6. Check whether chat deletion and memory deletion are separate controls; many products treat them differently.
7. If the device is managed by work or school, follow the organization's security reporting path before continuing with sensitive data.

Memory controls differ by assistant. Some products show saved memories clearly. Some separate personalization, account settings, chat history, and model memory. Some only let users reset broader personalization. Removing a suspicious memory should be followed by a clean retest rather than assumed success, because related context may remain in another setting or account surface.

Recovery is also a product design requirement. A phone agent should make it easy to see what context was attached, which memory or preference was reused, and what action was proposed from that context. Transparent memory controls help investigation, but they do not replace independent verification of important recommendations.

FoneClaw Context Boundaries on Android

The current FoneClaw release information gives us a concrete Android boundary to design from. The current released baseline adds a movable floating assistant and deliberate current-screen attachment while excluding FoneClaw overlay surfaces from that capture. It also shares task controls between Home and the floating assistant. For memory safety, the important point is user intent: screen context is attached when the user chooses, not treated as an invisible always-on feed.

FoneClaw separates configured-model reasoning from supported Android execution. A configured model reasons and plans; FoneClaw supplies governed Android actions with permission, approval, visible-result, and recovery boundaries. Online models or services may receive relevant context depending on the user's configuration and task. That is why our product surfaces context attachment and execution as moments the user can understand.

We do not present FoneClaw's currently available capabilities as automatic memory-poisoning detection, a dedicated saved-memory audit, or rollback for every assistant. The shipped boundary is more practical: the user can decide when to attach the current screen, review sensitive actions before execution, and use Android permission and task controls as part of the workflow. Locally managed account information has user controls, and the broader data boundary is explained on FoneClaw Privacy.

Current supported Android capabilities are summarized on FoneClaw Features. The lesson we carry into product design is direct: phone agents should make context entry visible, keep action authority separate from memory, and make recovery possible when a user spots suspicious behavior. Skill and extension security adds another layer; AI Agent Skill Security Needs Phone Permission Checks covers that installation and permission side without mixing it into this memory-poisoning guide.

Memory Safety Evaluation Checklist for a Phone Agent

Evaluate memory safety with low-risk sample preferences before using an assistant for consequential advice. Create a harmless preference, ask the assistant to use it, remove it if controls exist, and retest in a clean session. Then try a webpage or document that contains ordinary content plus a clearly unwanted preference request, without using any real sensitive data, and check whether the assistant treats it as content rather than durable instruction.

• Provenance: can the user see where a saved memory came from?
• Scope: can a memory be limited to a task, account, app, or context?
• Review: does the assistant ask before saving a preference from third-party content?
• Editability: can the user edit, disable, or remove saved memory where supported?
• Separation: are chat history, custom instructions, personalization, and memory controls clearly distinguished?
• Recovery: after removal, does a clean retest stop repeating the suspicious recommendation?
• Verification: does the workflow encourage independent sources for important decisions?

The goal is not a generic vendor ranking. The goal is to learn whether a phone assistant makes memory visible enough to trust, inspect, and repair. At FoneClaw, we build toward Android agent workflows where context, action, and user control stay explicit from the first screen attachment to the final reviewed result.