Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Does Prompt Injection Expose Customer Records?

Yes, when the injected agent can see real customer data and can send anything outward, and published attacks have leaked personal data at success rates from about 20 percent to 70 percent. Check what the model holds at the moment it is compromised, because an agent that only ever sees tokens has nothing real to leak.

Customer records flow from a contained archive into scattered fragments along an exposed instruction path.

Yes, when the injected agent can see real customer data and can send anything outward, and published attacks have leaked personal data at success rates from about 20 percent to 70 percent. Check what the model holds at the moment it is compromised, because an agent that only ever sees tokens has nothing real to leak. The question is usually asked as if prompt injection were the exposure. It is not. Prompt injection is the trigger; the exposure is whatever customer data the agent was holding when the trigger fired, multiplied by whatever channel it had to send that data out. Two agents can be injected by the identical text and produce opposite outcomes: one leaks a customer's name, email, address and payment details, the other emits placeholders that mean nothing outside the session. The difference is not in the model or the attack. It is in what the environment let the model see. This page sets out the published evidence that injected agents leak personal data, traces one real zero-click exploit from injected email to exfiltrated context, defines the blast radius as a function of data reach, works through a customer account record as the unit of exposure, notes what regulators expect of safeguards for customer information, and lists the claims a buyer should refuse.

Key findings

  • Simple prompt injections asking agents to leak personal data they observed during task execution reached average attack success rates around 20 percent in a University of Zurich study (arXiv, 2025).
  • Environmental injection attacks that place malicious elements in web pages achieved up to 70 percent attack success in stealing users' specific personally identifiable information from generalist web agents, in work accepted at ICLR 2025 (arXiv, 2024).
  • EchoLeak, CVE-2025-32711 in Microsoft 365 Copilot, was a zero-click exploit in which the client automatically fetched an external image URL included by the attacker, with an allowed Teams endpoint used to get past the content security policy (arXiv, 2025).
  • The same vulnerability was scored CVSS 9.3 and allowed exfiltration of the most sensitive data from the current LLM context without user interaction (The Hacker News, 2025).
  • The danger condition is the combination of access to private data, exposure to untrusted content and the ability to communicate externally; even a request to load an image can carry stolen data (Simon Willison, 2025).
  • The exposure is bounded by what the model can see, which is why an agent that receives tokens rather than real identifiers yields an injection nothing of value (What Does Prompt Injection Get From a Token-Only Agent?).

What does the published evidence say about injected agents leaking personal data?

Two peer-reviewed lines of work answer the question directly. Researchers at the University of Zurich tested whether simple prompt injections could make an LLM agent leak personal data it had observed while performing a task, and found average attack success rates around 20 percent (arXiv, 2025). The attacks were not elaborate. They asked the agent, through content it encountered, to pass along what it had seen, and one time in five the agent did.

The Environmental Injection Attack study, accepted at ICLR 2025, went further by placing malicious elements inside web pages that generalist web agents visit, and reported up to 70 percent attack success in stealing users' specific personally identifiable information (arXiv, 2024). The word "specific" matters: the attacker named the field they wanted, and the agent, which had access to it in service of the user's task, supplied it.

OWASP's LLM02:2025 entry on sensitive information disclosure frames the general risk: a language model application can reveal personal data, credentials or proprietary information present in its context or training (OWASP, 2025). Prompt injection is the mechanism that turns a disclosure risk into a directed theft, because it lets an outside party choose what the model reveals and where. The research shows the rates are high enough to plan for and the attacks are cheap enough to expect.

How did one real exploit move customer context out without a click?

EchoLeak is the clearest documented case. Catalogued as CVE-2025-32711 and analyzed in a peer-reviewed paper, it targeted Microsoft 365 Copilot. An attacker sent an email containing instructions. When a user later asked Copilot an unrelated question, the assistant retrieved the email as context, followed the embedded instructions, and composed output containing a markdown image whose URL carried data from the session. The client automatically fetched the external image URL included by the attacker, and an allowed Teams endpoint was used to get past the content security policy that should have stopped the request (arXiv, 2025). Press coverage recorded a CVSS score of 9.3 and described the attack as allowing exfiltration of the most sensitive data from the current LLM context (The Hacker News, 2025).

Three features of the case generalize. First, the user did nothing wrong and nothing at all; the trigger was an email that sat in the mailbox until retrieval. Second, the exfiltration channel was not a tool call or a deliberate send but a rendering behavior, an image fetch, which no permission model treated as an action. Third, the egress control in place, a content security policy, was defeated by routing through a trusted domain the policy allowed. The attacker needed only that the assistant could see sensitive context and that one outbound request could carry it.

The case is about an assistant rather than an agent, and that makes the point stronger. An agent that fills forms, sends messages and navigates sites has far more outbound channels than an image fetch. If a single automatic fetch was enough to move the most sensitive data in context, an agent operating a browser under a user's authenticated sessions has no shortage of routes.

What determines the blast radius of an injection?

The blast radius is the product of two quantities: what the model can see and where the model can send. The lethal trifecta framing names the three conditions that together create danger: access to private data, exposure to untrusted content and the ability to communicate externally, with the observation that even a request to load an image can carry stolen data (Simon Willison, 2025). Untrusted content is a given for any agent that reads email, tickets, documents or web pages. That leaves two levers.

Lever What it bounds Typical control Limit of the control
What the model sees The data available to leak Permissions, data minimization, substitution of identifiers Permissions bound the user's reach, not the screen's content; substitution bounds the screen
Where the model can send The channels available to carry a leak Egress filtering, allowlists, output sanitization Trusted domains proxy exfiltration, as EchoLeak showed

Most security programs pull the second lever: outbound filtering, destination restrictions, output sanitization. These are necessary, and EchoLeak shows their limit, since the allowed Teams endpoint carried the stolen data anyway. An allowlist is a list of places an attacker will try to route through.

The first lever is pulled less often because it seems to conflict with the task. An agent processing a refund needs the customer's record. But the agent needs to recognize the customer across screens and act on the right account; it does not need the real email address or card number to do that. Securing agents that access customer data therefore comes down to a question most programs have not asked: of the fields on the screen, which does the model need as real values, and which could be consistent placeholders that resolve only when an approved action needs them?

What does a single customer record expose, field by field?

Consider a customer account record in a billing system. The screen shows the account number, the customer's full name, email address, phone number, mailing address, the last four digits of a payment card, the card's expiry, a list of recent orders with amounts, and a notes field. An agent is asked to apply a credit for a late delivery.

If the agent is injected, through the notes field, through an order description a customer typed, or through a web page it visits to verify the shipping delay, the attacker's prize is whatever the agent can see. Here that is enough to impersonate the customer with the company, to phish the customer convincingly, to attempt account takeover at other services using the same email, and to build a profile from the order history. The 70 percent figure from the environmental injection work describes exactly this kind of field-specific theft (arXiv, 2024).

Now render the same screen with substitution. The account number becomes ACCT_001, the name CUST_001, the email EMAIL_001, the card digits CARD_001. The agent still sees that this is one customer with one account and a set of orders, still applies the credit to the right account, still answers the user's question. An injection that asks it to send the customer's email address receives EMAIL_001, a string that means nothing outside the session. The attack succeeds in the sense the benchmarks measure, the agent complied, and fails in the sense the title asks about: no customer record was exposed. The injection rate did not change. The consequence did. This is the distinction that the token-only agent analysis draws, and it is the only lever that does not depend on guessing where an attacker will route the data.

What do regulators expect of safeguards for customer information?

Customer records in many sectors sit under rules written before agents existed and applicable to them regardless. The FTC Safeguards Rule, 16 CFR Part 314, sets standards for safeguarding customer information at financial institutions under the Commission's jurisdiction and requires a written information security program with administrative, technical and physical safeguards (FTC, 2026). The rule does not mention prompt injection. It requires that the institution identify risks to customer information and design safeguards to control them, and an agent that reads customer records and can be made to leak them is such a risk.

The cost side has its own literature. IBM's annual report on the cost of a data breach quantifies what organizations spend recovering from exposures of customer and personal data across industries and regions (IBM, 2025). An agent-driven leak of a customer record is a breach by any regulator's definition, and the fact that no employee acted and no system was broken into does not reduce the notification obligation or the cost.

The compliance reading of this page is therefore not that a new AI rule forbids agents on customer data. It is that existing rules require the organization to evidence that it controlled the risk, and the strongest evidence is a record showing that the model never received the customer's real identifiers in the first place. A program that can show what the model saw on every screen, as tokens, has a different conversation with an assessor than one that can show only what destinations it blocked. Whether a given design meets a given rule is for counsel, but the shape of the evidence is an engineering choice made before the pilot.

What does a governed environment change?

A governed environment changes what an injection can take: the model holds tokens in place of customer identifiers at the moment it is compromised, so a successful injection has nothing real to send. The published rates, around 20 percent for simple requests to leak observed personal data (arXiv, 2025) and up to 70 percent for environmental attacks (arXiv, 2024), describe how often the instruction lands. They say nothing about what is in context when it does.

This class of control works at the rendered screen. Sensitive values on a customer record, the email address, card digits, address and notes field, are replaced with consistent tokens before any model reads the page, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action, such as a refund submitted to the processor or a record saved to the CRM. A named person confirms what is tokenized and approves consequential actions before they execute. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

Set this against the danger condition the page describes: private data, untrusted content and an outward channel (Simon Willison, 2025). Filters lower the probability of the event, and egress controls were present in the case that defines the problem. The environment removes the first element from the model's view, the one that bounds the loss when the other two fail. The exported record also supplies the screen-by-screen account the previous section asked for.

The control does not alter the application, the user's permissions or the model, and it does not reduce the rate at which injections arrive; it changes what they find.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design pulls the first lever. Agents run in a governed environment in the customer's cloud. Substitution happens at the render layer, before any model reads the screen, so the customer account record described above reaches the model with ACCT_001, CUST_001 and EMAIL_001 in place of the real identifiers, and the same value maps to the same token for the whole run so the agent can still work one customer across many screens. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM, so the organization can show an assessor what the model saw. 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 workflow would inject a request to leak a named customer field, run the agent on a real record type, and show what the model received, what it attempted to send, and what the exported record captured. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on peer-reviewed and preprint research on personal data leakage by injected agents (a University of Zurich study of 2025, the Environmental Injection Attack paper accepted at ICLR 2025, and the EchoLeak analysis presented at an AAAI symposium in 2025), press coverage of the EchoLeak vulnerability, OWASP's LLM02:2025 entry on sensitive information disclosure, the FTC Safeguards Rule at 16 CFR Part 314, IBM's annual data breach cost report, and the lethal trifecta analysis by Simon Willison. Existing RedactSure research pages on prompt injection, token-only agents and securing agents that access customer data are cited as evidence for the design points they document. All sources were read as of October 16, 2026.

No hands-on testing of any agent, model or product was performed for this page, and the EchoLeak vulnerability is described as the cited paper and press report describe it; Microsoft's own account of its remediation was not among the sources for this page. Rates quoted are those the cited authors report under their own test designs and are not comparable across studies. Where a vendor capability is described as "not described," that means it was not found in the pages reviewed. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The customer account record and billing system examples describe record types, not any organization; no customer or prospect is described.

Whether a given deployment's handling of customer information meets the FTC Safeguards Rule or any other obligation is a determination for the organization's counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Prompt injection exposes customer records when two conditions hold: the agent can see real customer data, and it has any channel outward, including channels no one thought of as actions, such as an image fetch. Published research places leakage rates between roughly 20 and 70 percent, and one real zero-click exploit moved the most sensitive context in a production assistant through an allowed endpoint. Egress controls and injection filters lower the odds and were present in the defining case. The lever that changes the outcome rather than the odds is what the model holds: an agent that reads customer screens as consistent tokens, in the manner RedactSure's design describes, complies with the injection and leaks nothing real. The test is to name one agent and one task, inject a request to leak one named customer field, and ask what left the session and what the record shows the model saw.

Frequently asked questions

Is prompt injection itself the data exposure?

No. Prompt injection is the trigger. The exposure is the customer data the agent was holding when it was triggered, combined with the channels it had to send that data out. Two agents injected by the same text can produce opposite results depending on whether their screens showed real identifiers or placeholders. Treating injection as the problem leads to filtering inputs, which lowers the odds. Treating exposure as the problem leads to controlling what the model can see, which changes the outcome.

How often do injected agents actually leak personal data?

Published research reports average success rates around 20 percent for simple injections asking agents to leak data they observed during a task, and up to 70 percent for attacks that embed malicious elements in web pages to steal specific personally identifiable information. The figures come from different test designs and should not be combined, but both are high enough that a deployment on customer records should plan for leakage attempts to succeed sometimes.

What was EchoLeak?

A zero-click vulnerability, CVE-2025-32711, in Microsoft 365 Copilot. An attacker's email contained instructions; when the assistant later retrieved the email as context, it produced output with a markdown image whose URL carried session data. The client fetched the image automatically, and an allowed Teams endpoint carried the request past the content security policy. It was scored CVSS 9.3, required no action by the user, and is the clearest documented case of a rendering behavior serving as an exfiltration channel.

Do egress controls and allowlists stop exfiltration?

They reduce it and cannot close it. The defining real-world case routed stolen data through a trusted, allowed endpoint. Trusted platforms host user-generated content, image proxies and redirectors that will carry anything encoded in a URL. Egress controls remain necessary, because they raise the attacker's cost, but a program that relies on them alone is betting on knowing every route in advance.

Does limiting the agent to the user's permissions protect customer data?

Not in the way the question hopes. The agent acts with the user's permissions, which include access to the customer's name, email, address and card digits; when injected, it uses that access on the attacker's behalf. Permissions determine which records the agent can reach. They do not determine whether the fields on a screen reach the model as real values or as placeholders, and that is the variable that decides what a leak contains.

What does an agent need to see to do its job?

Usually less than the screen shows. To apply a credit, the agent must recognize one customer and one account across screens and act on the right one. It does not need the real email address or card digits to do that. Consistent tokens preserve the structure the task requires while removing the values an attacker wants. The real values are needed only at the moment an approved action reaches an approved destination.

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.