Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do Malicious Documents Take Control of AI Agent Behavior?

A document carries instructions in places a reader never looks, such as white text, metadata and retrieval chunks, and any agent that opens it reads them as part of its task, so the payload travels with the file. Check which documents your agents read, what they can see alongside them, and which actions follow without a person.

Lines from a layered document pass through a control screen and into a series of concentric processing rings.

A document carries instructions in places a reader never looks, such as white text, metadata and retrieval chunks, and any agent that opens it reads them as part of its task, so the payload travels with the file. Check which documents your agents read, what they can see alongside them, and which actions follow without a person. A web page attacks the agent that visits it. A document is saved, shared, forwarded, indexed and retrieved, and each step delivers the same payload to a new agent in a new context; the person who planted it need not know which agent will open the file, or when. This page sets out where an instruction can hide inside a document, why a document payload persists and travels in ways a page does not, how retrieval turns one poisoned file into many triggered agents, what two documented cases showed, what the platform vendors' defenses cover and leave open, and what an organization should verify before agents read shared documents. It extends the question of securing agents that read documents and navigate screens to the file itself as the attack vehicle.

Key findings

  • Hidden prompts embedded in submitted PDFs reliably steered the language models used to review them, with the authors concluding that "adversarial prompts can reliably mislead the LLM" (Collu et al., 2026).
  • The first real-world zero-click case, EchoLeak (CVE-2025-32711) in Microsoft 365 Copilot, exfiltrated data because the client "automatically fetches the external image URL included by the attacker," using an allowed Teams endpoint to get past the content security policy (Reddy and Gujral, 2025).
  • Greshake and colleagues established the attack class by compromising LLM-integrated applications through retrieved content rather than the user's prompt (Greshake et al., 2023).
  • Microsoft's defense for a known exfiltration path was to "deterministically block the security impact," and for residual risk "we rely on the explicit consent of the user to perform a specific action" (Microsoft Security Response Center, 2025).
  • Google's layered defense for Gemini in Workspace includes "Identifying and redacting external image URLs and suspicious links," a control aimed at the exit rather than the instruction (Google Workspace Admin Help, 2026).
  • OWASP lists vector and embedding weaknesses as a distinct LLM risk, covering how poisoned content enters retrieval systems and reaches the model (OWASP, 2025).

Where can an instruction hide inside a document?

In any layer of the file that a model reads and a person does not. The most familiar is invisible text: white characters on a white background, a font size of one point, text behind an image, or a paragraph placed off the printable page. A person sees a normal contract or invoice; a model extracting the text receives every character, hidden or not, in one stream. The peer-review study by Collu and colleagues used exactly this: prompts embedded in submitted PDFs that no human reviewer would see, which the language models used for review read and obeyed (Collu et al., 2026).

The second layer is metadata. Documents carry author fields, comments, tracked-change history, alternative text on images and custom properties, and extraction pipelines often include some or all of these. An instruction in a comment or an image's alternative text reaches a model that reads those fields while remaining invisible to a person reading the body.

The third layer is structure. Spreadsheets have hidden sheets and cells; presentations have speaker notes; PDFs have form fields, annotations and attachments, each a place where text lives without appearing on the page. Consider a vendor contract in a shared folder. The agent's task is to extract the payment terms. The visible terms say net 30. A hidden paragraph, a comment or a speaker-note equivalent says that the remittance account has changed and that the agent should update it in the finance system. The agent, reading the whole file, has two instructions and no way to tell which one the contract's owner wrote. OWASP's LLM01:2025 entry describes the condition: content meant as data is read as instruction (OWASP, 2025).

Why does a document payload persist and travel in ways a web page does not?

Because a file is a copy, and copies multiply. A web page exists in one place and can be taken down. A document that enters an organization is saved, attached, forwarded, uploaded to a ticket, synced and indexed, and each copy carries the payload intact. The attacker has no further part to play; the file does the work wherever it goes.

The second difference is the trigger. A page attacks when visited. A document attacks when opened by an agent, which can be long after it arrived and for a reason unrelated to its content. The EchoLeak case shows the pattern: the attacker's email sat in the inbox, and the instruction fired when the user asked the assistant an unrelated question that caused the email to be retrieved (Reddy and Gujral, 2025). A file in a shared folder has the same property. It waits.

The third difference is trust. An outside web page is understood to be untrusted. A document in the organization's own shared folder, uploaded by a colleague, is understood to be internal, even though its origin was a supplier, a customer or an applicant. The trust attaches to the location; the content retains its author's intent. A file from the "Approved Vendors" folder looks approved, and the agent reads it as such (What Is an AI Control Record?).

Property Web page Document
Where the payload lives One server, can be taken down Every copy, in every location the file reaches
When it fires When the agent visits Whenever any agent opens or retrieves it
Who triggers it The agent's navigation Any user's unrelated request that causes retrieval
How it is perceived External, untrusted Internal, in a trusted folder or system

How does retrieval turn one poisoned file into many triggered agents?

Through indexing. Retrieval-augmented generation splits documents into chunks, embeds them, stores them in a vector index, and returns the chunks most similar to a user's question as context for the model. A poisoned document, once indexed, is a set of chunks the retrieval system will surface to any agent whose query is close enough, for any user, in any task. OWASP's LLM08:2025 entry on vector and embedding weaknesses catalogs this class of exposure, in which content enters the retrieval layer and reaches the model without the user or the agent ever selecting the document (OWASP, 2025).

The attacker's problem becomes retrieval, not delivery. In the vendor contract example, a chunk about payment terms that also carries a remittance-change instruction will be returned to every agent asked about payment terms for that vendor, and perhaps to agents asked about payment terms in general. One upload, indexed once, becomes a standing instruction in the knowledge base.

Retrieval also strips the context that might have warned a person: the chunk arrives without the file's name, folder, author or upload date. Microsoft's taxonomy of failure modes in agentic systems treats poisoning of the resources an agent relies on as a failure class distinct from attacks on the model itself (Microsoft AI Red Team, 2025). The knowledge base is part of the attack surface, and every document ingestion is an admission decision (Can AI Models Change Without Changing Their Controls?).

What did the peer-review and EchoLeak cases demonstrate?

Two different halves of the chain. The peer-review study demonstrated control. Collu and colleagues embedded hidden prompts in PDFs submitted for review and showed that language models used to assess them could be reliably steered toward the attacker's preferred conclusion, writing that "adversarial prompts can reliably mislead the LLM" (Collu et al., 2026). The document was the only input the attacker controlled, and the outcome was a judgment changed by text no human saw. The case generalizes to any agent asked to evaluate, score or extract from a file whose author wants a particular result: an applicant, a bidder, a claimant, a supplier.

EchoLeak demonstrated exfiltration. Reddy and Gujral document how a crafted email, retrieved as context by Microsoft 365 Copilot, caused the assistant to assemble sensitive data into a URL that the client then fetched, because it "automatically fetches the external image URL included by the attacker," with an allowed Teams endpoint used to get past the content security policy (Reddy and Gujral, 2025). The content was a message rather than a file, but the mechanism is the one documents use: a stored item, retrieved for an unrelated reason, carrying an instruction that completed with no click.

Together they bracket what a malicious document can do: change what the agent concludes, and make the agent send what it knows. Both were achieved by planting text in a stored item and waiting, and both trace back to the attack class Greshake and colleagues established, in which the application is compromised through what it retrieves rather than through what the user types (Greshake et al., 2023).

What defenses do the platform vendors describe, and what do they leave open?

They describe layers aimed mostly at the exit. Microsoft's account of defending against indirect injection explains that for the markdown image exfiltration path it took "steps to deterministically block the security impact," and that for residual risk "we rely on the explicit consent of the user to perform a specific action" (Microsoft Security Response Center, 2025). Google's layered defense for Gemini in Workspace includes "Identifying and redacting external image URLs and suspicious links" as one layer (Google Workspace Admin Help, 2026). Both block a known way out and fall back on specific user consent for what remains.

That is the right shape, and it has a boundary. The deterministic blocks cover the exfiltration channels the vendors have identified, in their own products, and the consent fallback covers actions those products surface. What the pages reviewed do not describe is the payload: what sensitive data is in the model's context when the instruction fires, and so what an exfiltration through a channel not yet blocked would carry. Nor do they describe a third-party agent operating in the organization's own applications.

The vendor defenses are a floor for the vendor's products. The controls the organization owns are the two the vendors' own fallback points to: the data the model holds, which can be reduced to tokens before the model reads any screen, and the actions that follow, which can wait for a named person. A document that steers an agent under those controls steers it toward tokens and a proposal someone refuses (Does Model Armor Control What an AI Agent Sees?).

What does a governed environment change?

A governed environment does not stop a document from carrying an instruction; it removes what the instruction can take and what it can do, because the model reads tokens where the real values would be and any consequential action waits for a person.

The mechanism is a class of control applied to the rendered screen rather than to the file. Sensitive values on the screen are replaced with consistent tokens before any model reads them, so the task runs on 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 such as 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 changes the two conditions this page identifies. A planted instruction needs a target and a payload; if the agent reads a contract alongside a vendor screen whose remittance account and bank details are tokens, it has neither. And the actions a document can request, updating a vendor record, sending a summary, loading a link, are each held to the standard Microsoft set for its own residual risk, explicit consent of the user for a specific action (Microsoft Security Response Center, 2025), whichever agent performs them. EchoLeak exfiltrated data through an automatically fetched image URL on an allowed endpoint (Reddy and Gujral, 2025); in this class of control the content available to such a request is tokens, and the attempt is in the record.

The environment does not change the document, the retrieval system or the model, and a poisoned file still needs to be found and removed.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design treats the document as untrusted and limits what a steered agent can see and do. The agent works inside a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so the finance system's vendor screen or any other application page open alongside a document reaches the model with sensitive values replaced by consistent tokens such as ACCT_001 or PATIENT_001 for the whole run; an instruction hidden in a file finds tokens where its payload would be. 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 before it executes, which RedactSure calls Supervised Delegation, so a remittance change a contract's hidden paragraph requested reaches a person who can refuse it. 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 document workflow, with an instruction hidden in one test file, would show the application screens as the model saw them, the action the file requested, and the person who refused it. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on preprints and peer-reviewed research, vendor documentation and standards: the peer-review injection study by Collu et al. (arXiv:2508.20863), the EchoLeak analysis by Reddy and Gujral (arXiv:2509.10540), the original indirect prompt injection paper by Greshake et al. (arXiv:2302.12173), Microsoft Security Response Center's account of its indirect injection defenses, Microsoft's AI Red Team taxonomy of failure modes in agentic systems, Google Workspace's documentation of its layered defense for Gemini, and OWASP's LLM01:2025 and LLM08:2025 entries. All sources were read as of October 16, 2026. Vendor defenses are described from the vendors' own pages.

No hands-on testing of any product was performed, and no document attack was run for this page. Where this page says a capability is "not described," it means not described in the pages reviewed, not that the capability is absent. The EchoLeak vulnerability was addressed by the vendor; document handling features and attack techniques change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot, and are confined to the section on where the company sits. The vendor contract, shared folder and finance system examples describe record types, not any organization; no customer or prospect is described.

Whether a given deployment's document ingestion, retrieval controls, screen handling and action approvals satisfy an organization's security policy, its regulatory obligations or its contractual commitments 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

Malicious documents take control of AI agent behavior by placing instructions in layers of a file that a model reads and a person does not, such as invisible text, metadata, structural elements and the chunks a retrieval system produces. Unlike a web page, a document is copied, forwarded, stored in trusted folders and indexed, so its payload fires whenever any agent opens or retrieves it. The documented cases show the two outcomes: an agent's conclusion changed by hidden prompts in a PDF, and an agent's data exfiltrated by a stored item retrieved for an unrelated question. The platform vendors block known exits and fall back on specific user consent, leaving the organization to govern what the model sees alongside a document and which actions follow it. The test is to name one agent and one task and ask: if the next file this agent opens carries a hidden instruction, what will the model see on the screens beside it, and who must agree before anything changes?

Frequently asked questions

How can a document contain instructions a person cannot see?

Through any layer of the file that extraction reads and a reader does not. White text, one-point fonts, text behind images and off-page paragraphs are invisible in the body but present in the extracted text. Metadata, comments, tracked changes, image alternative text, hidden spreadsheet cells and speaker notes are further places text lives without appearing on the page. The peer-review study used hidden prompts in PDFs that steered automated reviewers while human readers saw nothing.

Why are documents more dangerous than web pages in this respect?

Because they persist, multiply and are trusted. A page lives in one place and attacks the agent that visits it. A document is saved, forwarded, uploaded and indexed, and every copy carries the instruction. It fires whenever any agent opens or retrieves it, often long after arrival and for an unrelated reason, as EchoLeak showed. And a file in an internal folder is treated as internal even when a supplier or applicant wrote it.

What does retrieval-augmented generation change?

It removes the need for anyone to open the file. Once a document is indexed, it becomes chunks that the retrieval system surfaces to any agent whose question is similar enough, for any user. A chunk that pairs plausible content with an instruction becomes a standing instruction in the knowledge base, returned without the file name or author that might have raised doubt. OWASP lists vector and embedding weaknesses as a distinct risk for this reason.

Do the platform vendors' defenses handle this?

For their own products and the exits they have identified, in part. Microsoft describes deterministic blocking of a known exfiltration path and reliance on the user's explicit consent for specific actions; Google describes redacting external image URLs and suspicious links as one layer. Neither page reviewed describes what sensitive data is in the model's context when an instruction fires, or covers third-party agents in the organization's own applications. Those remain the organization's controls.

Can scanning documents for hidden text solve the problem?

It helps and is incomplete. Scanning catches white text and obvious metadata payloads, and an organization should do it. It will not reliably distinguish a legitimate instruction from a planted one, since a note saying the remittance account has changed is valid in one contract and an attack in another, and it does not address chunks already indexed. The controls that hold regardless are on what the model sees alongside the document and which actions wait for a person.

What is the first thing to check in our own deployment?

Open a real file with hidden content, metadata and comments and compare what the model extracted with what a person sees. Then open it with the application screens the agent works in beside it, and look at what the model received from those screens: real account numbers and bank details, or tokens. Then ask which actions the agent could take next without a named person agreeing. Those three observations describe the exposure.

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.