Hidden in Plain Sight: The File Leaks That Prove “What You See” Is Not What AI May Read
Files can expose more than what appears on screen. From failed PDF redactions and EXIF leaks to hidden prompt-injection attacks, past incidents show why every file should be inspected before being uploaded to AI.
For years, some of the most embarrassing security leaks have not come from elite hackers, zero-days, or stolen passwords. They have come from something more ordinary: files that looked clean but still contained hidden information.
PDFs with black boxes over sensitive text. Word documents with metadata. Photos with GPS coordinates. Printed documents with invisible tracking dots. And now, in the AI era, documents with hidden prompt-injection instructions that can manipulate what an AI system does.
The pattern is clear: a file is not just what appears on screen. It can contain invisible layers that humans miss but machines can read.
The old problem: bad redactions and forgotten metadata
One of the most famous redaction failures happened in 2009, when the Transportation Security Administration accidentally exposed a screening manual that had been posted online. Sensitive parts of the PDF had been covered visually, but the underlying text remained recoverable. Wired reported that the leaked material included secondary screening criteria, exemptions, screening procedures, and even instructions for calibrating metal detectors. The Department of Homeland Security’s Inspector General later issued a report on the breach.
This was not an isolated mistake. In 2008, Wired reported that hidden text in a Justice Department Inspector General audit about FBI wiretapping payments could be revealed with a simple copy-and-paste operation. The supposedly redacted material included sensitive details about telecom infrastructure and costs.
A similar issue appeared in litigation involving AT&T and NSA surveillance. A 2006 CNET report, cited in later legal scholarship on redaction failures, described how sensitive information in a PDF legal filing could be recovered because the visible redaction did not actually remove the underlying text.
The same class of error affected a 2005 U.S. Army report on the death of Italian intelligence officer Nicola Calipari in Iraq. The public PDF had redactions, but the underlying censored text could be extracted. Wikisource’s copy of the report describes the improper procedure and shows how the blacked-out material remained readable.
The lesson from these cases is simple: covering text is not the same as deleting text.
The political and legal fallout of PDF redaction failures
The most politically visible modern example may be the 2019 Paul Manafort court filing. Manafort’s lawyers filed a document with black redaction bars, but journalists quickly discovered that the hidden text underneath could be revealed by copying and pasting. Vox reported that the exposed text showed prosecutors believed Manafort had shared 2016 campaign polling data with Konstantin Kilimnik, whom prosecutors had linked to Russian intelligence.
The American Bar Association later used the Manafort episode as a warning to lawyers, noting that the failure disclosed information that had previously been confidential or unknown.
Facebook also suffered a high-profile redaction failure in litigation over its confidential settlement with ConnectU. Dark Reading reported that redacted portions of a PDF transcript could be revealed, exposing details the company had intended to keep secret.
In 2014, the New York Times reportedly published a Snowden-related NSA PDF with failed redactions. Techdirt reported that the upload exposed the name of an NSA employee and a targeted network, while OpenNews later cited the case in a guide on protecting sources when releasing sensitive documents.
These cases matter because they are not obscure technical edge cases. They affected governments, courts, major media organizations, political figures, and large companies.
Metadata can expose people, places, and sources
Not all hidden-file leaks involve redaction. Sometimes the hidden layer is metadata.
In 2012, Vice published a photo of John McAfee while he was evading authorities. The image reportedly contained geolocation metadata pointing to Guatemala. Wired reported that the embedded location data placed McAfee near the Rio Dulce area; days later, Wired also reported that he had been detained in Guatemala.
Photos are especially risky because EXIF metadata can contain GPS coordinates, timestamps, camera model, device information, and software details. In the McAfee case, the hidden data was not merely embarrassing; it had real-world location consequences.
Another famous metadata-adjacent case involved Reality Winner, the former NSA contractor accused of leaking a classified document to The Intercept. The issue was not ordinary document metadata but printer tracking dots: tiny, nearly invisible yellow dots that some color printers add to pages. Ars Technica explained how these dots could encode information such as the date, time, and printer serial number. The Electronic Frontier Foundation also discussed the tracking-dot technology after the case returned it to public attention.
Wired reported that investigators also used printer logs and other clues to narrow down who printed the classified report.
For journalists, whistleblowers, lawyers, and security teams, the message is severe: files can carry identity signals even when the content itself has been redacted or anonymized.
Word documents have exposed hidden authorship and collaboration
Microsoft Office files are another recurring source of hidden data. Word documents can contain authorship data, revision history, comments, tracked changes, template names, timestamps, and other internal properties.
The Office of the Privacy Commissioner of Canada warned as early as 2006 that document metadata had already caused professional and political embarrassment by revealing how, when, and by whom documents were created.
In academic publishing, Word metadata has even been used to detect ghostwriting. Wired summarized a Reuters story in which journal editor Frederic Curtiss examined manuscript metadata and found contributors who were not listed as authors; he estimated that about one-third of manuscripts he received had metadata that did not match the listed authors.
That kind of hidden authorship trail is not always a “data breach” in the narrow cybersecurity sense, but it is exactly the kind of information that people often do not realize they are sharing.
The AI-era version: hidden prompts inside documents
The same old file problem now has a new AI-specific form: hidden prompt injection.
Prompt injection occurs when content processed by an AI system contains instructions that try to override, manipulate, or redirect the model’s behavior. OWASP lists prompt injection as a major LLM risk, and the U.K. National Cyber Security Centre has warned that prompt injection is fundamentally different from classical SQL injection because language models blur the boundary between instructions and data.
The clearest public example so far is academic peer review. Nature reported in 2025 that some researchers had hidden messages in academic papers using white text or tiny font, visible to machines but not normal human readers. The hidden instructions were designed to influence AI-assisted peer review, with some papers reportedly containing commands to give positive reviews only.
The Guardian also reported on the same phenomenon, citing hidden prompts in preprint papers that instructed AI reviewers to ignore negatives and provide positive feedback.
This is especially relevant to tools like Before Upload because the attack uses the same principle as old redaction failures: there is a difference between what a human sees and what a machine reads.
Poisoned documents and AI connectors
The risk becomes more serious when an AI assistant is connected to external tools such as Google Drive, Gmail, SharePoint, GitHub, calendars, or internal documents.
In 2025, Wired reported on “AgentFlayer,” a proof-of-concept attack demonstrated by security researchers Michael Bargury and Tamir Ishay Sharbat. According to Wired, the researchers showed how a single poisoned document shared into a victim’s Google Drive could exploit ChatGPT Connectors through indirect prompt injection. The hidden prompt was written in white, size-one text, making it unlikely for a human to notice but still readable by the AI system.
In the demonstration, the hidden instructions caused the AI to search the connected Drive for API keys and exfiltrate them through a URL embedded in Markdown. Zenity Labs also published a technical write-up of the AgentFlayer attack. Wired reported that OpenAI introduced mitigations after the researchers disclosed the issue.
This is not simply a “bad prompt” problem. It is a file-ingestion problem. A document can become an active instruction carrier when an AI system is allowed to read it and act on connected data.
Hidden prompts in email and webpages
The same risk has appeared in email and web content.
Radware disclosed “ShadowLeak”, a zero-click, service-side attack against ChatGPT’s Deep Research agent when connected to Gmail and browsing. Radware said a crafted email could cause the agent to leak sensitive inbox data without user action or visible UI. Malwarebytes reported that OpenAI fixed the vulnerability and that the attack relied on prompt injection hidden through techniques such as tiny fonts, white-on-white text, and layout tricks.
Palo Alto Networks’ Unit 42 has also reported web-based indirect prompt injection observed in the wild. In one case, hidden prompts were used to target an AI-based product ad review system and force approval of scam content.
The Guardian previously tested ChatGPT’s search tool and found that hidden webpage content could manipulate responses, including making the AI produce favorable output despite negative visible reviews.
These examples show that prompt injection is no longer only a lab concept. Some cases are proofs of concept, some are observed in the wild, and some are already affecting real workflows such as peer review, ad moderation, email summarization, and AI-connected document search.
What we did not find
The research did not reveal a widely documented, famous public breach caused specifically by prompt injection hidden in PDF metadata.
What does exist is close enough to matter:
- hidden prompts in academic PDFs or manuscripts;
- white-text document prompt injection against AI connectors;
- crafted emails with hidden prompt instructions;
- hidden web content used for indirect prompt injection;
- official warnings that hidden text in CVs, documents, emails, and external content can be interpreted as instructions by AI systems.
So the risk is not hypothetical, but the public record is still early. The famous historical cases are mostly about metadata, bad redaction, EXIF, printer dots, and hidden Office/PDF content. The AI-specific cases are newer and often come from security research, incident reports, and observed lower-impact manipulation rather than large confirmed public breaches.
The new rule: inspect before upload
The old advice was: remove metadata before publishing.
The new advice is broader:
Before uploading a file to AI, inspect what the machine may read.
That means checking for:
- PDF metadata;
- hidden text;
- failed redactions;
- comments;
- tracked changes;
- speaker notes;
- hidden sheets;
- EXIF/GPS data;
- embedded files;
- printer or source-identifying traces;
- suspicious AI-directed instructions;
- encoded or obfuscated text;
- links and external references.
The rise of AI tools makes this more urgent. A hidden string that once merely exposed a name, date, or GPS coordinate can now become an instruction to an AI agent connected to email, files, calendars, code, or corporate data.
The lesson from two decades of file leaks is blunt:
If a machine can read it, you may have shared it.