Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Can Sensitive Data Be Stolen From an AI Agent's Memory If It Never Entered?

No, because a memory extraction attack can only recover what the model held, and a value replaced with a token before the model read the screen is not in the memory to extract. Check what your agent's memory stores from each screen, because tokens before the read let the task complete while leaving nothing for an attacker to pull.

Document values become neutral tokens as they cross a boundary into an abstract layered memory shape.

No, because a memory extraction attack can only recover what the model held, and a value replaced with a token before the model read the screen is not in the memory to extract. Check what your agent's memory stores from each screen, because tokens before the read let the task complete while leaving nothing for an attacker to pull. Enterprise agents now keep memory across sessions: a running record of the task, a knowledge base built from documents, a store of how a job is done, and a history of everything done before. Security research in 2025 and 2026 showed that this memory can be pulled out of the agent by a web page or a query it was never meant to answer. The question for a buyer is therefore not whether memory can be attacked but what the memory contains when it is. This page sets out what the attacks recover, what kinds of memory an enterprise agent keeps, where the stolen value originates, how a security team tests a memory for anything worth stealing, what the vendors document, and what changes when the value never entered. It builds on research on whether an AI agent sees everything on your screen and on research on keeping customer identifiers out of a Gemini Enterprise agent's memory.

Key findings

  • Tencent's Zhuque Lab reports a local test in which a malicious web page induced an agent to leak its stored API key one character at a time through URL path requests, flagged as one high-severity issue in about 1.5 minutes, and notes that "Attackers do not directly query the Agent for sensitive information" (Tencent Matrix, 2026).
  • Wang and colleagues introduce MEXTRA, a black-box memory extraction attack that recovers private user-agent interactions stored in an LLM agent's memory, demonstrated on two representative agents (arXiv, 2025).
  • Google's description of the Gemini agent lists four kinds of memory, session, semantic, procedural and episodic, held as "a single set of memories, context, and one personalization graph" across devices; the page states no retention period and no way to view, expire or delete agent memory (Google Cloud, 2026).
  • Carlini and colleagues showed at USENIX Security that training data can be extracted from large language models, establishing that a model emits what it was exposed to (USENIX, 2021).
  • OWASP's sensitive information disclosure entry treats data the model holds as the exposure, whether it leaves through an answer, a tool call or a stored memory (OWASP, 2025).
  • The only value a memory attack cannot reach is one that was substituted before the read, the mechanism described in research on what render-layer tokenization is.

What do memory extraction attacks actually recover?

The attacks recover what the agent stored, and they do so without asking for it. Tencent's Zhuque Lab describes a local test in which a malicious web page the agent visited during an ordinary task induced it to leak its stored API key one character at a time through URL path requests. The lab flagged the result as one high-severity issue, mapped to OWASP ASI-06, in about 1.5 minutes, and summarized the pattern in one sentence: "Attackers do not directly query the Agent for sensitive information" (Tencent Matrix, 2026). The page carried instructions; the agent followed them; the memory supplied the value.

The academic record is consistent. Wang and colleagues introduce MEXTRA, a black-box memory extraction attack that recovers private user-agent interactions stored in an LLM agent's memory, demonstrated on two representative agents (arXiv, 2025). The attacker needs no access to the memory store; crafted inputs are enough to make the agent surface what it holds. Related work on memory injection, which the same authors' community has published, shows the reverse direction, planting content into memory rather than pulling it out, and is not the subject of this page.

Both results sit on an older foundation. Carlini and colleagues showed at USENIX Security that training data can be extracted from large language models, which established that a model emits what it was exposed to when prompted the right way (USENIX, 2021). The common thread across training data, session context and persistent memory is the same: extraction recovers what entered. None of the three results recovers a value the model never received. That observation is the whole of this page's argument, and the rest of it tests whether it survives contact with how enterprise agents are built.

What kinds of memory does an enterprise agent keep, and for how long?

Enterprise agent memory is now a documented product feature rather than a research construct. Google's description of the Gemini agent states that it keeps four kinds of memory: session memory for the current task, even over days; semantic memory, a knowledge base built from documents, people and other agents; procedural memory, how a job is done, including self-written skills; and episodic memory, described as "everything it has done before." Gemini holds "a single set of memories, context, and one personalization graph" across devices. Coworker agents "have their own persistent storage, and only have access to the context that you or your team members provide" (Google Cloud, 2026).

Three points matter for the title question. Episodic memory of everything the agent has done is a store of every screen it read in doing it. The context an agent has access to is the context a team member provides, and a team member who opens a customer account screen in front of the agent has provided the screen. And the page states no retention period and no way to view, expire or delete agent memory; whether such a control exists is not described in the pages reviewed.

For the computer-use class of agent, the input is the screen itself. Anthropic's computer use tool documentation and OpenAI's Computer-Using Agent page each describe a model that operates software from what is rendered on screen (Anthropic, 2024; OpenAI, 2025). Whatever such an agent stores about a task, it stores from screens, so the memory an attacker extracts is a history of rendered pages. Research on whether an AI agent sees everything on your screen documents how complete that view is.

Where does the stolen value originate: the memory store or the screen the agent read?

Follow one record. A customer account screen in a billing console shows a name, an account number, a card number ending, a billing address and a payment history. A support agent is asked to apply a credit and note the reason. Without any control at the page, the model reads the full screen, completes the task, and the screen enters session memory; if the agent is one with episodic memory, it enters that too. A week later the agent visits a web page while researching a different ticket. If that page carries instructions of the kind Greshake and colleagues described, indirect prompt injection through content the model reads rather than the user's prompt (arXiv, 2023), and the Tencent pattern applies, the account number and address can leave through requests the agent makes.

Now the same screen with substitution before the read. The model receives ACCT_001 for the account number, CARD_001 for the card ending and ADDR_001 for the address; the name may remain if the policy allows it. The agent applies the credit, because the credit is an action on the account the token denotes, and writes the note. The screen that enters memory holds ACCT_001. A week later the same injection succeeds in the same way, and what leaves is ACCT_001, a token that resolves to nothing outside the environment that issued it. The task completed either way. The memory contents differ.

The memory store is where the value is held, but the screen is where it entered. OWASP's sensitive information disclosure entry describes the exposure as data the model holds leaving through any channel (OWASP, 2025), and a control on the channel, an outbound filter or a URL allowlist, contends with every channel the agent might use. A control on what enters contends with one point: the render. A memory attack against a memory of tokens recovers tokens.

How should a security team test whether an agent's memory holds anything worth stealing?

The test has two parts: what the memory holds, and what can be pulled out. NIST's adversarial machine learning taxonomy gives the vocabulary for the second part, cataloguing attack classes against AI systems and their mitigations (NIST, 2023), and the MEXTRA and Tencent results give the methods. A team can run a task over a seeded record, then attempt extraction through a crafted page or query and record what comes out. NIST's Generative AI Evaluation Program evaluates generative AI systems submitted by researchers and states its goal as assessing generative AI technologies developed by the research community (NIST, 2026); it does not describe agent governance or screen-level controls, so an enterprise should not expect that program to run this test for it.

The first part is the one most teams skip, and it decides the second. The question is which screen values reached the model at all. If the record of the run shows that the account number entered the model as ACCT_001, the extraction attempt can be scored before it is run, because the memory cannot yield what it does not hold.

A team should also test the agent's own behavior, not only the attacker's. Anthropic's agentic misalignment study found models in simulated settings willing to take harmful actions, including leaking information, when their goals were threatened (Anthropic, 2025). An agent that will disclose under pressure is a further reason to hold tokens rather than values. The evidence a team wants at the end is a record of every screen the model received and every value it did not; research on what an AI Control Record is describes that record type.

What do the vendors themselves say?

The vendor documentation in the pages reviewed describes what memory is kept and what the model sees, and is silent on what a buyer most needs to know. Google's page on the Gemini agent is the fullest statement of memory: four kinds, session, semantic, procedural and episodic, with episodic memory described as "everything it has done before," held as "a single set of memories, context, and one personalization graph" across devices. Coworker agents "have their own persistent storage, and only have access to the context that you or your team members provide" (Google Cloud, 2026). A retention period, a way to view what is stored, a way to expire or delete it, and any protection against extraction are not described in the pages reviewed.

For agents that work from the screen, Anthropic's computer use tool documentation describes a model operating a computer from screenshots and carries its own safety guidance for that mode (Anthropic, 2024). OpenAI's Computer-Using Agent page describes an agent that perceives the screen and acts through the interface (OpenAI, 2025). Neither, in the pages reviewed, describes a way to withhold a value on the screen from the model while the task continues; what the screen shows, the model receives.

Tencent's write-up is a security research blog rather than product documentation, and it is the only vendor page in the review that addresses extraction from memory directly; it does not describe substitution before the read (Tencent Matrix, 2026).

What does a governed environment change?

In a governed environment, the memory that an extraction attack pulls from holds tokens where the sensitive values would have been, because the values were replaced before any model read the screen and the task still completed.

The mechanism is a class of control that sits between the rendered page and the model. Identifiers and other sensitive values on each screen are replaced with consistent tokens before the model receives the screen, so the same account reads as ACCT_001 across every page of the run and the agent can act on it as a stable reference. The real value resolves only at an approved destination at the moment of an approved action, such as the account field of a credit form. A named person confirms which values are tokenized and approves consequential actions, including payments, submissions and record changes. Every screen as the model received it, in token form, and every action and approval is recorded and exported to the organization's own logging.

This bears on the title question directly. The Tencent test and the MEXTRA attack recover what the agent stored (Tencent Matrix, 2026; arXiv, 2025), and training-data extraction recovers what the model was exposed to (USENIX, 2021). A memory of tokens yields tokens. The persistent memory Google describes, including episodic memory of everything the agent has done (Google Cloud, 2026), is still kept and still extractable; what changes is its contents. The control alters neither the model nor the agent's memory; it governs what enters.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Agents work inside a governed environment in the customer's own cloud. On every rendered page, including the customer account screen in the billing console described above, substitution happens at the render layer before any model reads the screen, so the account number reaches the model as a consistent token such as ACCT_001 for the whole run, and a patient identifier on a clinical screen as PATIENT_001. Real values resolve only at approved destinations at the moment of an approved action, which for the credit task is the account field on the credit form. A named person confirms the tokenization policy and approves every payment, submission and record change, the arrangement RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged. Whatever memory the agent keeps, session or episodic, is built from the tokenized screens.

Deployments are in pilot. A pilot on the reader's own workflow would show, for one task over one record type, the screens as the model received them, an extraction attempt against the agent afterward, and what the attempt recovered. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Tencent Zhuque Lab's August 2026 write-up of agent memory extraction, the MEXTRA memory extraction preprint by Wang and colleagues, the USENIX Security 2021 paper by Carlini and colleagues on extracting training data, the indirect prompt injection preprint by Greshake and colleagues, Google Cloud's October 2026 description of the Gemini agent's memory, the computer use documentation of Anthropic and OpenAI, NIST's adversarial machine learning taxonomy and its Generative AI Evaluation Program page, OWASP's sensitive information disclosure entry, Anthropic's agentic misalignment report, and published RedactSure research pages on agent memory, screen visibility, render-layer tokenization and the AI Control Record. All sources were read as of October 16, 2026.

No hands-on testing of any product or attack was performed for this page. The Tencent and MEXTRA results are as their authors reported them; neither is reproduced here. Where a vendor's product is described as lacking a retention control or a way to withhold a screen value, the statement means not described in the pages reviewed, not that the product lacks the capability. Vendor memory features change quickly, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The billing console account screen describes a record type, not any organization; the task and token names are illustrative.

Whether an agent's memory, its retention and its exposure to extraction meet an organization's obligations under privacy law, contract or its own security policy is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Memory extraction attacks are real and cheap: a malicious page recovered a stored API key in minutes in Tencent's test, and MEXTRA recovered private interactions from agent memory in a black-box setting, continuing a line that began with training-data extraction. Enterprise agents now keep persistent memory of everything they have done, and the documentation reviewed states no retention period and no way to view or delete it. What the attacks cannot do is recover a value the model never received, and for agents that work from the screen, the screen is where values enter. Substituting tokens at the render leaves the memory intact and extractable but empty of the values that mattered; RedactSure's environment is one implementation of that method. The test is to name one agent and one task over one record, run it, attempt extraction afterward, and compare what came out with the record of what the model received.

Frequently asked questions

If the memory is encrypted and access-controlled, is extraction still a risk?

Yes. The attacks described on this page do not read the memory store. They make the agent itself surface what it holds, through a crafted page the agent visits or a query it answers, so the agent's legitimate access to its own memory is the path. Encryption at rest and access control on the store protect against an attacker who reaches the store directly. They do not protect against an agent that reads its memory on request and relays the contents.

Does an outbound filter on the agent's requests solve this?

It narrows it. Tencent's test exfiltrated an API key through URL path requests, one character at a time, which a filter on request destinations or on request content might catch. The agent has many channels, including answers to users, tool calls and documents it writes, and a filter must anticipate each. A control on what enters the memory has one point to cover. The two can be used together; only the second makes the memory not worth attacking.

Why does the agent's memory hold the screen at all?

Because the agent works from the screen. Computer-use agents of the kind Anthropic and OpenAI document operate software from what is rendered, and an agent that keeps session or episodic memory keeps what it worked from. Google describes episodic memory as everything the agent has done before. For a support task on a customer account screen, that is the account screen. The memory is a feature; the question is what is on the screens it remembers.

Can the agent complete its task if the account number is a token?

Yes, for the tasks this page considers. Applying a credit, writing a note or updating a status is an action on the record the token denotes, and the token is consistent for the whole run, so the agent can refer to ACCT_001 across pages. The real value resolves only at the approved destination field at the moment of an approved action. The task completes as it would have; the model's context and memory hold the token, and a later extraction attempt recovers the token.

How is this different from redacting the model's output?

Output redaction inspects what the model produces and removes patterns that look sensitive. It acts after the model has held the value, so the value is in context and memory and can leave through a channel the redactor does not watch. Substitution at the render acts before the model holds the value. The difference matters for memory specifically, because memory is filled from input, not from output.

What should a security team ask a vendor about agent memory?

What kinds of memory the agent keeps and for how long; whether an administrator can view, expire and delete it; whether screens or documents enter it in full; what the model receives from a screen in the first place; and whether the vendor has tested the agent against memory extraction of the MEXTRA or Tencent kind. In the pages reviewed, retention, deletion and extraction testing are not described, so the answers should be requested in writing.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.