Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Protect Sensitive Data Across Multiple AI Agents?

By making sure no handoff between agents ever carries a real value: one consistent token set, issued before the first agent reads a screen and shared by every agent in the pipeline, keeps identifiers out of every hop by default. Check what crosses each boundary, which agent could resolve a token, and what happens when one hop is compromised.

Data records pass through a sequence of distinct agent rings along a shared protected workflow.

By making sure no handoff between agents ever carries a real value: one consistent token set, issued before the first agent reads a screen and shared by every agent in the pipeline, keeps identifiers out of every hop by default. Check what crosses each boundary, which agent could resolve a token, and what happens when one hop is compromised. Multi-agent designs are now ordinary. An intake agent reads a claims record, a triage agent decides what kind of claim it is, a payment agent prepares the disbursement, and an orchestrator passes messages between them. Each hop is a place where data moves from one model's context into another's, and each agent reads content that an attacker may have planted. The research record on these systems is specific and unflattering: compromise of one agent propagates, and controls placed on a single agent do not follow the data through the handoff. This page works through what changes when more than one agent touches a record, how one compromised hop spreads, why per-agent controls fail at the boundary, how a shared token set changes the picture, how to measure protection across a pipeline, and which claims a buyer should refuse. It extends the question of enforcing data protection across multiple enterprise applications to the case where the applications are read by several agents in turn.

Key findings

  • Web-delivered attacks made GPT-4o multi-agent systems execute malicious code in 58 to 90 percent of trials, with some configurations at 100 percent, which shows that a compromise entering through one agent is not contained there (Triedman, Jha and Shmatikov, 2025).
  • Hidden page elements let an attacker steal user data from a generalist web agent, with the Environmental Injection Attack reaching up to 70 percent success in stealing specific personal information (Liao et al., 2025).
  • Applying one uniform governance model across all agents is a path to failure, because agents differ in autonomy, data reach and consequence, so controls must be set per agent and per task (Gartner, 2026).
  • Information-flow analysis for language models can track which inputs influenced an output, and so which data a downstream agent inherited, though it remains a research technique (Siddiqui et al., 2025).
  • Microsoft's taxonomy of agentic failure modes treats multi-agent interaction as a distinct class of failure, where the boundaries between agents become attack surfaces (Microsoft AI Red Team, 2025).
  • Protecting data across agents starts with protecting what each agent reads from the screen, since every downstream hop inherits whatever the first agent saw (How to Protect Sensitive Data From AI Agents That Navigate Screens).

What changes when more than one agent touches a record?

Consider a claims record moving through a three-agent pipeline. The intake agent opens the claim screen: claimant name, policy number, date of birth, incident description, amount claimed. It summarizes the claim and hands the summary to a triage agent. The triage agent classifies the claim, consults a rules page, and hands a decision to a payment agent. The payment agent fills a disbursement form and submits it. An orchestrator moves messages between the three.

With a single agent, the exposure question is one question: what did this model read? With three, it multiplies. Each handoff is a message written by one model and read by another, and whatever the first agent put in its summary, the second agent now holds. If the intake agent's summary contains the claimant's name and policy number, the triage agent has them, the payment agent has them, and the orchestrator's message log has them. Data that entered at one screen is now in four contexts and at least one log, each with its own retention and each reachable by whatever that agent reads next.

The second change is that the attack surface compounds. Each agent reads content from somewhere: a claim description a claimant typed, a rules page someone maintains, a form a vendor hosts. Any of those can carry injected instructions. In a single-agent design an injection reaches one model. In a pipeline, an injection that lands in the intake agent's context can shape the summary it writes, and the summary is trusted input to the next agent. The pipeline has turned one model's mistake into the next model's instruction, and the record it is working on travels with it.

How does a single compromised hop spread through a pipeline?

The research record on this is direct. In a study of multi-agent systems built on GPT-4o, web-delivered attacks caused the systems to execute malicious code in 58 to 90 percent of trials, and some configurations failed every time (Triedman, Jha and Shmatikov, 2025). The attack entered through one agent's reading of a web page and ended in another agent's action. The intermediate agents did not detect that their input had been shaped by an attacker, because from their position the input looked like a message from a trusted colleague.

The data-theft version of the same pattern has been measured on web agents. The Environmental Injection Attack hides instructions in page elements a human would not notice, and reached up to 70 percent success in stealing specific personal information (Liao et al., 2025). In a pipeline, the stolen value need not leave through the agent that was attacked. It can be written into a handoff message and exfiltrated by a later agent whose tools include sending email or posting to a form. The original work on indirect prompt injection established that retrieved content can redirect a model in exactly this way (Greshake et al., 2023), and the OWASP Top 10 for LLM applications lists prompt injection first among the risks these systems carry (OWASP, 2025).

The lesson for the claims pipeline is that contamination follows the data. If the claimant's real name and policy number are in the intake summary, then any hop that is compromised can leak them, and the defender must secure every hop to secure the record. If the summary carries CLAIMANT_001 and POLICY_001 instead, a compromised triage agent can leak the tokens and nothing else. The attack still happened; the loss did not.

Why do per-agent controls fail at the handoff?

Most agent security controls are applied to one agent at a time: a system prompt with rules, a filter on that agent's outputs, a scoped set of tools. Each is reasonable and none travels with the data. When the intake agent writes a summary and the orchestrator passes it on, the triage agent applies its own rules to content it has no reason to distrust. The boundary between agents is where control is thinnest, and Microsoft's taxonomy of agentic failure modes treats multi-agent interaction as a class of failure in its own right for this reason (Microsoft AI Red Team, 2025).

The uniform alternative does not work either. Gartner's position is that applying one governance model across all agents leads to failure, because agents differ in autonomy, reach and consequence and a single rule set is either too loose for the payment agent or too tight for the triage agent (Gartner, 2026). The defender is caught between controls that are specific but do not follow the data and controls that are too blunt to be specific.

Research on information flow in language models points at what a better control would track: which inputs influenced an output, and therefore which data each downstream agent inherited (Siddiqui et al., 2025). That technique is not a deployed product. What is available today is a cruder version of the same idea: decide what sensitive data may enter the first context, and make that decision hold for every context after it. Zero trust architecture reaches the same conclusion, evaluating each request at an enforcement point rather than trusting a message for its origin (NIST, 2020).

How does a shared token set keep real values out of every handoff?

The control that follows the data is substitution before the first read. If the claim screen is tokenized when the intake agent opens it, the intake agent's summary is written in tokens, the triage agent classifies a claim it knows as CLAIMANT_001, and the payment agent fills a form with POLICY_001 in the policy field. The tokens are consistent across the run and all three agents, so each recognizes the same claim. The mapping between tokens and values is held in the governed environment, outside every agent's context, and consulted once, when the payment agent's submission is approved and the form is written to the disbursement system.

Handoff What crosses with real values What crosses with a shared token set
Intake to triage Claimant name, policy number, date of birth in the summary CLAIMANT_001, POLICY_001, DOB_001
Triage to payment Same identifiers plus the classification Same tokens plus the classification
Payment to disbursement system Real values, as required by the destination Tokens resolve to real values at the approved destination only
Any agent to its log or the orchestrator Identifiers at every hop Tokens at every hop

The table shows why the shared set must be one set. If each agent tokenized independently, the triage agent would receive CLAIMANT_017 for the claim the intake agent called CLAIMANT_001, and the pipeline would lose the thread. If only the first agent tokenized, a later agent opening the claim screen itself would reintroduce real values. The token set has to be issued by the environment the agents run in, not by any agent, and every screen any of them opens must pass through the same substitution. That is what protecting data at the screen rather than at the gateway means here: a gateway inspects traffic between a model and its provider, while these handoffs are between models.

How should an organization measure protection across a pipeline?

Measure the handoffs, not the agents. For a chosen pipeline, record every message that crosses an agent boundary during a real task and inspect each one for identifiers. The count of real values in handoff messages is the metric. A pipeline in which that count is zero has protected the data regardless of what any agent was told to do; a pipeline in which it is not has a leak path at every hop that carries a value.

Then test the pipeline under attack. AgentDojo provides a dynamic environment for evaluating prompt injection attacks and defenses on LLM agents, and its approach, planting instructions in the content an agent reads and checking whether the task is subverted, can be reproduced on the organization's own pipeline with its own content (Debenedetti et al., 2024). Plant an instruction in a claim description and observe what reaches the payment agent. The question is not whether the injection succeeded, since the research record says it often will, but what left the pipeline when it did. Work on multi-agent threat mitigation argues for treating the pipeline as a system with its own failure modes rather than as a set of individually secured parts (Foundjem, Armstrong et al., 2026); handoff-level measurement is the practical form of that view.

Finally, check the agents that were not on the diagram. Pipelines accrete summarizers, notification agents and retry steps, and each new hop that opens a screen on its own must pass through the same substitution. Legacy applications are the usual gap, because their screens are often the hardest to protect, and a pipeline is only as protected as the one agent reading an unprotected screen.

What does a governed environment change?

In a governed environment, identifiers are tokenized before the first agent reads a screen and the same tokens travel through every handoff, so a compromised hop downstream holds nothing it can resolve.

The mechanism is a class of control that sits between the display and the model for every agent in the pipeline. Sensitive values on the rendered screen are replaced with consistent tokens before any model reads them, and each agent's task runs on those tokens; a handoff message written by one agent and read by the next contains the same tokens. Real values resolve only at an approved destination at the moment of an approved action, which no intermediate agent is. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. 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 the research record shows compromise propagating through agents; web-delivered attacks made multi-agent systems execute malicious code in 58 to 90 percent of trials (Triedman, Jha and Shmatikov, 2025). Inspecting handoff messages after the fact finds only the patterns it knows, and by then the writing agent has already held the values; tokenizing before the first read means the list of real values found in handoffs, the artifact asked for above, is empty by construction.

The control does not change the agents, the orchestrator, the applications or the models; it changes what is on the screen when the first agent looks, and therefore what every later agent can inherit.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design is a governed environment in the customer's cloud in which every screen any agent opens is substituted at the render layer before any model reads it. Tokens such as ACCT_001 or PATIENT_001 are consistent for the whole run and are issued by the environment rather than by any agent, so a pipeline of several agents shares one token set and every handoff message is written in tokens by default. Real values resolve only at approved destinations at the moment of an approved action, which for a pipeline means once, at the final submission. A named person confirms the tokenization policy and approves every payment, submission and record change, which the company 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 environment is model agnostic, needs no per-application integration and leaves user permissions unchanged.

Deployments are in pilot. On the reader's own pipeline, a pilot would show each handoff message as it was written, the count of real values in those messages, and the single point at which a token resolved and who approved it. 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 multi-agent and web agent security, including Triedman, Jha and Shmatikov on malicious code execution in multi-agent systems (2025), Liao et al. on environmental injection attacks (2025), Siddiqui et al. on information-flow analysis for language models (2025), Debenedetti et al. on the AgentDojo evaluation environment (2024), Foundjem, Armstrong et al. on multi-agent threat mitigation (2026) and Greshake et al. on indirect prompt injection (2023); on Microsoft's taxonomy of agentic failure modes (2025; vendor whitepaper); on Gartner's May 2026 press release on agent governance (industry analysis); on OWASP's LLM01:2025 entry and NIST Special Publication 800-207 (standards and official guidance); and on RedactSure research pages. All sources were read as of October 16, 2026.

No hands-on testing of any pipeline or product was performed. The percentages quoted are the figures the cited papers report in their own experimental settings, with the models and configurations those papers used; they are not predictions for any organization's pipeline. Where a product's behavior is described, "not described in the pages reviewed" means exactly that. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The claims pipeline used as a worked example describes a record type and a generic sequence of agents, not any organization.

Whether a given pipeline, its handoff contents or its approval design meets an organization's obligations is a determination for its counsel, its assessors and its own security and compliance officers. This page supports that review and does not replace it.

What the record shows

Multi-agent pipelines fail in a way single agents do not: a compromise entering at one agent travels through the handoffs, and whatever data was in the first agent's context travels with it. The research record puts propagation rates in multi-agent systems well above half of trials under web-delivered attack, and data theft from web agents at up to 70 percent. Controls applied per agent do not follow the data across the boundary, and a uniform rule set across all agents is too blunt to be specific. The control that holds is substitution before the first read, with one token set shared by every agent and resolution only at the approved destination, which is the design RedactSure runs. The test is to name one pipeline and one task, capture every handoff message from a real run, and count the real values in them.

Frequently asked questions

Is it enough to secure the orchestrator?

No. The orchestrator moves messages between agents and can enforce routing, but it does not change what those messages contain. If the intake agent read real values, its summary carries them and the orchestrator passes them on. Securing the orchestrator protects against some routing attacks and leaves the data problem untouched. The question to ask of any orchestrator is whether the messages it moves contain identifiers, and the answer depends on what the first agent read.

Why not have each agent tokenize its own inputs?

Because the agents would issue different tokens for the same value and lose the ability to recognize the same record across the pipeline. Consistency requires that the token set be issued once, by the environment the agents run in, and applied to every screen any agent opens. Per-agent tokenization also leaves a gap wherever one agent forgets or is bypassed, and a pipeline is only as protected as its least protected read.

Does prompt injection matter if the data is tokenized?

It still matters, because an injected instruction can make an agent take a wrong action, such as approving a claim that should be denied. What tokenization changes is the loss when injection succeeds. A compromised agent that holds only tokens can leak tokens, which have no value outside the run. Action governance, with a named person approving consequential steps, addresses the wrong-action risk; tokenization addresses the data-loss risk. A pipeline needs both.

How do we find every agent in a pipeline?

Start from the task and trace it, not from the architecture diagram. Run a real claim through and record every process that read or wrote anything along the way, including summarizers, notification steps and retry handlers that were added after the original design. Each one is a hop, and each hop that opens a screen on its own must pass through the same substitution as the rest. Pipelines accrete agents over time, and the diagram is usually behind the running system by several hops.

What should a handoff message contain?

Everything the next agent needs to do its work and no identifier it does not need. For a claims pipeline that means the classification, the amount, the relevant dates and the tokens that let the next agent recognize the record, with the claimant's name, policy number and date of birth present only as tokens. The practical test is to read a captured handoff message as a stranger and ask whether it could be used to identify a person.

Where do the real values come back?

At the approved destination, at the moment of an approved action, and nowhere else. In the claims example that is the disbursement system when the payment agent's submission has been approved by a named person. The environment resolves the tokens as it writes the form; the payment agent's own context never holds the values. Every other consumer of the pipeline's output, including logs, dashboards and the SIEM export, continues to see tokens, so the number of systems that ever hold the real values stays at one.

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.