Consider an agent allowed to read customer records, summarize documents, and create tickets. Each tool can serve a legitimate business task. An unauthorized export can nevertheless emerge when the agent reads restricted records, transforms them into ordinary-looking prose, and places that prose into a ticket visible outside the permitted audience.
The individual operations may pass a tool allowlist. The violation exists in the relationship between the source data and the destination. We use data laundering here to describe the loss of security context during transformation, not to name a newly discovered exploit family.
What the published work establishes
InjecAgent examines indirect instructions carried through external content into tool-using agents [1]. AgentDojo provides tasks and adversarial environments in which tool results can redirect agent behavior [2]. These works support evaluating the transition from untrusted data to downstream actions rather than assessing only the initial user prompt.
The additional inference in this note is architectural: a control that evaluates calls independently can miss an unauthorized information flow even when it recognizes every tool and correctly authenticates the agent. This is a hypothesis to test in a specific deployment, not a universal claim about every gateway.
The relevant security property is that data retrieved under one access boundary should not cross into a destination outside that boundary without an authorized disclosure decision. Transformation does not inherently remove sensitivity or establish a new permission to share.
Preconditions and attacker influence
Assume a support agent can read a restricted customer workspace and write to a broadly shared issue tracker. The legitimate task is to investigate one customer's problem. The attacker can place text in a support attachment or tool result that the agent will encounter, but cannot directly read the customer database.
The attacker wants the agent to move protected content into an attacker-visible issue or diagnostic artifact. The malicious request may be framed as troubleshooting or verification. The attacker relies on the agent's existing privileges rather than supplying a privileged credential.
The scenario requires both source access and a usable sink. If the issue tracker enforces the same audience boundary as the source, the proposed export may fail. If the agent never receives the sensitive content, that path is also closed. State these conditions before interpreting any test result.
The loss of context happens between tools
The first call retrieves data within an approved account. The second step summarizes or restructures it. The third call writes the transformed material to a destination selected by the agent. A policy that knows only tool names sees read, summarize, and create issue; it may never evaluate disclosure.
Summaries can preserve sensitive facts while removing the markers that a pattern-based scanner expects. Encoding, aggregation, and partial extracts create additional challenges. This does not mean every transformed answer is unsafe. It means the receiving destination and the provenance of the information remain relevant after transformation.
Treat free-text fields as possible disclosure channels. Notes, issue bodies, filenames, URL parameters, logs, and attachments can all carry information. A rule that protects only a dedicated export endpoint may leave equivalent paths available through otherwise ordinary business tools.
| Step | Local decision | Session-level question |
|---|---|---|
| Retrieve customer record | Is this reader authorized? | Which data boundary now applies? |
| Transform into a summary | Is transformation permitted? | What sensitivity and provenance remain? |
| Create shared issue | Is this tool available? | Is this audience allowed to receive the content? |
| Retry or split output | Is this call within a per-call limit? | Does cumulative disclosure exceed authority? |
Defensive design: preserve a disclosure boundary
Keep source identifiers and classification metadata in the execution context where feasible. At outbound actions, resolve the actual destination and audience from trusted provider metadata. Compare that destination with the source restrictions and the workload's explicit disclosure grant.
Do not claim perfect taint tracking through arbitrary language generation. A model can combine information from several sources, and exact semantic lineage may be unavailable. Use conservative sensitivity inheritance for bounded workflows, resource-level access controls, destination restrictions, and review for ambiguous high-consequence disclosure.
For legitimate external communication, minimize the data available to the agent before drafting. A support workflow may need an order status rather than the full record. Reducing source exposure often provides a stronger and cheaper boundary than trying to detect every possible sensitive paraphrase at egress.
Detection requires a session view
Correlate restricted reads with subsequent outbound writes, new destinations, bulk retrieval, repeated small transfers, and unusual attachment creation. A new sink introduced shortly after untrusted content is encountered can justify investigation, especially when it falls outside the initiating task.
Preserve the original user request separately from the agent's evolving plan. An agent may explain that the export is required because an external document told it so. That explanation does not establish user authority. Analysts need both the request and the source of the claimed requirement.
Tune detections against legitimate workflows. Incident responders and support engineers may legitimately summarize restricted information for an approved audience. An alert should identify the source, sink, missing permission, and evidence gap rather than treating all read-then-write sequences as malicious.
A proposed canary experiment
Create synthetic customer records with unique canary facts and a ticket service whose audiences are fully controlled. Define a legitimate task and an explicit rule prohibiting transfer to one test destination. Run the clean task first to establish that ordinary support work completes.
Introduce an untrusted attachment that attempts to redirect the workflow toward that destination. Test direct copying, paraphrasing, aggregation, and splitting across several calls. Inspect the sink for the canary facts and the provider audit for actual writes. Record attempted actions, denied dispatches, and confirmed disclosure separately.
Repeat with the same authorized disclosure to a permitted audience. That benign counterpart checks whether the control enforces the boundary or simply disables outbound work. Record model, prompt, tool, policy, and corpus versions; stochastic behavior requires repeated trials and honest denominators.
What the result would mean
A confirmed canary transfer would establish a failure of the tested information-flow boundary under the stated configuration. A refusal without sink inspection would establish less. A clean test run would support only the cases exercised, not immunity to all transformations or tool combinations.
The defensive priority is to govern the composed effect: which data may reach which audience under whose authority. Tool allowlists remain useful, but the system also needs a way to reason about the relationship between a sensitive read and an external write. That relationship is where a harmless-looking sequence can become a disclosure.