Finding prompt injections
at web scale.

Why MLHouse

MLHouse researches how a shared data lakehouse can serve AI applications and autonomous agents as their questions and workloads change. Prompt-injection discovery, investigated with Ermes Cyber Security S.p.A., is a demanding case: detectors need new examples, but finding and reviewing those examples across billions of pages consumes substantial resources.

This report examines the cost of discovery, the performance of candidate-selection methods, and the effect of adapting an embedding model. The findings inform the proposed MLHouse architecture and the experiments needed to connect discovery to continuing detector improvement.

The economics of discovery

Building a detection system requires more than training on the attack patterns already in hand. We need to keep looking for emerging instructions, unfamiliar variants, and benign lookalikes, then use reviewed examples to improve the detector. This is why we want an indexed data lake: it lets us revisit an evolving collection with new questions and search for patterns we did not know to look for when the data was collected.

Every discovery round trades coverage and speed against compute and review cost. Reusable indexes let new questions revisit the collection, while selective model analysis supplies richer context for promising candidates.

Why one search method is not enough

Full-text search is the natural baseline for known wording. Once an index is built, new word and phrase queries can revisit the collection without running a language model over every document. Rules and regular expressions capture known signatures. The difficulty is specifying what to search for: an emerging instruction may use wording we have never observed, and listing every paraphrase, language, and combination of terms is impractical.

Task-tuned embeddings offer a way to search for related instructions. The aim is to bring passages with similar attack behavior closer together despite differences in wording or surrounding content. A vector index makes those representations searchable at scale. This motivates our fine-tuning experiments, but broad transfer across languages and unfamiliar attack families remains to be demonstrated.

Obfuscation can challenge both approaches. Encoded text or altered characters may obscure the signal from lexical queries and embedding models alike. It is a separate problem from ordinary multilingual or paraphrase variation. The proposed approach combines original and normalized representations, complementary retrieval methods, and selective model review; the held-out encoding experiment illustrates this limitation in the tested model.

What would an LLM pass over Common Crawl cost?

We use 2.10 billion page inspections, matching the approximate page count of the June 2026 Common Crawl release, CC-MAIN-2026-25. This gives us a concrete workload tied to the crawl used in our investigation. The archive count is a planning proxy for extracted-text inspections; it does not establish that every archived page has an eligible text record. [4]

The measured pipeline applies an LLM to every page. Its first pass uses gpt-oss-20b with input capped at 8,000 characters, low reasoning effort, and up to 512 generated tokens. It uses batched inference and prefix caching, with one model replica per H100 GPU. Only the 5,823 candidates out of five million pages (0.116%) receive the more detailed review by both gpt-oss-20b and gpt-oss-120b. This staged strategy concentrates the larger model's work on a small candidate set.

For a more expensive alternative, we also project applying the gpt-oss-120b review procedure to every page. That procedure uses four H100 GPUs, a different rubric, a larger input allowance, and up to 3,072 generated tokens. Its measured candidate-review throughput provides a basis for a cost scenario, although we have not run it over an unfiltered crawl.

The commercial compute equivalent uses US$3.99 per H100 SXM GPU-hour, a listed Lambda instance rate checked on 14 September 2026. It illustrates the value of the compute consumed; it is neither a matched-hardware performance benchmark nor a bill for our RES allocation. Cluster pricing and availability can differ. [5]

The 120B scenario extrapolates candidate-review throughput to an unfiltered crawl. The procedures differ, so these are not costs at equal detection quality. See cost assumptions and exclusions.

Reuse preparation across discovery rounds

The useful comparison is additional validated content per budget and response time over repeated searches. Index construction, encoding, refresh, model verification, and human review all count. Sampled model inspection can investigate regions that both lexical and vector queries miss; reviewed results then guide training and the next searches.

Data & experimental approach

The study examines the components needed for a continuing learning workflow. Broad model inspection establishes candidate examples and a compute baseline. Lexical and classifier experiments test inexpensive ways to select candidates. Controlled embedding experiments test whether training changes retrieval quality. The populations below answer different questions; they do not form one benchmark on which all methods can be ranked.

We use AI-directed content for text addressed to an assistant or automated reader. An injection attempt asks the system to treat instructions from that external content as authority over its task. A quoted prompt, a security tutorial, and an ordinary routing notice can resemble an attack without being one. Motive is a separate dimension: an instruction may seek promotion, obstruction, or harmful action.

The synthetic work uses injected content in clean host pages, including a 2024-46 Common Crawl source. Historical in-the-wild scans use a separate 2024-42 snapshot. The 2026 investigation uses CC-MAIN-2026-25. These populations are not interchangeable, even when they share a year.

What the models actually see

Common Crawl WET records provide extracted text, rather than the original HTML, headers, or rendered page. The five-million-page census reads raw WET files, but first-pass model inputs are still capped at 8,000 characters and fitted to a token budget. The logs show input truncation for 1,019,689 records, or 20.39%. Candidate adjudication returns to the source text with a larger, token-based allowance. The earlier indexed text surface was capped at 4,000 characters. Access to raw WET therefore improves available coverage without guaranteeing full-page inspection.

The census samples files and takes the first eligible records from each selected file, excluding very short text. This is not a uniform random sample of web pages. The second judge sees first-pass candidates only, so it cannot identify cases the first pass missed. The run also records 185 errors among the five million verdict records.

Position within existing research

Large-scale observation of web injections is already an active research area. Google's April 2026 study uses Common Crawl to investigate real-world instructions and their objectives. Khodayari and colleagues examine webpage and HTTP-response injections and separately test model behavior. Our contribution is to examine discovery as a recurring data workload: the cost of inspecting content, the limitations of candidate selection, and the evidence needed to improve retrieval and detection over time. [1] [2]

What we found in the wild

The observed instructions show why discovery needs both broad coverage and careful review. They span promotion, attempts to obstruct automated reading, and harmful requests. Similar wording also appears in benign demonstrations and published prompts. Those distinctions matter when discovered pages become training examples.

The five-million-page census produced 5,823 first-pass candidates. Adjudication confirmed 456 as AI-directed with the 20B judge and 375 with the 120B judge; 248 were shared. Agreement across candidate verdicts was imperfect, with Cohen's κ of 0.566.

The subsequent genre classifier selected 61 adversarial pages across 15 domains from those shared confirmations. Full-source review found three clear contextual false positives: a published model execution log, a security explainer, and a displayed red-team demonstration. A fourth page is a routing/attribution boundary case. Excluding all four leaves a proposed 57-page, 11-domain set under a broad convention that includes output-targeted promotion and anti-crawler overrides. This is a provisional review result, not a released, independently adjudicated gold standard.

What the instructions actually say

These short, verbatim excerpts reproduce page text captured in CC-MAIN-2026-25. The first four illustrate instructions retained under the broad review definition; the fifth was excluded after checking context. Links identify the original webpages, which may have changed since the crawl.

The provisional grouping contains 29 promotion, 27 deterrence, and one harmful-command page. Counts are concentrated by site and template: page totals should not be read as independent attack campaigns. More importantly, agreement between two model judges did not remove the need to examine original context.

Expanded patterns surfaced additional domains

A separate scan extended the earlier 31-rule baseline. Catalog reconstruction generated 32 patterns, then two revision rounds expanded the set to 44 and 57. The scan reports 64,765 raw hits across 51,128,154 pages. The selected review queue contains 1,520 hits from nine rules, covering 350 domains. Every domain in that selected group has a review label: 75 positive and 275 negative, with 68 of the positives marked absent from the census set.

Revised patterns produced additional candidates, but reviewing and labeling those candidates remains a substantial part of discovery work.

Evidence of growth, with incomplete visibility

Independent monitoring provides evidence of increased activity. Google reports a 32% relative increase in malicious-category detections between November 2025 and February 2026 across repeated Common Crawl scans. Its researchers also expect the scale and sophistication of attempts to grow, as more capable AI systems become valuable targets and automation lowers the cost of attacking them. The measured increase and the expectation of future growth are distinct claims. [1]

Our historical pattern scans reported zero confirmed adversarial cases among approximately 1.31 billion pages from 2024, compared with 21 among 14.6 million pages from 2026. These reported counts have not been independently reproduced. The contrast is consistent with increased activity, but differences in crawl populations, text coverage, sampling, and review prevent a controlled growth estimate. Zero detections in the earlier scan does not establish that attacks were absent.

Continued growth and diversification are reasonable planning assumptions; an exponential trend has not been established. Our detection experiments also miss known examples, so the observed cases form an incomplete inventory. The number of undiscovered attacks remains unknown. Together, these findings motivate continuous discovery and repeated evaluation as the threat changes.

Why models need adaptation

The two tested classifiers leave large review queues while missing reference cases. The results motivate adaptation to this workload and evaluation of the candidates each method actually selects.

The tested classifiers create substantial review work

At a 0.5 threshold on 500,000 pages, ProtectAI flagged 141,993 pages (28.40%) and PIGuard flagged 49,786 (9.96%). They recovered 6 and 10 of the 20 judge-selected reference cases respectively. Both leave a large queue for further analysis while missing examples already surfaced by the census.

The reference cases were discovered by the judge, not drawn from an independent complete attack set. Recovery here is conditional on those cases. Classifier-only hits were not comprehensively reviewed, so the flagged fractions are neither false-positive rates nor estimates of attack prevalence.

Patterns are useful, but the evaluation population matters

On the 4,014-row calibration benchmark, a normalized 40-term keyword detector recovers 418 of 2,003 positive rows (20.87%), with six negative rows flagged. Without normalization it recovers 257 positives (12.83%). On the same labeled benchmark, the census pipeline recovers 1,120 positives (55.92%). The language-model pipeline therefore has substantial misses even in this controlled setting.

These 40 keywords are a different detector from the structural regex set. Reapplying the expanded 57 patterns to the saved quote/evidence fields matches 276 of 456 positive 20B judgments (60.5%). Because those patterns were revised using observed misses, that result measures adaptation on the inspected data. It is not held-out, full-page attack recall.

Language models add context, but are not ground truth

The census can surface wording outside the fixed keyword vocabulary. Its remaining calibration misses, judge disagreement, and quoted-example false positives show why model outputs need source-context review before becoming training labels. An independent sample is also necessary to investigate what every candidate-selection method misses. Otherwise, a learning loop risks reinforcing its own blind spots.

A filter changes the population passed to the next model. Evaluate the downstream classifier on those actual candidates, including benign lookalikes, and count both missed cases and review effort.

Learning to retrieve

A vector index makes embedding representations searchable; the representation determines which passages appear similar. The experiment here tests adapting that representation to injection-like content. Weak base-model results concern the tested embeddings and retrieval task, rather than vector indexing as a technology.

We fine-tune BGE-M3 on synthetic injections. A deliberate overfit setting with shared payloads across different host pages is kept separate from an evaluation with disjoint payload text. The generalisation run uses 6,295 training pairs. Exact selected web-derived payloads and evaluation host IDs are absent from its training split.

For the web-derived evaluation, payloads are inserted into new clean host pages. The payload text itself becomes the query. Set A contains 106 usable records selected from AI-directed judgments whose quote/evidence text does not match the expanded patterns. Set B contains 36 selected representatives from the combined census and pattern-derived collection. Each set is searched separately against its injected targets plus one million clean distractor pages.

Fine-tuning improves the measured task. The targets are AI-directed records, not a uniformly validated attack set, and the query contains the target payload. A matched lexical baseline and stronger family holdouts are needed before drawing conclusions about new-attack discovery; see evaluation boundaries.

Obfuscation tests the representation as well as the retriever

A paraphrase or translation changes wording while preserving an instruction's meaning. Obfuscation can also change how that instruction is represented, through character substitutions, invisible characters, or encoded text. Semantic similarity alone does not guarantee that the embedding model will recover the underlying instruction.

The held-out base64 result makes this limitation concrete. When base64 wrapping is excluded from training, the saved evaluation reports recall@1 moving only from 0.1% to 0.2%. This particular result shows little transfer to the held-out encoding. The improvement in exact-payload retrieval therefore does not establish general resistance to obfuscation.

A proposed extension is to retain the original text alongside normalized or decoded views where applicable, then compare lexical and learned retrieval over those representations. Original context remains necessary to distinguish an attack from benign encoded content or a quoted example. Evaluation should report paraphrase, language, character-variation, and encoding holdouts separately, including the additional computation and false positives introduced by each transformation.

Implications for MLHouse

The findings motivate a shared, versioned data foundation that connects discovery, reviewed examples, model updates, and evaluation. It needs scans, SQL and aggregations, full-text search, vector search with different embeddings, summaries, and approximate query methods. Different access methods can contribute to the same task, with source records and transformations retained so results remain traceable.

The lakehouse must serve autonomous agents as well as people. Repeated agent requests can increase both workload volume and variety. Building every representation of every record would commit resources before its value is known. MLHouse therefore investigates how to select data subsets and access methods according to expected reuse, construction and maintenance costs, and quality and freshness requirements.

These are two connected learning loops. Detector learning changes how attacks are recognized; infrastructure learning changes how data is organized and served. A new embedding model may justify re-encoding selected records, while other subsets remain best served by a text index or occasional scan. Policies should compare the benefit across successive requests with the cost of building and refreshing those representations.

Toward continuous learning

The target is an automated discovery and detector-improvement workflow, with reviewed labels and evaluation before updates are adopted. Three experiments connect the present results to that system.

1. Run a matched discovery evaluation.Compare normalized lexical search, base and tuned embeddings, and selective model verification on the same source records. Use independently reviewed labels; separate known-payload lookup from queries defined before seeing targets. Hold out payloads, families, domains, languages, and encodings to measure additional validated discoveries beyond the lexical baseline.
2. Measure cost and improvement over successive rounds.Vary candidate budgets and review depth, train on new reviewed examples, and test each update against independent holdouts and later data. Count ingestion, encoding, indexing, refresh, unsuccessful runs, and human review. Report new discoveries and regressions alongside compute, latency, and reviewer time.
3. Test workload-driven lakehouse adaptation.Replay changing agent requests and compare fixed configurations with policies that selectively build or refresh indexes, embeddings, summaries, and samples. Measure total cost across the request sequence while holding quality and freshness targets constant.

Conclusions & limits

Broad model inspection surfaces useful cases at substantial compute cost. The tested classifiers miss reference cases and leave large review queues; adapted embeddings improve controlled retrieval but transfer poorly to an unseen encoding. These findings support complementary access methods and evaluated model updates, with costs measured across repeated discovery rounds.

Scope of the evidence

The report observes AI-directed instructions and apparent injection attempts, not demonstrated agent compromise. It does not establish global attack prevalence, a growth rate from our historical scans, or a validated cost advantage for the complete proposed system. Model-selected candidates, repeated sites and templates, truncated text, and unresolved annotation boundaries limit coverage. The provisional 57-page set and 75 positive-domain labels must not be added as independent counts of unique attacks.

Prompt injection makes the broader infrastructure requirement concrete: applications need to revisit data, discover new evidence, and evaluate changes as their needs evolve.

References

External research, funding information, and sources for the web-scale and compute-cost assumptions.

1. Brunner, Liu & Pande · April 2026AI threats in the wild: The current state of prompt injections on the web

   Google's Common Crawl monitoring reports a 32% relative increase in malicious-category detections from November 2025 to February 2026 and discusses the prospect of greater scale and sophistication. This external result is separate from the MLHouse measurements.

2. Khodayari, Zhang, Acharya & Pellegrino · April 2026Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives

   A large-scale empirical study of webpage and HTTP-response injections, with a separate model-impact evaluation.

3. ML House project support · CPP2023-010729AEI · CPP2023 award resolution · Funding acknowledgement guidance

   Official award information and funding-credit guidance for Spain's 2023 public–private collaboration programme.

4. Common Crawl workloadCommon Crawl · June 2026 release

   The June release, CC-MAIN-2026-25, contains approximately 2.10 billion archived pages. We use that count as the workload for the report's full-crawl cost projections.

5. Commercial GPU-price illustrationLambda · Published instance pricing

   Checked 14 September 2026: H100 SXM, 80 GB, eight-GPU instance, US$3.99 per GPU-hour before tax. Used only as a unit-price illustration; dedicated cluster prices, capacity, hardware throughput, and terms can differ. RES access is not invoiced at this price.

Data availability

MLHouse has created datasets for testing retrieval, detector training, and data-lakehouse workloads. The following resources are available to researchers upon request; for collections still in preparation, access covers the available portions.

Synthetic prompt-injection benchmark · Available

Paired clean and injected web content, with labelled payloads and injection locations, supports controlled detection and retrieval experiments. The benchmark covers instruction overrides, retrieval-targeted manipulation, data-exfiltration requests, and obfuscation variants. Modified chunks are re-embedded with BGE-M3.

Synthetic CRM lakehouse · Available

A Salesforce-shaped, multi-tenant corpus combines structured business records with synthetic emails, activities, and other text. Deterministic relationships and LLM-generated content support experiments with SQL, full-text search, vector retrieval, and lakehouse layouts across three workload shapes.

Common Crawl 2024 WET corpus · Embedded and indexed

The project's processed 2024 WET text corpus is embedded with BGE-M3 and indexed for retrieval experiments. It provides a reusable historical collection for searching web content and comparing access methods. This describes our processed research corpus, rather than a complete archive of the web.

Common Crawl 2026 WET corpus · In preparation

We are preparing an embedded and indexed collection from CC-MAIN-2026-25, the June 2026 snapshot used in this report. A portion is already available for experiments; processing and indexing of the wider collection are ongoing.

Collected prompt-injection attempts · In preparation

We are assembling a database of observed prompt-injection attempts, retaining source context and review labels to support analysis and future evaluation. The collection is being curated; inclusion records an observed attempt, not proof of successful agent compromise.

The larger indexed and embedded collections span dozens of terabytes, so we arrange access or transfer individually instead of providing direct downloads from this website. To discuss available versions and request research access, write to mlhouse@qbeast.io. The sharing offer does not include the partner-provided Ermes research sample.