Half the Validated Prompt Injections in a Web-Scale Corpus Rode in HTTP Response Headers, Where a DOM-Only Scanner Can’t Reach

Researchers hunting the telltale phrasings of hidden instructions aimed at AI agents built a corpus two ways: a 1.2-billion-URL sweep of Common Crawl, plus 3,346 snapshots pulled from Censys and Shodan that had already been selected because they matched an indicator. Across the 15,387 validated instances that came out of the combined set, just over half were never in the web page at all; they arrived in the HTTP response headers, the metadata a server sends alongside the page, in custom fields with names like X-AI-Instructions. Nothing renders. No white-on-white text, no zero-pixel font, no off-screen div. That only becomes your problem if your agent’s fetch tool serializes the headers into the model’s context along with the page — a client that receives a header and never passes it to a model is not exposed through this channel. Much of what sits in that half is dull, and the measured rate at which models actually obey any of it is low in every representation the researchers tested. Two caveats ride along with those numbers and matter as much as the headline: the scan looked for known phrasings, so it is a floor rather than a census, and the study’s own authors caution that the low compliance figures on raw responses are not evidence that raw responses are safer.

The numbers come from Khodayari, Zhang, Acharya, and Pellegrino, who searched Common Crawl, Censys, and Shodan using 3,963 lexical indicators and confirmed 15,387 injection instances across 11,722 pages and 2,042 hosts. By delivery surface the split is 7,887 instances (51.2%) in HTTP response headers, 7,216 (46.9%) in the response body, and 284 (1.8%) in site-level files like sitemap.xml and security.txt. Read that 51.2% as a property of the combined corpus, because that is how it was computed. The paper publishes no source-by-delivery-surface table, and the two supplemental sources are IP-based scanners whose snapshots are exactly the kind of artifact you would expect to be header-heavy — so the header share within the Common Crawl portion alone is not recoverable from what was published. Inside the header half, the X-AI namespace accounts for 6,535 instances and X-LLM for 1,022 — together 95.8% of the header-borne total. Worth noting if you go to the source: the prose says nine distinct header types were observed, while Table 5 enumerates eight — X-AI, X-LLM, X-AI-Overlords, X-AI-License, X-ChatGPT, X-OpenAI, and two instruction-style fields the table renders abbreviated as X-AI-Instr. and X-Bot-Instr. (the prose spells the latter X-Bot-Instructions). Those eight already sum exactly to all 7,887 header instances, so treat the table as authoritative on the count; there is no ninth category you need to hunt for. The paper’s separate embedding-mechanism taxonomy spans all three surfaces and sums cleanly to the corpus total: 7,887 in headers, 4,608 in HTML elements, 1,996 in structured data (1,716 JSON objects plus 280 XML-root records, most of the JSON being JSON-LD), 675 in comments (356 HTML, 318 JavaScript, one XML), and 221 in page metadata. On visibility, 10,779 instances (70.1%) are non-visible by construction and another 2,703 (17.6%) are concealed through rendering behavior, summing to 13,482, or 87.6% of the corpus. Table 6 reports 13,483 — an off-by-one discrepancy that does not affect the substance. Only 236 instances, 1.5%, are plainly visible to a human reading the page. The remainder is not a fourth category of hidden content: 1,583 prompts had been removed and 86 pages were unreachable by the time the rendering analysis ran.

TL;DR

• Across the study’s combined corpus, 51.2% of validated injections arrived in HTTP response headers — mostly X-AI and X-LLM custom fields that never render, so DOM sanitization and rendering-trick detection miss them entirely. That corpus mixes a Common Crawl sweep with indicator-prefiltered scanner snapshots, no per-source breakdown is published, and the authors call the whole measurement a lower bound.
• Header matches were accepted as true positives by rule rather than individually reviewed, on the reasoning that indicator strings are unlikely to turn up incidentally in a response header. That is a plausible shortcut, but it means the largest category got the lightest validation.
• Provenance across the whole corpus is 79.9% first-party, and the objective labels are multi-label and overlapping rather than a clean partition — but the paper publishes no header-by-provenance or header-by-objective breakdown, so “the header half is mostly harmless” is an inference, not a finding.
• Representation matters more than namespace, with a caveat the headline number hides: compliance runs 3.9% on plain text versus 0.2% on raw HTTP responses, but raw responses also produced a 25.8% model-error rate against 0.7% for plain text, mostly context-window failures. The authors say plainly that this is not evidence raw responses resist injection better.
• Header names cannot classify injection. Scan normalized header values before ingestion, then page on the correlation: injection-classified content followed in the same session by a policy-relevant action — ordered by trace, span and parent-child structure, never by _time.
• The durable fix is a serialization boundary, not a protocol one: omit transport headers from model context by default and project only required metadata into typed, provenance-marked fields.

What the number measures, and what it doesn’t

This is the part that decides whether your detection survives week one, so be clear about it before you write a rule.

The scan was seeded with 3,963 known lexical indicators — ignore previous instructions and thousands of generated variants — matched with Aho–Corasick across the corpus. That method finds what it is looking for. The authors are explicit that it “may not capture all variants, such as highly obfuscated or non-English prompt injections,” that Common Crawl “may underrepresent authenticated or platform-restricted content,” and that the result “should be interpreted as a lower bound estimate of prompt injection prevalence.” So 51.2% describes the composition of the detected corpus. It is not the distribution of prompt injection on the web, and it would move if the indicator list changed.

The validation is asymmetric in a way that matters, because the header half is the majority category. Body candidates went through a five-step review — sampling for recurring benign classes, group-level labeling, representative page review in a browser, priority review of concealed prompts, then instance-level review of whatever was left. Header candidates did not. The paper’s first validation rule is to “conservatively treat matches in HTTP response headers as true positives, because strings matching our indicators in header fields are highly unlikely to be part of standardized Web protocols.” That reasoning is plausible, because such strings are unlikely to turn up incidentally in a response header — though test endpoints, research systems, and copied configurations are all conceivable ways one could. It remains acceptance by rule rather than the context-sensitive validation the body candidates got.

The three data sources are also not equivalent, which breaks the prevalence arithmetic if you mix them. Common Crawl was the one source not prefiltered by indicator — but it is still a large, incomplete sample rather than a probability sample of the web: roughly half of the October 2025 crawl, 1.2 billion URLs across 24,834,442 hosts, with the authors noting that crawls miss unlinked, authenticated, and platform-restricted content. Censys and Shodan contributed 3,346 snapshots already selected because they matched an indicator, and nearly all of them validated.

That asymmetry wrecks any host-level base rate computed off the combined total. Censys reports 1,700 affected hosts and Shodan 155, but the paper does not publish how those overlap with each other or with Common Crawl — and we know overlap exists, because the per-source host counts sum to 2,140 against a stated total of 2,042. The supplemental sources therefore represent somewhere between 1,757 and 1,855 distinct hosts, call it 86% to 91% of the total. Either way, dividing 2,042 by the Common Crawl host population mixes a numerator drawn from three sources into a denominator drawn from one. The defensible figures come from the Common Crawl portion alone: 285 of 24,834,442 hosts and 9,676 of roughly 1.2 billion URLs carried a validated instance — about 0.00115% of hosts and 0.00081% of URLs. Note that the seven-fold correction applies to the host rate specifically, where the mixed numerator inflates things badly; the URL rates differ by only about 21%, because pages are not concentrated the way scanner-discovered hosts are. One more wrinkle if you go to the source: Table 1 puts the Common Crawl page count at 9,676, while the persistence analysis baselines on 9,681. The paper does not explain the five-page difference.

The paper doesn’t establish whether the header half is defensive, benign, or malicious

Provenance across the corpus is 79.9% first-party, and the largest defensive objectives are data protection at 26.6% and AI bot identification at 20.1%. Read those shares as overlapping labels rather than slices of a pie — the coding is multi-label, which is why system disruption at 57.8% plus these two plus the underspecified remainder comfortably exceed 100%. And only part of this is the “do not train on this content” material you are picturing. Data protection splits into personal-information restrictions, copyright assertions, and social-media-bot rules; AI bot identification is something else entirely, mostly challenge-response tests along the lines of “if you are an AI, include this word in your response,” plus a smaller set of honeypots. The copyright slice is the robots.txt with delusions of enforceability, bolted onto an nginx config by someone who read a blog post about AI scrapers. The challenge-response slice is a site actively trying to catch you.

Two things stop that from settling the question. First, the paper’s single largest objective category is system disruption and degradation at 57.8%, and the paper files it under offensive, not defensive — the bulk of it is garbage injection intended to corrupt or pollute automated processing with random output, repeated nonsense, or pseudo-command payloads like DROP TABLE USERS CASCADE. First-party does not mean benign, and it is not forensic attribution either: the label says the string appeared in site-operator-controlled content rather than user comments or platform-hosted third-party material. It does not tell you who actually inserted it, which leaves compromise, delegated administration, plugins, and injected ad or analytics code all sitting inside the “first-party” bucket. Second, and more directly: the paper reports provenance and objectives against the whole corpus. There is no header-by-provenance or header-by-objective cross-tabulation anywhere in it. The inference that the header subset is mostly webmasters rather than mostly adversaries is a reasonable reading of the namespace conventions — X-AI-License and X-AI-Overlords do not read like an intrusion set — but it is a reading, not a measured result. Write your triage around that uncertainty rather than assuming the benign case.

The high-severity examples documented in the sources reviewed here are body-, metadata-, attribute-, comment-, CSS-, or script-borne — which is not the same as establishing that no hostile header-borne example exists anywhere. Forcepoint’s X-Labs documented ten live payloads, as Help Net Security reports, including one carrying “a fully specified PayPal transaction and step-by-step instructions designed for AI agents with integrated payment capabilities,” and another using meta-tag namespace injection with a persuasion amplifier to route AI-mediated financial actions to a Stripe donation link. Note the verb: these are instructions aimed at agents, discovered on live infrastructure. Neither Forcepoint’s writeup nor the reporting on it establishes that an agent obeyed one or that a transaction completed. That does not make them harmless, but it does mean the honest claim is intent plus reachability, not demonstrated impact. None of this establishes that malicious intent concentrates in the body either — no source publishes a delivery-surface-by-maliciousness table. What it establishes is that the body is where the documented high-severity examples have surfaced so far.

Unit 42 catalogued 22 distinct payload engineering techniques from production telemetry; its prose puts visible plaintext at 37.8%, HTML attribute cloaking at 19.8%, and CSS rendering suppression at 16.9%. That middle number is worth a footnote if you plan to cite it: the accompanying pie chart labels attribute cloaking 18.6%, not 19.8%, so the source disagrees with itself. The arithmetic favors the prose — the chart’s seven segments sum to 98.8% as labeled, and to exactly 100.0% if you substitute 19.8%, which makes the chart label look like the typo. Their most useful finding for a detection engineer is that 85.2% of observed jailbreak framing was social-engineering style rather than syntactic override — a category that spans authority override like god-mode and developer-mode framing, DAN-style persona creation, purported security notices, and requests dressed up as legitimate testing or compliance work. Your regex for ignore previous instructions catches the amateurs, and the study’s keyword-first methodology means the corpus is biased toward exactly those amateurs. Unit 42 is also careful about impact: it states it is “not aware of any confirmed real-world instances where such an attack has been successfully demonstrated against deployed ad-checking agents.”

Google’s crawl-scale view agrees on the direction and disagrees on the panic level. Their April writeup reports a 32% relative increase in the malicious category between the November 2025 and February 2026 Common Crawl snapshots — each of which holds roughly two to three billion pages from the predominantly English-speaking public web, though Google does not say it processed every page in every snapshot. It notes that observed sophistication “seemed much lower” than published research and that attackers have “yet not productionized this research at scale.” Read the scope with the claim: that is Common Crawl, which skips login walls and anti-crawl directives, so it says little about restricted or authenticated environments. It is a statement about what is visible in the open crawl today, not about what exists.

Why the low compliance rate is not the reassurance it looks like — and not the alarm either

The paper ran 5,200 trials — 100 prompts across four page representations against 13 models — and got compliance rates a vendor would love: 3.9% for content presented as plain text, 1.1% each for HTML and page snapshots, and 0.2% for raw HTTP responses.

The ordering is the interesting part, and it is also where the draft of this argument that everyone repeats goes wrong. Yes, the representation with the highest compliance is plain text and the lowest is the raw response, and yes, plenty of RAG and agent pipelines normalize fetched content to markdown or text before the model sees it — though the representation varies by product and configuration, and several retrieval services will hand you cleaned or raw HTML if you ask. But the same experiment recorded error rates alongside compliance: 25.8% for raw responses and 20.3% for HTML, against 0.7% for plain text and 3.5% for snapshots. Those errors are context-window failures — raw responses and HTML are simply longer, and they blow past some models’ limits. The authors put it plainly: “lower attack-effectiveness on HTML and raw inputs should not be interpreted as better resistance to prompt injection; in many cases, the model simply fails before producing a usable output.”

So the honest version is narrower and more useful than “flattening moves you into the worst bucket.” Flattening strips the structural cues — markup, comments, styling, response context — that let a model notice a prompt was hidden, and in this experiment that correlated with higher compliance. It does not follow that raw HTML is a protective format; a quarter of the time it just broke the model. And the experiment was one fixed task, single-turn webpage summarization, with the authors noting that other tasks, longer interaction settings, or proprietary processing pipelines “may exhibit different levels of susceptibility, in either direction.” Test your own extraction and prompting configuration rather than adopting a ranking measured on someone else’s task.

Model size stacks on top. Small models complied at 4.2% overall and 8.0% on plain text; medium at 0.6%, large at 1.2%, closed-source at 0.6%. Detection rates run the same way and worse: closed-source models flagged 25.1% of injections, medium 20.7%, large 13.8%, small 4.8%. And detection is not resistance — the researchers logged six cases where a model explicitly identified the injection and followed it anyway.

That size gradient is the basis for a real architectural concern about cheap pre-summarizers: put a small model first to compress fetched pages for an expensive one, and you have placed the most compliant and least perceptive component at the point where provenance is easiest to lose, since its output arrives downstream wearing the costume of trusted internal content. Be clear that this specific hypothesis is not a result from this paper. It measured direct responses from individual models; it never fed one model’s summary to another, and it did not show that detection opportunities vanish after summarization.

Other work has measured the chaining question directly, though, and the results argue for taking it seriously. Wang and Zhang’s “Kill-Chain Canaries” tracks a cryptographic token through four stages — exposed, persisted, relayed, executed — across 950 runs, five frontier models, six attack surfaces and five defense conditions. Their point is that binary “did the attack succeed” testing hides what you actually need: every model was fully exposed, but outcomes diverged sharply downstream, with Claude blocking every injection at the memory-write boundary (0 of 164) while GPT-4o-mini propagated at 53%, and DeepSeek producing 0% on one surface and 100% on another. Their conclusion reads as a design instruction — write-node placement is the highest-leverage safety decision, and routing writes through a verified model eliminated propagation. Two of their other findings land squarely on this post’s thesis: all four tested defenses failed on at least one surface through channel mismatch alone, with no adversarial adaptation required, and invisible whitefont PDF payloads matched or exceeded visible-text success, so screening the rendered layer is not sufficient. That is a different architecture from the cheap-pre-summarizer case, so treat it as evidence the risk class is real and measurable rather than as a number that transfers to your stack. Screen the raw fetch rather than only the summary, put a verified model on the write node, and measure your own pipeline.

One more number from the same paper that changes planning: among injection-bearing pages that could be retrieved from the Internet Archive, 93.1% already carried the injection three months earlier, 77.3% at six months, and 65.8% at twelve. Read the conditioning — those are percentages of successfully archived pages, not of all pages, and the horizon is twelve months at page level. The paper does not measure multi-year persistence, and it does not evaluate host blocklists at all. What it supports is that these strings are durable enough that a host you flagged last quarter is a reasonable place to look again, which is unusual in a field where most indicators decay in days. Whether blocking that host is precise enough to be safe is a question you have to answer with your own data.

Getting the event into an index at all

You are unlikely to get arbitrary response headers out of your existing network telemetry, though this is product- and configuration-specific enough that you should check rather than take my word for it. Many default proxy and gateway log schemas record request metadata and response status without capturing every origin response header. If you are running a service mesh, Envoy and Istio access logs can record response headers — but the format directive names each one explicitly, as %RESP(header-name)%. That is fine for confirming a header you already know about and useless for discovering field names you have never seen, which is the actual task here. Enumeration needs application instrumentation or a proxy filter.

So instrument the fetch tool. One structured event per retrieval, emitted from the agent framework’s HTTP client:

sourcetype=agent:fetch
  session_id, trace_id, span_id, parent_span_id, seq,
  turn_index, url, host,
  resp_header_names (multivalue), unexpected_header_count,
  scan_verdict, scan_rule_id,
  content_type, raw_bytes, extracted_bytes, extract_sha256

Note what is and is not in there. Header names are inventory: they tell you a field arrived that you did not expect, which is a hygiene signal about your transport metadata. They cannot tell you whether an injection is present. X-AI-Instructions can carry a perfectly ordinary licensing string, and a boring registered field can carry attacker-controlled text — the IANA field registry tracks both permanent and provisional names and has never been a security allowlist. Classification has to come from scanning the value. So run a bounded scan of normalized header values before ingestion, emit the verdict and the rule that fired as scan_verdict and scan_rule_id, and keep raw values out of the index by default. Header values are variable-length attacker-controlled text: HTTP defines no universal maximum, and while every real implementation imposes its own per-field and aggregate limits, those are the origin’s choices and its client’s, not yours. Enforce explicit per-field and total caps in your fetch layer before you normalize, scan, or retain anything, then store hashes and bounded extracts and pull full values on demand from a short-retention tier. You will regret full-cardinality retention the first time a host returns a 40 KB header.

The triage search compares header names against an exact set of fields your pipeline permits, anchored at both ends. Treat the list below as a deliberately minimal illustration and not a production allowlist — it omits cookie, authentication, CORS, security-policy, content-disposition, content-range, and alt-svc fields among many others, and shipping it as written would turn ordinary web behavior into a firehose of novelty alerts. Build the expected set from your actual fetch client and workload:

sourcetype=agent:fetch
| eval unexpected=mvfilter(NOT match(resp_header_names,
    "(?i)^(content-type|content-length|content-encoding|content-language|date|etag|last-modified|cache-control|expires|vary|server|location|link|age|retry-after)$"))
| where mvcount(unexpected)>0
| stats count, dc(url) as urls, values(unexpected) as hdrs by host
| sort - count

Exact match, both anchors, and a set you maintain deliberately. Do not reach for prefix matching — a content- prefix exempts an attacker-chosen Content-AI-Instructions, and a cf- prefix exempts anything a host cares to name that way. The output is a list of fields outside your permitted set, which is a starting point for review, not a list of confirmed injections.

Expected volume is genuinely hard to forecast, and the base rate above is the reason to distrust any number I could give you. In the non-indicator-prefiltered Common Crawl portion roughly 0.0008% of URLs carried a validated instance; 20,000 randomly distributed fetches a day would imply well under one affected page. Real agent workloads are not randomly distributed — they hit a narrow set of domains repeatedly, and the corpus is brutally power-law, with one host carrying 2,180 separate injections. Your volume depends on which sites your agents actually retrieve and how often, so measure it rather than budgeting from this study.

Triage converges faster than you would expect, with a caveat about method. There are 363 distinct lexical templates in the whole corpus and the top 54 of them (14.8%) cover 95% of all instances. But the paper produced those by normalizing strings and clustering them on token-overlap similarity at a 0.75 threshold, not by hashing. A literal hash of the normalized string groups only exact matches and will fragment the families the clustering merged. Use normalized-template or semantic clustering if you want a comparable reduction, and expect the remaining 5% to still spread across roughly 309 low-frequency templates, 144 of which appear exactly once.

The rule that actually earns its keep

Header presence alone is a hygiene signal. The detection worth paging on is correlation: content classified as injection-bearing — by a value scan, or by a template hit on the extracted text — followed in the same session_id by a policy-relevant action. Outbound email, payment initiation, recursive delete, credential or secret read, code publication, privilege change. That is the shape of the PayPal payload Forcepoint documented, and it is the version of this that maps to a real impact.

Two corrections to how that rule usually gets written. It should not be scoped to the first use of a tool in a session — nothing in this research suggests exploitation is confined to a first invocation, and an agent that has already sent mail once is not thereby safe. And temporal adjacency is not causation, so preserve enough of the model’s decision trace to tell an injection that steered an action from an action that merely happened next. Separately, do not let the tool-call framing become your whole threat model: the dominant objective in the corpus is degrading and polluting output, and a biased summary, a suppressed result, a forced citation, or a falsified answer is a real harm that invokes no privileged tool at all. Those need content-side monitoring, not correlation rules.

Do not let _time be your ordering mechanism. Correlate on a session or trace ID, give every fetch and tool call its own operation or span ID, record parent-child relationships between them, and carry a per-operation sequence number; keep timestamps as secondary evidence. A turn index alone is not enough, because a single model turn can issue several fetches and tool calls at once, and parallel branches under the same turn need explicit parentage to reconstruct what actually caused what. This is ordinary distributed-tracing structure, and the reason you need it is not exotic clock drift — containers inherit the node’s system clock, and chrony belongs on the node, not in a per-pod sidecar. The reason is ordinary distributed-systems behavior: your fetch workers and orchestrator are separate processes, often on separate nodes, and asynchronous emission, retries, buffering, and network delay will reorder sub-second events even when every node is properly synchronized. Nobody notices a correlation rule that stopped firing.

False positives, in roughly the order they will hit you: security research blogs, including this one; the OWASP LLM Top 10 pages; GitHub issue threads discussing injection; your own red-team eval corpora if they live in an indexed repo; and LLM vendor documentation, which quotes example payloads verbatim. Google hit exactly this problem at crawl scale, reporting that “many prompt injections were found in research papers, educational blog posts, or security articles discussing this very topic,” and solved it by classifying context rather than trusting domains. Do the same: tag known test corpora, documentation paths, and approved research repositories as contextual exceptions. Do not blanket-suppress your GitHub Enterprise instance or the security-vendor domains — those hosts carry user-controlled issue text, third-party content, and occasionally compromised pages, and a domain-level carve-out is a permanent hole in exactly the places your engineers point agents at.

There is a coverage gap worth naming. If your agents fetch through Firecrawl, Tavily, Exa, or Jina Reader, you are working from the vendor’s normalized output. Their documented formats center on markdown or extracted text — Firecrawl also offers cleaned and raw HTML, and Exa has returned clean markdown by default since June 2025 but hands back raw HTML, unprocessed, with includeHtmlTags=true — and none of them documents returning arbitrary origin response headers. So you likely get the header channel removed for free, and you lose visibility into it. What none of them documents is header omission as a security guarantee, or any equivalent handling of body-borne instructions, which is the question their marketing pages do not answer. Test it and put it in the questionnaire rather than assuming either way.

What to actually change

Fix the serialization boundary, not the protocol. Omit transport headers from model context by default and project only the metadata you actually need — content type, status, final URL — into typed, provenance-marked fields. Applied to this corpus that would have kept all 7,887 header-borne instances out of the prompt, which is the accurate way to state the win. It is not “half your exploit risk,” since registered fields can carry attacker-controlled values too, and some non-standard headers are operationally required by your HTTP client even though they should never reach a model. Stripping headers at the fetch boundary changes protocol handling to solve a prompt-construction problem; governing what gets serialized solves it where it lives.

On flattening, the instruction is not “stop.” It is: preserve provenance, trust labels, and the instruction-versus-data boundary through extraction, so the model has something to reason about, and evaluate both raw and normalized representations against your own task rather than trusting a ranking from someone else’s. And treat structured data deliberately — 1,996 instances rode in JSON and XML structured data. If nothing downstream consumes it, drop it. If something does, parse the schemas and fields you expect instead of passing an arbitrary JSON or XML blob into the context window.

Then the boring one that matters most: the agent processing untrusted web content should not hold the credential that sends mail or moves money. If it does, no input filter you deploy is load-bearing.

The table below is my own mapping, offered as implementation rationale rather than an authoritative crosswalk. NIST is explicit that mappings like this are subjective and do not establish control equivalence, and applicability depends on your architecture, authorization boundary, and selected overlay.

On the compliance side, the honest answer is that authoritative guidance is not there yet. NIST AI 100-2e2025 gave the field a shared taxonomy in March 2025. The COSAiS overlay project published a concept paper in August 2025 and released an annotated outline in January 2026 that lays out the whole series: NISTIR 8605 for overview and methodology, then 8605A for predictive AI, 8605B for generative AI, 8605C for AI developer controls, and NISTIR 8605D, “Using Agentic AI: Single Agent and Multi-Agent” — the volume that would actually speak to this, and note that it covers both single- and multi-agent cases in one document. The published schedule has 8605 and 8605A going out as drafts for public comment by Q3 FY2026, additional volumes drafting “through 2026 and 2027,” and the full series finalized “in 2027, pending available resources.” So the identifier and the target year both exist; what does not exist yet is any draft text for the agentic volume. Read that timeline as a development plan rather than a delivery commitment — NIST attaches the resource caveat itself. The practical consequence is that if you are asked about agent input validation before 8605D lands, you are arguing from the base catalog and your own architecture.

The CSA’s research note makes a related point about tracking, relaying a statistic from the OWASP GenAI Security Project’s Q1 2026 Exploit Round-up: of eight major AI-related incidents documented between January 1 and April 11 2026, exactly one — Flowise, CVE-2025-59528 — carried a CVE identifier; the rest, in CSA’s words, “stemmed from misconfiguration, excessive agency, supply-chain failure, or prompt injection.” The useful conclusion is not that seven identifiers went missing. Most of those categories are not patchable product defects and were never going to get one. It is that a program keyed only on CVE feeds will miss much of this risk class — particularly the incidents rooted in misconfiguration, excessive agency, supply-chain process failure, or adversarial content rather than a discrete product defect. Product vulnerabilities in adjacent agentic chains do still get identifiers, as Flowise shows. CVE tracking stays necessary; it just stops being sufficient, so you need configuration, behavioral, and architectural tracking running beside it.

The serialization boundary is the cheapest thing on this list to fix and the easiest to prove you fixed. Do that this week. Then go find out what your own pipeline does to provenance between the fetch and the model, because that is where the interesting failures live and it will take a lot longer than one config change.

Sources

• Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives (arXiv)
• Kill-Chain Canaries: Stage-Level Tracking of Prompt Injection Across Attack Surfaces and Model Safety Tiers (arXiv)
• AI threats in the wild: The current state of prompt injections on the web (Google)
• Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild (Unit 42, Palo Alto Networks)
• Indirect Prompt Injection in the Wild: X-Labs Finds 10 IPI Payloads (Forcepoint)
• Indirect prompt injection is taking hold in the wild (Help Net Security)
• Indirect Prompt Injection Goes Operational (Cloud Security Alliance)
• SP 800-53 Control Overlays for Securing AI Systems: Publications (NIST CSRC)
• Control Overlays for Securing AI Systems (COSAiS) project (NIST CSRC)
• COSAiS: Using and Fine-Tuning Predictive AI — Annotated Outline, January 2026 (NIST CSRC)
• Getting Envoy’s Access Logs (Istio)
• Hypertext Transfer Protocol (HTTP) Field Name Registry (IANA)

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.