Word's "Remove Personal Information" Doesn't.
Microsoft Told You. Nine Federal Documents Prove It.

The AI Hallucination Cases database maintained by French legal academic Damien Charlotin, one of the most-cited public trackers of the phenomenon, had logged 1,397 court filings worldwide as of May 5, 2026, where an attorney cited a case the AI invented. United States courts alone issued more than $145,000 in sanctions in the first quarter of 2026.

Two of those orders matter for what is about to follow. In Couvrette v. Wisnovsky, No. 1:21-cv-00157-CL, U.S. Magistrate Judge Mark D. Clarke of the District of Oregon sanctioned attorney Stephen Brigandi a total of $110,204.38 across two orders issued in December 2025 and March 2026, after Brigandi included fifteen non-existent cases and eight fabricated quotations across three summary-judgment briefs. When defendants flagged the fakes, Brigandi tried to fix his filings by silently deleting the bogus citations and refiling without disclosing the change.

Judge Clarke's order said it directly. "Rather than a correction, Mr. Brigandi attempted a cover-up. He failed at both."

In Bunce v. Visual Technology Innovations, No. 2:23-cv-01740 in the Eastern District of Pennsylvania, U.S. District Judge Kai N. Scott imposed a $5,000 sanction on attorney Raja Rajan on April 20, 2026, for a second misuse of AI-generated case citations. Rajan had asked one chatbot to verify another chatbot's work. Judge Scott wrote, "It will be your name and license on the line, not ChatGPT's."

Brigandi was caught the easy way: opposing counsel read both versions of the filed PDF and noticed the citations had changed between drafts. Most cover-ups will not be that visible. When the substantive change is subtle, when the surface text reads identically, when the only evidence is a comparison of who edited what and when, that evidence lives in the source document's bytes. Lawyers draft in Word, then export to PDF for filing. The Word file is where the editing trail accumulates. Word offers a feature called "Document Inspector" that promises to remove that trail before sharing. This post is about what it actually leaves behind.

Open a .docx file in Microsoft 365's Word application. Select File, then Info, then Check for Issues, then Inspect Document. A dialog appears with six checkboxes. Microsoft's official support article names them, verbatim:

The disclosure exists. It is not on the support article most users read. It is on a blog post titled "What Document Inspector doesn't catch" that lives in the archived Office Resource Kit section of learn.microsoft.com. The post is dated June 30, 2009. Microsoft Learn's metadata shows the page last touched in 2024 with no content change. Seventeen years on a Microsoft URL.

Direct quotes follow. All of these are Microsoft's own description of what their feature leaves behind, not ours.

The dominant pattern across the United States federal government is upload-as-authored. Document Inspector is rarely if ever invoked at the agency-publication boundary. Native DOCX files travel from a staffer's desktop, through internal review, into a Drupal CMS, and out to the public web with no scrub.

Below are nine DOCX files, all freely downloadable from six federal agencies. All nine were verified as valid OOXML zips and their SHA-256 hashes recorded. We ran them through File X-Ray's parser and through cross-references against ExifTool. The findings are reproducible.

The file at hud.gov/sites/dfiles/Housing/documents/HOTMA_Net_Family_Assets_Script-4_26_24_Final.docx is a 384 KB training script for the Housing Opportunity Through Modernization Act, distributed by HUD's Office of Multifamily Housing. The filename ends in _Final, the canonical signal of a document uploaded straight from a desktop.

The file at grants.nih.gov/sites/default/files/DMS-Plan-blank-format-page.docx is the official NIH grant submission template for data management and sharing plans. Every researcher applying for an NIH grant downloads it.

The file at nidcr.nih.gov/sites/default/files/2025-02/csoc-report-template.docx is a 278 KB template for Clinical Studies Oversight Committee monitoring reports.

The file at justice.gov/d9/jmd/legacy/2014/07/01/cops-justification.docx is a Department of Justice budget submission for the Community Oriented Policing Services office, originally drafted in 2014 and re-served on the modern Drupal 9 platform in 2021.

The file at ignet.gov/sites/default/files/files/10-22-2024 CIGIE Guide for PIIA.docx is a 437 KB cross-IG working-group document distributed by the Council of the Inspectors General on Integrity and Efficiency.

EPA, Environmental Information Document Template. Author "EPA" (institutional, not personal). Last Modified By: Zolandz, Julia. RSID registry: 139 sessions. Body rsids: 89. The cleanest file in the corpus, and it still surfaces a named EPA staffer.

CMS, CY 2026 NY Dual Special Needs Plan Model Material. Author "CMS/MMCO." Last Modified By "Julie Jones." Last printed 2023-04-24. RSID registry: 5,321 sessions, the largest in the corpus. A Medicare model contract template with 5,321 distinct editing-session signatures stored in its bytes.

HHS ACF, PREP Webinar Transcript. No author set. Header reads Mathematica Policy Research, Inc., 20250514 PREP Webinar, Edited. Mathematica is HHS's contractor for PREP evaluation. The file is hosted on prepeval.acf.hhs.gov. The header outs the contractor that produced the transcript.

ED.gov, National Certificate of Eligibility Instructions Template 2025-2026. Author "Sarah Martinez." Last Modified By "Meyertholen, Patricia." Used by every Title I-C migrant student certification annually. The header retains an OMB control number that survives every annual revision.

The nine corpus files contain 13,803 total editing-session identifiers (w:rsid values) across their settings.xml registries. Ten of those rsids appear in two different files.

Random collisions happen, but the rate has to be calculated against Word's actual rsid generator, not against the nominal 32-bit value space. Every rsid we observed in this corpus, and every rsid in our control torture file, begins with the byte 00. The high-byte constraint narrows the effective entropy to about 24 bits. Under that conservative model, the expected number of cross-document rsid collisions across nine files of these sizes is approximately four. We observed ten. The probability of seeing ten or more collisions when chance predicts about four is roughly 1.3 percent.

The largest single cross-document cluster is between the CMS Dual Special Needs Plan model material (5,321 rsids in registry) and the DOJ COPS budget justification (2,042 rsids). They share three: 009C7A02, 00B40823, and 00D242E2. Two unrelated agencies, two unrelated documents, three matching session identifiers. For two specific files of those sizes drawn at random, the probability of three matches in 24-bit-effective space is approximately 2.8 percent. The CIGIE PIIA guide and the DOJ COPS justification share two rsids. The CMS Dual SNP material and the HUD HOTMA training script share two rsids. The HUD HOTMA script and the NIDCR CSOC report share one. Each pair, individually, would not survive a strict false-discovery correction. Taken together, the corpus-wide observed rate is significantly above what chance predicts.

The mechanism is documented in the academic literature. Spennemann and Spennemann's 2023 paper "Establishing Genealogies of Born Digital Content: The Suitability of Revision Identifier (RSID) Numbers in MS Word for Forensic Enquiry" (Publications 11(3):35) examined more than four hundred journal-template DOCX files from a single publisher and demonstrated that rsids survive copy-and-paste between files, persist across forks, and can seriate document genealogy. Jeong and Lee's 2017 Digital Investigation paper on Word file revision history reached the same conclusion from a different angle, focusing on the auxiliary .tmp and .asd files Word generates during editing. Spennemann's 2024 follow-up in Forensic Science International: Digital Investigation applied the same rsid forensic technique to detect academic plagiarism and ghostwriting.

What works on a four-hundred-paper academic corpus also works on a nine-document federal corpus. Given two DOCX files with shared rsids, you can attest with statistical confidence that at some point text passed between them, or both inherited from a common ancestor file. None of the federal documents in this corpus had any reason to share rsids by design. They share rsids because someone copied text from one to another, or both sourced the same template branch.

This is the genealogy layer Document Inspector does not address.

To complete the picture we built a synthetic DOCX with every leak vector we could think of, ran it through Word's full Save and Document Inspector "Remove All" pipeline, and compared the bytes before and after.

Methodology caveat first. Microsoft Word, on opening a non-canonical OOXML file, silently repairs parts that do not match its expected structure. Several of our injected sections (custom XML payload, comments, people list) were repaired into nothing on the first save, before Document Inspector itself ran. We cannot make precise claims about what Inspector specifically removed. We can make precise claims about what survived all of Word's pipeline including Inspector's most aggressive setting.

A field that exists in both the pre-Inspector file and the post-Inspector file definitionally survived Inspector. That is the claim category we have evidence for.

After running Inspector with every category checked, the field count surfaced by the parser dropped from 60 to 14. Inspector's surface-level work was real. The marketing-grade summary would call this a 76 percent scrub. The 14 surviving fields are the relevant answer:

The federal corpus residue and the controlled-experiment survivors are visible to anyone with a parser that walks the OOXML tree. Most parsers do not.

Six findings in one paragraph each.

Microsoft has been honest, in a place no one looks. The "What Document Inspector doesn't catch" page is a clean list of fourteen residue categories in Microsoft's own writing. It dates from June 30, 2009. Seventeen years on a Microsoft URL. Anyone who reads it learns most of what this post just demonstrated. Anyone who reads only the support article does not.

The feature has not changed materially in twelve years. The last public Microsoft announcement of a Document Inspector module change was December 9, 2014. OOXML has continued to grow. New element families appear in settings.xml every few years. The 2014 module list is what Word 2024's Inspector still applies. There is no public indication this is being revisited.

Federal agencies do not run it. Across nine downloaded files from six agencies, the Author field intact in eight, the lastModifiedBy intact in nine, rsidRoot intact in nine, headers and footers carrying named staffers and contractor full addresses intact in five, last-printed timestamps reaching back to 2011 in two. Document Inspector takes one click. None of these documents got it.

Even when it runs, the editing-session genealogy survives. rsids are present in nearly every Word document and Inspector does not address them. Two unrelated agency files in our corpus shared three editing-session identifiers, in a way that statistical analysis says is not random. Cross-document linkage is real. The forensic methodology has been peer-reviewed since 2023.

Document variables are an unmarked bypass. Three lawyer names in our torture experiment survived Inspector verbatim because they live in <w:docVars> inside settings.xml, not in docProps/core.xml. Microsoft's documentation never mentions docVars in any Inspector module description. Any law firm, any consultant, any agency that uses document variables for matter numbers, draft attorneys, or template fields is publishing those fields on every "scrubbed" file.

Embedded images and embedded objects pass through untouched. Microsoft says so. The HUD HOTMA training script proves it: a 2017 Adobe Illustrator chart embedded in a 2024 file. Anyone embedding photos from an iPhone is republishing the EXIF GPS coordinates. Anyone embedding an Excel chart is republishing the XLSX's own author, modifier, and rsid lineage.

These six findings are not theoretical. They are reproducible against the file URLs cited in the methodology section below.

The federal corpus was downloaded on May 5, 2026, from the URLs listed below. SHA-256 hashes are recorded for every file. The parser used is the production parser at filexray.orygn.tech/scan. Cross-checks were performed against ExifTool 12.97 and against direct unzip -p against the OOXML zip parts.

Reproduction. Download any of the federal DOCX files from the URLs below. Drop into File X-Ray's /scan page. The fields described in this post will surface for any reader who downloads any of the source files. The torture experiment is a synthetic DOCX built by hand for the test; the parser that reads it is in the project repository.

For technical background on the metadata standards, see the Field Manual. For the previous post on document forensics in famous PDF leaks, see /leaks.