Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Keep Customer Identifiers Out of a Gemini Enterprise Agent's Memory?

Replace the account number, Social Security number and other identifiers with tokens before the Gemini agent reads the screen, so what reaches its session, semantic and episodic memory is ACCT_001 rather than the value. The agent still completes the servicing task, because the real value resolves only in the approved destination field at the moment a named person confirms.

Customer identifiers become small tokens before crossing a layered memory boundary and reaching a task record.

Replace the account number, Social Security number and other identifiers with tokens before the Gemini agent reads the screen, so what reaches its session, semantic and episodic memory is ACCT_001 rather than the value. The agent still completes the servicing task, because the real value resolves only in the approved destination field at the moment a named person confirms. Google describes the Gemini agent as keeping four kinds of memory across devices, and administrators can set how long conversation history is kept. Those settings decide duration. They do not decide whether an identifier was present to be kept, because the agent read the screen before any retention clock started. This page sets out where an identifier enters memory on a customer account screen, what Google's retention and training settings control and where they stop, how researchers have pulled stored data back out of agent memory, how a team tests whether an identifier was ever there, what Google's own documentation says about agent memory and access, and what changes when substitution happens before the read. It builds on research on what confidential data Gemini Enterprise agents can reach and research on whether data can be stolen from an agent's memory if it never entered.

Key findings

  • Google's announcement of the Gemini agent states that "it keeps four kinds of memory": session, semantic, procedural and episodic, with episodic memory covering "everything it has done before," held as "a single set of memories, context, and one personalization graph" across devices (Google Cloud, 2026).
  • Google Workspace administrators can set how long Gemini conversation history is kept, from automatic deletion periods to indefinite retention, and Workspace states it "does not use customer data for training models without customer's prior permission or instruction" (Google, 2026).
  • In a local test by Tencent's Zhuque Lab, a malicious web page induced an agent to leak a stored API key one character at a time through URL path requests in about 1.5 minutes; the authors note that "attackers do not directly query the Agent for sensitive information" (Tencent, 2026).
  • Wang et al. 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 agent platform documentation states that "deployed agents have access to all resources that their service account has permission to access," which sets the ceiling on what an agent can read and therefore remember (Google Cloud, 2026).
  • Memory is a downstream copy of the screen; the identifier reaches it only if the model read it, which is the premise examined in research on render-layer tokenization.

Where could a customer identifier enter a Gemini Enterprise agent's memory?

Take a customer account screen in a bank's servicing console as the record type. It shows the holder's name, the account number, the last four digits of the Social Security number, a date of birth, an email address and a note from the last call. A Gemini agent is asked to update the mailing address and log the change, so it reads the screen.

Google's own description of the Gemini agent gives four places that read can land. Session memory holds the current task, which Google says can run over days. Semantic memory is a knowledge base built from documents, people and other agents. Procedural memory records how a job is done, including skills the agent writes for itself. Episodic memory is "everything it has done before" (Google Cloud, 2026). Google adds that Gemini holds "a single set of memories, context, and one personalization graph" across devices, so what the agent read on a desktop console is available when the same user works from a phone.

For the account screen, the account number and the partial Social Security number are the identifiers most likely to persist. The session memory holds them while the task runs. If the agent writes a procedural note ("to update an address, open the account record and confirm the holder's identity"), the identifier may be embedded as the example it learned from. The episodic record of the run holds the screen content it acted on. Google states that coworker agents "have their own persistent storage, and only have access to the context that you or your team members provide" (Google Cloud, 2026). The context provided here is the screen, and the screen carries the identifiers. Research on what happens when an AI agent reads a sensitive document traces the same path for a document rather than a console.

What do Google's retention and training settings control, and where do they stop?

Google Workspace gives administrators two settings that bear on this question. The first is retention: administrators set how long Gemini in Workspace conversation history is kept, from automatic deletion periods to indefinite retention, and whether Gemini app conversations are saved at all. The second is training: Workspace states that it "does not use customer data for training models without customer's prior permission or instruction" (Google, 2026).

Both settings operate on data that has already been read. A retention period of thirty days means the account number sits in retained history for thirty days; a retention period of zero means it is deleted after the session. In every case the model received it, acted on it and held it for the duration of the task. The training commitment governs a different question, whether the identifier is used to improve the model, and leaves untouched the question of whether it is in the agent's memory for the next task.

The documentation reviewed describes retention for conversation history. A retention period for the four kinds of agent memory Google describes, or a way to view, expire or delete an agent's semantic, procedural or episodic memory, is not described in the pages reviewed. The administrator who wants to assert that no customer identifier is in agent memory therefore cannot rely on a setting alone. OWASP's sensitive information disclosure entry describes the exposure of personal data through model outputs and lists data sanitization before the model receives input among the mitigations (OWASP, 2025). That is a control before the read, not a setting after it.

How does an attacker extract what an agent's memory holds?

Two pieces of research describe the extraction path. Wang et al. introduce MEXTRA, a black-box "Memory EXTRaction Attack" that pulls private user-agent interactions out of an LLM agent's memory, demonstrated on two representative agents; the attacker needs no access to the memory store, only the ability to prompt the agent (arXiv, 2025). Applied to the account screen, the interactions stored from the address update run, including the identifiers the agent read, are the target.

Tencent's Zhuque Lab reports the same shape in a local test with a web page rather than a prompt. A malicious page induced an agent to leak its stored API key one character at a time through URL path requests, which the lab flagged as one high-severity issue in about 1.5 minutes; the authors observe that "attackers do not directly query the Agent for sensitive information" (Tencent, 2026). The agent's own tool use carried the stored value out. For a servicing agent that browses to a vendor page or a customer-supplied link, the stored account number is in the same position as the key.

The point for a financial services team is that memory is a second copy of the screen, reachable through a channel the application's own access controls do not see. The servicing console checked that the agent's user was entitled to the account record. Neither the console nor the retention setting sees the later prompt or the later page that asks the agent to repeat what it remembers. Research on whether sensitive data can be stolen from an AI agent's memory if it never entered examines the only condition under which the extraction returns nothing: the identifier was not there.

How should a team test whether an identifier was ever there to keep?

The test follows from the research. Run the agent on one account screen for one task, the address update. Then, in a new session, ask the agent what it knows about the account holder, and separately let it browse to a test page that asks it to echo what it remembers, modeled on the Tencent and MEXTRA methods. If the account number or the partial Social Security number comes back, retention settings have not kept it out; they have only scheduled its deletion.

Compare two runs of the same screen. In the first, the model received the screen as rendered: "Account 4471 0092 3310, SSN ending 2286, DOB 03/14/1971, holder Jane Doe." The address update completed. The memory probe returns some of those values. In the second run, the screen reached the model as "Account ACCT_001, SSN SSN_001, DOB DOB_001, holder CUST_001." The agent found the address field, entered the new address, and the change was committed when a named person confirmed; the real account number resolved only in the console's own save action, which the model never read. The address update completed. The memory probe returns ACCT_001, a token with no value outside the governed run.

The second run shows the distinction the page rests on. Google's settings decide how long the model keeps what it read. Only a step that runs before the read decides whether an identifier was present to keep. The test does not require access to Google's memory store, which is not described in the pages reviewed as inspectable; it requires one agent, one screen and one probe, and a record of what the model received, the artifact described in research on the AI Control Record.

What does the vendor's own documentation say?

Vertex AI has, as The New Stack reports, "evolved" into the Gemini Enterprise Agent Platform (The New Stack, 2026), which Google describes as one platform for agent development (Google Cloud, 2026). Its pages give these points and limits.

Dimension Google, per its documentation What a buyer should verify
Memory kinds Session, semantic, procedural, episodic; one personalization graph across devices Which kinds a deployed agent uses for the task
Retention Administrator sets conversation history retention, from automatic deletion to indefinite (Google, 2026) Whether it reaches agent memory, not only history
Training use No training on customer data without prior permission or instruction The contract terms behind the statement
Data reach Deployed agents reach "all resources that their service account has permission to access" (Google Cloud, 2026) The service account's actual grants
Agent identity "A strongly attested, cryptographic identity for each agent," granted permissions through IAM (Google Cloud, 2026) Whether identity narrows what is read, or only who reads
Viewing, expiring or deleting agent memory Not described in the pages reviewed Ask for the procedure in writing

Scope the service account, since its permissions are the ceiling on what the agent can read and remember, and give each agent its own identity. Neither changes what the model receives from a screen the agent may open.

What does a governed environment change?

In a governed environment, the account screen reaches the Gemini agent with tokens in place of the identifiers, so none of the agent's four kinds of memory ever holds a customer's account number, and the address update still completes.

The mechanism is a class of control that sits between the rendered page and the model. Sensitive values on the screen, including the account number, the partial Social Security number and the date of birth, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. The real value resolves only at the approved destination at the moment of an approved action, which for the address update is the console's own save of the record. A named person confirms what is tokenized and approves consequential actions, including the record change. Every screen as the model received it, in token form, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because memory is downstream of the read. Google's retention settings act on conversation history after the agent has acted (Google, 2026), and the extraction methods in the research recover what the agent stored (arXiv, 2025). When the stored content is ACCT_001, the retention period and the extraction attempt both operate on a token with no value outside the governed run. The control does not change Gemini, its memory architecture or its settings; it changes the input.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Agents, including a Gemini Enterprise agent, work inside a governed environment in the customer's own cloud. On every rendered page, including the customer account screen in a servicing console, substitution happens at the render layer before any model reads the screen, so the identifiers reach the model as consistent tokens such as ACCT_001 or CUST_001 for the whole run, and those tokens are what any session, semantic, procedural or episodic memory can hold. Real values resolve only at approved destinations at the moment of an approved action, such as the console's save of an address change. 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.

Deployments are in pilot. A pilot on the reader's own servicing workflow would show the account screen as the model received it, the memory probe returning tokens, and the record of the completed task. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Google Cloud's October 2026 announcement of the Gemini agent and its April 2026 announcement of the Gemini Enterprise platform, the Google Workspace Admin Help privacy hub for generative AI, Google Cloud documentation on managing access for deployed agents and on agent identity, Tencent Zhuque Lab's August 2026 analysis of agent memory attacks, the Wang et al. preprint on memory extraction attacks, the OWASP Top 10 for LLM Applications entry on sensitive information disclosure, The New Stack's report on the renaming of Vertex AI, and published RedactSure research pages on Gemini Enterprise agents, agent memory, sensitive documents, render-layer tokenization and the AI Control Record. All sources were read as of October 16, 2026.

No hands-on testing of Gemini Enterprise, its agents or any other product was performed for this page. Where a capability is described as not described, the statement means not described in the pages reviewed, not that the product lacks it; a procedure for viewing, expiring or deleting agent memory may exist outside those pages. Vendor features change, and agent memory features in particular are new and announced for phased availability, so the page carries its date. The Tencent test and the MEXTRA results are reported as their authors describe them and were run on agents other than Gemini. Statements about RedactSure describe its current design, with deployments in pilot. The customer account screen describes a record type, not any organization; the values and token names are illustrative.

Whether a given configuration of Gemini Enterprise meets an organization's obligations under GLBA, state privacy law, PCI DSS or its own data retention 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

Google describes the Gemini agent as keeping four kinds of memory and one personalization graph across devices, and gives administrators retention and training settings for conversation history; a procedure for inspecting or deleting agent memory is not described in the pages reviewed. The retention settings govern how long the agent keeps what it read. The research on memory extraction shows that what it keeps can be pulled back out through a prompt or a web page, without access to the store. The only configuration under which that extraction returns nothing of value is one where the identifier never entered: substitution before the read, with resolution at the approved destination under a named person's confirmation, which is the design RedactSure's environment implements. The test is to name one agent and one account screen, run the task, then probe the agent's memory in a new session and ask whether what comes back is a value or a token.

Frequently asked questions

Does setting Gemini conversation retention to the shortest period keep identifiers out of memory?

No. The retention setting governs how long conversation history is kept after the agent has read the screen and acted. A short period limits how long the account number persists in that history; it does not prevent the model from receiving it, using it during the task, or holding it in the session, semantic, procedural or episodic memory Google describes. Retention for those memory kinds is not described in the pages reviewed. The setting shortens exposure rather than removing it.

Does Google's no-training commitment cover agent memory?

It covers a different question. Workspace states it does not use customer data to train models without the customer's prior permission or instruction. That governs whether an identifier improves the model. Agent memory is the agent's working store for later tasks, and the commitment reviewed does not describe it. A customer identifier can be absent from training data and present in an agent's episodic memory at the same time.

Which identifiers on a customer account screen matter most?

The account number and any portion of the Social Security number, because they identify the holder across systems and are what an extraction attempt would be aimed at. Date of birth and email address combine with a name to identify a person. Free-text notes from past calls are easy to overlook and often contain all of these. A tokenization policy should cover each field a servicing agent reads, not only the fields labeled as identifiers.

How do researchers extract data from an agent's memory?

Wang et al. describe MEXTRA, a black-box attack that prompts the agent to reveal stored user-agent interactions, with no access to the memory store. Tencent's Zhuque Lab showed a web page inducing an agent to leak a stored key one character at a time through URL requests, in about 1.5 minutes. In both cases the agent's own behavior carries the stored content out. The attacker never queries the memory directly.

Does giving the agent its own identity solve the problem?

Agent identity in Google Cloud IAM gives each agent a cryptographic identity with permissions granted directly, and the agent platform states that deployed agents reach everything their service account can. Both narrow who reads and what can be opened. Neither changes what the model receives from a screen the agent is entitled to open. Identity governs the door; the content of the screen passes through it.

Can the agent still complete a servicing task if it never sees the account number?

Yes, for tasks that act on the record rather than on the value. An address update, a note entry or a status change needs the agent to locate the record and the field, which a consistent token such as ACCT_001 supports, and the real value resolves only in the console's save action when a named person confirms. Tasks that require the model to reason on the value itself, such as validating a number's format, need a policy decision on that field.

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.