A methods study found that specification-valid Word, Excel and PowerPoint files could show BENIGN in Microsoft Office’s default editing canvas while an extractor exposed task-relevant TRAP content from another part of the file. The workflow confirmed 21 such evidence forks across the three formats, and all 13 extraction tools in the test panel emitted evidence from at least one fork.
The divergence sometimes reached language-model outputs. Across 8,400 trials with four native-ingestion APIs, models returned the trap in 48% to 76% of runs, depending on the API. At least one tested interface returned the trap for 20 of the 21 mechanisms. Those rates were balanced across the tested mechanisms and were not estimates of how common attacks are in real-world deployments.
How the split was confirmed
The study counted a candidate as an evidence fork only when two results appeared after the file was instantiated: BENIGN in the default Office editing canvas and TRAP from at least one extractor. Passing records were deduplicated and screened to keep the analysis within scope.
For a more realistic test, the researchers created 10 Office documents per mechanism, or 210 documents in all. Every instance passed the Office visibility check, and validation found no package, schema, semantic or Markup Compatibility errors.
The measurement covered 13 extraction tools, four native-ingestion APIs and seven web chatbots, with 8,400 API trials and 1,470 web trials. It asked which extractors exposed the trap-bearing view, whether AI services passed that content into their answers, whether exposure followed the model or the ingestion path, how affected paths appeared in open-source agent and retrieval-augmented generation projects, and how common the signatures were in ordinary files.
The API responses were labeled TRAP or NON-TRAP by two automated judges. They agreed on all 8,400 responses, and an audit of 420 sampled responses agreed with both automated verdicts. Web responses were labeled manually.
Extraction reach fell into two bands
The extractors did not expose all mechanisms equally. Seven mechanisms reached between 11% and 33% of the applicable tools, while 14 reached between 67% and 100%; none fell in the middle. Lower reach was seen when the trap sat outside the document’s main content, while higher reach occurred when it was ordinary content text.
The same pattern was visible in the model-facing tests. Models returned the trap in 48% to 76% of API runs, depending on the interface, and at least one interface exposed it for 20 of 21 mechanisms. Matched clean twins produced no trap responses in 840 trials, while visible-positive controls were detected in all 24 trials. Repeated API verdicts were consistent for 826 of 840 document–API pairs, or 98.3%, and all 147 web cells were consistent across their 10 documents.
The advertised model label was not enough to predict exposure
In a direct comparison, GLM’s web interface and file-parsing API advertised the same model label but exposed different mechanism sets. The web path exposed mechanisms that the API did not, while the API exposed none unique to the web path. The study did not identify which backend component accounted for the difference.
A separate set of eight behavioral probes compared closed interfaces with the tested extractor settings. Eight of 11 interfaces matched at least one candidate configuration over those probes. That result shows behavioral equivalence within the test set, not the identity of a service’s backend.
The comparison also included three Claude models using one shared document-ingestion path. They exposed the same 16 of the 21 mechanisms, indicating no observed model-level difference under that shared path. The finding supports stability under the tested setup, not universal model independence.
Ordinary files showed a wide spread of signatures
The source-code review covered 16 open-source agent and retrieval-augmented generation projects. Their default OOXML paths concentrated on a small set of leaf extractor families, the lower-level tools that pull content from documents. The review was conducted at source level and did not measure whether a complete application propagated extracted trap content end to end.
A scan of ordinary public XLSX, DOCX and PPTX samples found that six mechanisms were absent, 10 appeared in under 2% of files, and five appeared in 2.75% to 16.5% of format-specific samples. Overall, 748 of 4,263 documents, or 17.5%, carried at least one signature. The combined figure is descriptive because the sample sizes for the three formats were selected independently; it is not a population estimate.
What the finding does—and does not—establish
The authors interpret document-loader selection and upgrades as security-relevant policy changes. They recommend explicit contracts stating which document view is intended, where evidence came from and what semantic role it has, along with evidence-fork probes for regression testing when loaders change.
The results are limited to the specification-valid OOXML constructions, Office view, pinned extractor versions and call arguments, four native APIs, seven web chatbots, 16 source repositories and the stated public file samples. The study did not estimate attack prevalence or population-level deployment risk, identify the exact backend configuration of a closed service, or measure downstream human decisions and harms.
The work is an arXiv version 1 preprint dated 26 Aug 2026. Its central warning is narrower than a claim that every Office file or AI service is affected: under the tested conditions, the evidence visible in the Office canvas did not always define the evidence exposed by document-ingestion paths.
Paper data and sources
Original title: Beyond the Editing Canvas: Evidence Divergence in OOXML-to-LLM Ingestion
Authors: Side Liu, Jiangpeng Liu, Jinwen Xin et al.
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-26
DOI: Not available
Original paper · Full text