FIleDNA

A Malicious Document Used to Compromise One Person. Now It Can Poison What Your AI Knows

For thirty years, the worst case for a weaponized file was a compromised endpoint. One machine, one user, one incident to contain. Enterprise AI quietly changed the blast radius. When a document becomes training context, retrieval data, or an instruction an autonomous agent acts on, a single untrusted file no longer threatens one person. It can shape decisions across the whole organization.

Our perspective on the trust problem that arrives with enterprise AI


Traditional business software required a human to read a document before anything happened with it. A person opened the attachment, interpreted it, and decided what to do. That human step was slow, but it was also a checkpoint. The damage a malicious document could do was bounded by the one person who opened it and the one machine it ran on.

Enterprise AI removes the checkpoint. Large language models, retrieval-augmented generation systems, copilots, document intelligence engines, and autonomous agents increasingly consume documents directly, extracting knowledge, generating recommendations, producing reports, and driving workflows without a human reading each source first. That is the entire point of deploying them. It is also a profound change in what an untrusted file can reach.

The blast radius changed

The shift is easiest to see as a chain. Consider what a single bad document could do before, and what it can do once AI sits in the middle of enterprise workflows.

Yesterday

Bad document  →  bad endpoint

Tomorrow

Bad document  →  poisoned AI  →  bad recommendations  →  bad automation  →  bad customer outcomes  →  regulatory and financial exposure

Every uploaded document becomes potential enterprise knowledge. Every engineering drawing becomes context a model reasons over. Every contract becomes retrieval data. Every technical specification becomes operational guidance that an assistant may hand to an employee as fact. The consequence of compromised content no longer stops at malware execution on a device. It reaches organizational knowledge itself, and everything that flows downstream from it.

A new class of risk that isn’t malware

Traditional cybersecurity protects confidentiality, integrity, and availability. AI introduces a fourth concern that the older model was never built to address: the trustworthiness of the information that automated systems consume.

This is the part that catches security teams off guard. The threat here does not require malware in any conventional sense. A document can carry no executable payload, trip no behavioral heuristic, and match no known signature, and still be dangerous, because it contains instructions or manipulated content aimed at the model that will read it rather than at the machine that stores it. The industry has a name for the most direct version of this. The OWASP GenAI Security Project ranks prompt injection as the leading risk to large language model applications, and it identifies indirect prompt injection, where the malicious instruction is planted in external content the model later ingests, as a distinct and serious class of attack.

Files are the ideal carrier. Researchers have demonstrated PDFs that hide adversarial instructions in places a human reviewer never looks: text placed beyond the visible page boundary, or tucked inside metadata fields, invisible on screen but perfectly legible to the system parsing the document into an AI pipeline. A contract, a resume, a support ticket, or a technical manual can look completely ordinary and still carry a payload written for a machine reader. Conventional antivirus ignores it entirely, correctly, because by its own definition it is not malware. It is a manipulation of content, and content was never the thing the detection stack was watching.

The security question has quietly changed. It is no longer only “does this file contain malware?” It is now also “should this content be trusted to become part of what our AI systems know and act on?” Those are different questions, and almost nothing in the traditional stack was built to answer the second one.

Content security is no longer email security

There was a time when protecting inbound content largely meant scanning email attachments, because email was the dominant way outside information entered the organization. That time has passed. Enterprises now receive externally generated content through cloud collaboration platforms, customer upload portals, API integrations, DevOps repositories, SaaS applications, mobile collaboration, third-party marketplaces, digital supply chains, and, increasingly, dedicated AI knowledge-ingestion pipelines.

Every one of those channels introduces content produced elsewhere into trusted internal workflows, and the newest of them feeds material directly into systems that interpret rather than merely store it. Content security has therefore stopped being a feature of the mail gateway and become an enterprise-wide architectural concern. The document a copilot retrieves from a SharePoint site it was pointed at never passed through the email filter at all. The trust decision has to happen wherever content enters, not only at the one channel that used to matter.

Establishing trust before content becomes knowledge

If the risk is that untrusted content becomes enterprise knowledge, then the natural place to intervene is the boundary, before ingestion, at the moment content crosses into the pipeline. That is a different posture from watching what the AI does after the fact and hoping to catch a bad outcome downstream. It is a preventive checkpoint reintroduced at machine speed, standing in for the human reader that automation removed.

The mechanism that fits this problem is structural rather than probabilistic. Rather than guessing whether a document is malicious, a content trust layer examines what the file actually contains, identifies the executable and active elements and the hidden or out-of-spec content that has no legitimate place in the format, applies policy, and reconstructs a clean equivalent before the document is allowed to become training context or retrieval data. Because the decision rests on the structure of the file rather than a resemblance to known threats, it holds against novel manipulations and against payloads written specifically to evade recognition. It does not need to have seen the trick before to strip content that does not belong.

This is also why the capability belongs upstream of the AI system rather than inside it. Model-level guardrails and output filters are valuable, but they are reasoning about content that has already been ingested. Cleaning the document at the point of entry means the poisoned instruction, the invisible payload, the malformed structure never reaches the model in the first place. Prevention at the boundary and safeguards at the model are complementary layers, and the boundary is the one that keeps the corpus itself trustworthy.

Why this is the moment

Enterprises are racing to put AI to work on their own documents, and the pace is not slowing. Every deployment increases the volume of externally sourced content flowing into systems that consume it as knowledge, and every increase widens the gap between how fast content enters and how well it is vetted. The organizations that get this right will treat trusted content as a prerequisite for trustworthy AI, not as something to bolt on after an incident makes the risk concrete.

The principle is simple to state and demanding to engineer: information should be validated before an automated system is allowed to act on it. That is the problem FileDNA CADR is built to solve at the file boundary, analyzing inbound documents, neutralizing the executable and manipulated content that does not belong, and reconstructing clean, faithful files before they reach users, endpoints, or the AI pipelines that increasingly turn documents into decisions.

This is part of an ongoing series on where enterprise security architecture is heading. Read the companion pieces on why content trust is the AI era’s new security layer, why the largest vendors haven’t built it, and understanding a file instead of guessing whether it’s malicious, or explore the FileDNA platform.