Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Happens When an AI Agent Reads a Sensitive Document?

The document's contents enter the model's context and from there flow into outputs, logs, tool calls and any downstream agent, with no boundary that distinguishes the sensitive parts from the rest. Check where the contents of one document could travel after the read, and whether your controls act before that moment or after it.

A sensitive document flows into a central processing node and branches toward storage, files, and other endpoints.

The document's contents enter the model's context and from there flow into outputs, logs, tool calls and any downstream agent, with no boundary that distinguishes the sensitive parts from the rest. Check where the contents of one document could travel after the read, and whether your controls act before that moment or after it. A document is the most ordinary thing an agent handles. It summarizes a contract, extracts terms from an invoice, compares a policy to a checklist, drafts a response to a letter. Each of those tasks begins with a read, and the read is where a sensitive document stops being a file with permissions and becomes text in a model's working memory. From that point the text is subject to the model's reasoning, to whatever the model writes, to the logging that surrounds the inference, to any tool the agent calls, and to any other agent that receives the first agent's output. The permissions on the file governed who could open it. Nothing in the permissions governs where the text goes next. This page follows the contents of one document through that chain, describes the research on information flow, injection and memorization that bears on each stage, examines the logging layer that most organizations overlook, and sets out why the control point for an agent that reads documents and navigates screens is before the read rather than after it.

Key findings

  • Information-flow analysis for language models treats the contents of an input as a labeled flow that can propagate to any output the model produces, which formalizes the observation that a read is the start of a path, not an endpoint (Siddiqui et al., 2025).
  • Indirect prompt injection lets text inside a document or page the model reads redirect the model's behavior, so a sensitive document can carry instructions as well as contents (Greshake et al., 2023).
  • Hidden page elements steer web agents into disclosing user data, with the Environmental Injection Attack reaching up to 70 percent success in stealing specific personal information (Liao et al., 2025).
  • Inference tables in a gateway log the requests and responses passing through model endpoints, which means a document's contents can be stored in a second system the moment the model reads them (Databricks, 2026).
  • OWASP's LLM02:2025 entry treats sensitive information disclosure as a model output risk and lists sanitizing data before the model among the mitigations, placing the control ahead of the read (OWASP, 2025).
  • Runtime security for agents is about what happens after access is granted, which is the stage at which a document read turns into propagation (What Is AI Agent Runtime Security and What Happens After an Agent Gets Access?).

Where do a document's contents go once an agent has read it?

Take a supplier contract as the worked example. It contains the supplier's legal name and bank details, the names and signatures of two executives, the pricing schedule, a confidentiality clause, termination terms and a dispute-resolution clause. An agent asked to extract the termination notice period reads the whole document, because the agent cannot know where the notice period is until it has read everything. The bank details, the pricing and the executive names enter the model's context alongside the clause the task needed.

From context the contents can travel along at least five paths. The first is the output: the agent's answer, which may include more than the notice period if the model judges the pricing relevant. The second is the log: the request to the model and its response are commonly recorded by the serving infrastructure, and the request contains the document. The third is a tool call: if the agent uses a search, a calendar or a messaging tool during the task, the arguments it passes may carry text from the document. The fourth is a downstream agent, whose input is the first agent's output and whose logs and tools inherit whatever was passed along. The fifth is the model's behavior under instructions it meets in the document or elsewhere, which the injection research describes.

Information-flow analysis for language models makes the structure explicit. The approach labels inputs and tracks how their contents can influence outputs, and in the permissive form proposed by Siddiqui et al. it reasons about which inputs actually affected a given output rather than assuming all of them did (Siddiqui et al., 2025). The premise is the relevant part: once contents are in context, every output is a potential carrier. A file permission has nothing to say about that, which is why a credential vault cannot protect what an agent reads; the vault governs the opening, not the reading.

How does a document change the agent's behavior as well as its knowledge?

A document is text, and a model does not reliably distinguish text that is information from text that is instruction. Greshake et al. demonstrated indirect prompt injection against real language model integrated applications, showing that content retrieved from a document or a web page, rather than typed by the user, could redirect what the model did (Greshake et al., 2023). A sensitive document therefore carries two risks at once. Its contents may propagate, and its contents may contain instructions that cause other contents to propagate.

The second risk is sharper when the agent holds more than the document. The Environmental Injection Attack study tested web agents that held user data and encountered pages with hidden elements, and found that the hidden elements could steer the agents into disclosing specific personal information with up to 70 percent attack success (Liao et al., 2025). Translate that to documents: an agent that has read the supplier contract and then reads a second document, or visits a page, that contains an instruction to send the bank details somewhere has everything the instruction needs already in context. The second document did not need to contain anything sensitive. It needed only to ask.

This is why the amount of sensitive content in context is the variable that matters. The injection cannot be eliminated, since models read text and text can instruct. What can be bounded is what the injection has to work with. An agent whose context holds the contract's clauses but not its bank details, executive names or pricing can be instructed to exfiltrate those things and have nothing to send. The behavior analyzed on the page about how malicious documents take control of agent behavior is the mechanism; this page is about what the mechanism can reach.

What does the logging layer record when a document is read?

Layer What it typically records What a buyer should verify
Model serving or gateway The request, including the document text, and the response Is logging on, where do tables live, who can query them, how long are they kept
Agent framework Steps, tool calls and their arguments Are tool arguments carrying document text stored, and for how long
Downstream agents Their inputs, which include the first agent's outputs One retention policy across the chain, or several
Application audit log That the file was opened, by whom, when Not what the model received or produced

The serving layer is the one most overlooked. Databricks documents inference tables, which automatically capture incoming requests and outgoing responses for model serving endpoints and store them in a table for monitoring and debugging (Databricks, 2026). Its consequence for a sensitive document is that the full text sent to the model is written to a second system, with its own access controls and retention, at the moment of the read; the contract's bank details are now in a monitoring table its file permissions never contemplated.

Harvard's information security office, in its best-practice guidance on managing generative AI systems, treats the data sent to a model and the records of that data as assets to be governed: the inference log is a data store holding copies of whatever the agent read (Harvard University Information Security and Data Privacy). The application's own audit log, by contrast, records that the file was opened and by whom. It does not record what the model received, which is the gap addressed on the page about monitoring what an agent actually accesses. A buyer asking where the document is now needs an answer covering every row in the table above.

Can a model retain what it read beyond the session?

Two different questions hide here, and they have different answers. The first is whether a single document read during inference changes the model's weights. In ordinary deployment it does not; the model is fixed, and the document lives in context for the session and in logs afterward. The second is whether documents used in training can be recovered from a model later, and the answer to that is yes, in measurable cases. Carlini et al. demonstrated the extraction of verbatim training data from a large language model, including personal information that appeared in the training set (Carlini et al., 2021).

The two questions connect through the logs. A document read during inference does not enter the weights that day. If the inference logs are later used to fine-tune or evaluate a model, the document's contents are in a training set, and the Carlini result describes what can follow. The path is indirect and depends on organizational choices, but it exists, and it begins with the read. OWASP's LLM02:2025 entry covers both the direct disclosure risk and the training data dimension, and its mitigation list starts with sanitizing data before it reaches the model (OWASP, 2025).

For the supplier contract the practical consequence is that the bank details and executive names, once in context, may be in the response, in an inference table, in a tool argument, in a downstream agent's input, and potentially in a future training set. Each of those is a separate retention question with a separate owner. A design that prevents the details from entering context collapses all of them into none.

Why is the control point before the read rather than after it?

Every control that acts after the read is a control on a copy. Output filtering inspects the response, which is one of five paths. Log redaction scrubs the inference table, after the text was written to it. Tool-call inspection examines arguments, one at a time, as they leave. Downstream agents can be given their own filters. Each of these addresses one path and leaves the others, and each operates on text the model has already seen and may already have acted on.

A control that acts before the read changes what enters context, and therefore what every path can carry. For the supplier contract, that means the agent receives a version in which the bank details, the executive names and the pricing are replaced with consistent tokens, such as VENDOR_001 for the supplier and ACCT_001 for the account, while the termination clause the task needs is readable. The response can contain only tokens. The inference table stores tokens. Tool arguments carry tokens. The downstream agent receives tokens. An injected instruction to send the bank details yields a token. The real values appear only where an approved action requires them, at that destination and at that moment.

The approach is the same one described for sensitive data masking for AI agents, applied to a document rather than a screen, and the information-flow framing explains why it works: labels attached before the read propagate with the contents, while labels attached after must chase every copy (Siddiqui et al., 2025). The design question for a buyer is therefore not which filter to add but where the substitution happens relative to the model's first look at the document.

What does a governed environment change?

In a governed environment, a document the agent reads on screen enters the model's context with its sensitive fields already replaced by tokens, so every path the trace in the previous section follows afterward carries tokens rather than values.

The mechanism is a class of control that sits between the rendered document and the model. Sensitive values on the screen, such as the names and account numbers in a forty-page contract, are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions, including payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This places the control where the page has argued it belongs. OWASP's LLM02:2025 entry lists sanitizing data before the model among its mitigations (OWASP, 2025), and a read is the start of a path to outputs, tool arguments, downstream agents and logs. Inference tables record requests and responses passing through a gateway (Databricks, 2026), so without a control before the read the document's contents are stored in a second system at the moment of reading. With one, the five paths of the trace carry the same tokens, and the retention question for each store loses weight because what is retained resolves to nothing outside the environment.

The control does not change where the document is stored, who may open it, how long the inference table keeps rows or the model; it changes which values are in the document when the model reads it on screen.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design places the control before the read. The agent runs inside a governed environment in the customer's cloud, and substitution happens at the render layer, before any model reads the screen or the document, so the supplier's bank details, executive names and pricing reach the model as consistent tokens such as VENDOR_001 or ACCT_001 for the whole run while the clauses the task reads stay readable. Because the substitution happens before context, the response, the inference logs, the tool arguments and any downstream agent carry tokens rather than values. 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. The design is model agnostic, needs no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own document workflow would produce the trace described above and show which stores held tokens and which, if any, held values. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on peer-reviewed research and preprints on information-flow analysis for language models, indirect prompt injection, environmental injection against web agents and training data extraction, on Harvard University's published best-practice guidance for managing generative AI systems, on OWASP's LLM02:2025 entry, on Databricks' documentation of inference tables as an example of serving-layer logging, and on earlier RedactSure research pages on document and screen surfaces, runtime security, credential vaults, access monitoring and masking. All sources were read as of October 16, 2026. The attack success figure cited is the study's own reported result and is not extrapolated.

No hands-on testing of any agent, model, gateway or product was performed for this page, and no document was traced through any system. The Databricks inference tables documentation is used as a representative description of serving-layer logging; other platforms' logging behavior is not described and should be read as not described 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 supplier contract and termination-clause task used as examples describe a record type, not any organization; no customer, prospect or supplier is described.

Whether a given document's propagation through an agent run constitutes a disclosure under contract, privacy law or sector regulation, and whether a given control is sufficient, are determinations for the organization's counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

When an agent reads a sensitive document, the document's contents become context, and context has no internal boundary. The research on information flow treats every output as a potential carrier; the research on injection shows that content the agent reads can instruct it to carry specific things; the documentation of serving-layer logging shows that the full request, document included, is routinely written to a second store at the moment of the read. Controls placed after the read act on copies, one path at a time. A control placed before the read decides what every path can carry, which is the design RedactSure applies at the render layer. The test is to name one agent and one task and ask where the contents of one document could be found after the run: in the response, the inference table, a tool argument, a downstream agent, and eventually a training set, and whether each of those would hold a value or a token.

Frequently asked questions

Does the model remember a document after the session ends?

Not in its weights, under ordinary deployment; the model is fixed and the document lives in context for the session. The document does persist in the surrounding systems: the inference log that captured the request, the agent framework's step records, any tool arguments, and any downstream agent's inputs. If those logs are later used for fine-tuning, the contents enter a training set, and research has shown that training data can be extracted from models. The retention question is about the logs, not the weights.

If the file has strict permissions, is the document protected?

The permissions govern who can open the file. Once an agent operating under an authorized identity opens it, the contents are in context, and the permissions have no further effect on where they go. The response, the inference table and any tool call are outside the file's permission model. A credential vault or an access control list protects the opening; it does not protect the reading, and the reading is where propagation begins.

Can output filtering catch sensitive content before it leaves?

It can catch some of it on the channel it watches. The response is one of several paths; the inference log, tool arguments and downstream agents are others, and a filter on the response does not see them. Filtering also acts on text the model has already composed, so an injected instruction that routed content into a tool call rather than the response bypasses it. A control on what enters context covers every path at once.

What is an inference table and why does it matter here?

A feature of model serving platforms that automatically records the requests sent to a model endpoint and the responses returned, for monitoring and debugging. Databricks documents one such implementation. When an agent reads a document, the request contains the document's text, so the table holds a copy with its own access controls and retention. Many organizations enable the feature without connecting it to the sensitivity of what their agents read.

Does a multi-agent design make the problem worse?

It multiplies the paths. Each agent in the chain has its own inference logging, its own step records and its own tools, and each receives the previous agent's output as input. A sensitive field passed by the first agent is now in the second agent's context and logs. The chain also has as many retention policies as it has agents. A substitution before the first read means every agent in the chain works on tokens.

What is the minimum an organization should check before letting agents read sensitive documents?

Three things. Whether inference logging is enabled on the model endpoint, where the logs are stored and who can read them. Whether the agent's tool calls and step records are stored and for how long. And whether anything replaces sensitive fields before the model reads the document, or whether the model receives the file as stored. The third answer determines whether the first two hold values or tokens.

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.