Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Why is every prompt injection that gets caught hidden in the HTML, not in the text?

The payload survives because extraction pipelines strip the tags and keep the words. People review what a page renders; a model reads what was served, so an instruction in a comment, an attribute or a hidden element reaches the model and never reaches a reviewer. Cleaning text after extraction promotes the hidden layer into the visible one.

Visible browser content and underlying document layers feed an inspection filter.

The payload survives because extraction pipelines strip the tags and keep the words. People review what a page renders; a model reads what was served, so an instruction in a comment, an attribute or a hidden element reaches the model and never reaches a reviewer. Cleaning text after extraction promotes the hidden layer into the visible one. The injections a practitioner catches are hidden in the HTML because that is where an attacker can place instructions that a person will never see but a machine pipeline will still read. Visible page text is reviewed by people, moderated, and rendered in a browser. Markup, comments, attributes, metadata, and style controlled elements are not. When an agent or a summarizer ingests the raw source, the hidden layer becomes part of the model context. The gap closes when the model is fed what the page renders, untrusted content is marked as data, the agent's reach is limited, and render-layer tokenization keeps real identifiers out of the model, so a successful injection collects tokens. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Prompt injection is ranked first in the OWASP Top 10 for LLM Applications, as LLM01 in the 2025 edition, and OWASP distinguishes direct injection typed by a user from indirect injection planted in external content the model later reads (OWASP, 2025).
  • Indirect prompt injection was formalized in peer reviewed research showing that instructions planted in retrieved material can compromise real LLM integrated applications without the attacker ever joining the session (Greshake et al., 2023).
  • Palo Alto Networks Unit 42 reported web based indirect prompt injection observed in live telemetry, with delivery methods grouped into visual concealment, obfuscation, dynamic execution, and URL manipulation (Palo Alto Networks Unit 42, 2026).
  • Concealment works because many extraction pipelines strip tags and keep text. Removing a tag does not remove the words inside an element that CSS made invisible, so a hidden instruction survives as ordinary text in the extracted result; every visual concealment method Unit 42 lists is a presentation instruction, and none deletes the text (Palo Alto Networks Unit 42, 2026).
  • The reliable fix is architectural, not lexical: feed the model what the page renders, mark untrusted content as data, limit what the agent can do, and require approval for consequential actions (Microsoft Research, 2024).

What is the difference between what a page shows and what a model reads?

A browser is a rendering engine. It applies styles, layout, scripts, and visibility rules, then presents a finished page to a person. A language model pipeline usually does something different. It fetches the document, parses the document object model or the raw markup, extracts text nodes, and assembles those nodes into a prompt. Those two processes can produce very different versions of the same page.

The difference matters because a model does not see a page. It receives a sequence of tokens with no inherent record of whether each token was large or tiny, on screen or off screen, written for a reader or left in a comment. NIST describes prompt injection in its adversarial machine learning taxonomy as a problem of the generative AI pipeline, with direct and indirect forms treated separately because the delivery channel differs (NIST, 2023). In the indirect form, the attacker controls a resource the system reads, not the conversation itself.

Take a product page. A person sees a title, a price, and a short description. The source may also contain a comment with an instruction, an attribute describing an image in imperative language, a block set to zero size, and a footer element pushed far off screen. If extraction collects every text node, the model receives the visible description and those extra instructions together, in one undifferentiated stream. The model has no visual system telling it that part of the stream was never displayed.

Not every pipeline makes this mistake. A pipeline built on rendered screenshots, or on an accessibility tree that respects visibility, will usually drop elements that are not presented. A pipeline built on raw HTML, on a readability extractor that ignores style, or on a search index built from source text will usually keep them. The question in the headline is therefore partly a question about tooling: practitioners who catch injections in HTML are often looking at systems that read source rather than presentation.

Which hiding places in HTML carry an injection?

Unit 42 grouped the delivery methods it observed into a small number of families, and that grouping is a useful checklist for reviewers (Palo Alto Networks Unit 42, 2026). Visual concealment hides text from a human viewer while leaving it in the document: zero font size, zero line height, a container with zero height and hidden overflow, off screen positioning with large negative coordinates, display set to none, visibility set to hidden, opacity set to zero, and text colored the same as its background. Each of these is a presentation instruction. None of them deletes the text.

Obfuscation hides the payload from parsers and filters rather than from eyes. Instructions can sit inside HTML comments, inside attribute values such as image descriptions or data attributes, inside elements that conventional parsers skip, or encoded so that a simple keyword scan finds nothing recognizable. Payloads can also be split across several elements so that no single element looks like a complete instruction, then reassembled when the text nodes are concatenated in document order.

Dynamic execution takes the payload out of the static source altogether. A script can insert instructions into the page after load, so a fetch of the original HTML shows nothing while a headless browser that runs the script receives the full text. URL based delivery places instructions in a fragment or query component of a link the agent is asked to open, so the malicious content arrives with a page that is otherwise legitimate.

Character choice is another hiding place. Zero width characters, homoglyphs that look like ordinary letters, and instructions repeated in several languages can make a payload hard to spot in a source view while still legible to a model that tokenizes the raw characters.

Why does visible text rarely carry the payload?

An attacker who writes an instruction in visible text gives up three advantages. First, concealment: a person reading the page, a moderator reviewing a listing, or a site owner checking their own content can see the instruction and delete it. Second, deniability and persistence: visible text is attributed to the page author in a way that hidden markup often is not, and it competes with the real content for space. Third, effect: a visible instruction addressed to an AI reader looks out of place to human visitors and can reduce trust in the page, which matters when the underlying goal is commercial, such as steering a shopping or review agent.

Visible placement also faces ordinary content controls. Marketplaces, review platforms, and content management systems screen visible submissions for spam and abuse, and a sentence telling an automated reader to approve a listing or recommend a product is exactly the kind of text those screens are built to catch. Markup fields, metadata, and comment areas are screened far less consistently, because they were designed for machines and site operators rather than for publication.

Many indirect attacks are not aimed at the page owner at all. Greshake and co authors described attackers planting instructions in material that a victim application will retrieve, so the person who suffers the disclosure or the unwanted action is a user of the application, not a visitor to the page (Greshake et al., 2023). In that threat model, the page is a delivery vehicle, and keeping the payload invisible keeps the vehicle looking normal to everyone except the one reader the attacker wants to influence. Visible injections do still exist, in reviews, posts, resumes, and documents. The pattern in the headline is a selection effect: visible payloads are removed by visible review, hidden payloads are found later by people inspecting source, logs, or model behavior.

Why do scanners and reviewers keep missing it?

Keyword scanning fails for structural reasons. A scanner that looks for phrases such as an instruction to ignore earlier directions will miss paraphrases, translations, encodings, and payloads that contain no suspicious phrase at all. An instruction to send a copy of a record to an address is ordinary English. Its malice comes from its provenance, not its vocabulary. Classifiers trained on wording therefore have little to work with when the payload is a plausible business instruction placed in the wrong location.

Review workflow is a second failure point. Human reviewers are usually shown the rendered page, a screenshot, or a cleaned text preview. All three remove exactly the material the attacker used. A reviewer who wants to find hidden payloads has to inspect source, compare extracted text against rendered text, and diff the two. That is a deliberate forensic step, not a natural part of content review, and few review tools present the difference automatically.

A third failure is inconsistent extraction across a stack. A security team may test the crawler, while the production agent uses a different summarizer, a different browser configuration, or a fallback that returns raw HTML when rendering fails. The payload only needs one path that keeps it. Testing has to cover the actual ingestion path, including fallbacks, timeouts, and the text produced by scripts after load.

Finally, logs often hide the evidence. If a system records only the final answer and the URL visited, an investigator cannot tell which part of the page influenced the model. Recording the exact extracted text that entered context, with its source location, turns a puzzling answer into a diagnosable incident.

What controls actually reduce the risk?

The first control is to ingest presentation rather than source where the task allows it. Dropping elements that are not rendered, stripping comments and non content attributes, and normalizing hidden characters removes the concealment layer before the model is involved. This is a deterministic transformation, and it can be tested with fixtures: a page whose hidden block contains a unique marker should produce extracted text with no marker. Where a task truly needs source, for example code review, that need should be explicit and the resulting content should be treated as untrusted data throughout.

The second control is to mark provenance. Microsoft Research proposed spotlighting, a family of transformations that delimit, mark, or encode untrusted input so the model can distinguish it from instructions, and reported substantial reductions in attack success on the test sets used in that work (Microsoft Research, 2024). Marking is not a guarantee, and later adaptive attacks degrade prompt level defenses, so it belongs in a layered design rather than standing alone.

The third control is to limit consequence. OWASP advises constraining model behavior, separating privileges, and keeping a human in the loop for sensitive actions, because no input filter is complete (OWASP, 2025). An agent that can read a page but cannot send mail, move money, change records, or reveal credentials without approval turns a successful injection into a contained event. Least privilege per task, short lived credentials, and allow listed destinations all shrink what a hidden instruction can achieve.

The fourth control is detection aimed at provenance rather than wording. Comparing rendered text with extracted text, flagging elements hidden by style that contain imperative language, and alerting when an agent attempts an action that no user instruction supports are signals tied to the mechanism of the attack. They will still miss cases, but they fail in different ways from a keyword filter, which is the point of layering.

Where does RedactSure sit?

RedactSure is built on the rendered side of the gap. Its supervised AI co-workers work from applications as rendered inside a governed environment, with no per-application integration and no change to user permissions, so the model is handed the task's fields rather than the served source. Policy chosen values are already tokens before any model reads the screen: the model works with ACCT_001 and PATIENT_001, and real values resolve only at approved destinations at the moment of an approved action. A successful injection therefore collects tokens and the remaining task context rather than real values.

The consequential action the injection wants, a message sent, a record changed, a payment released, still stops for a named person's approval under Supervised Delegation. The Planner sets which values are tokenized and what the agent may do on each screen, and a named person confirms that policy before the run. The attempt, the screen as tokens and the approval decision are written into the AI Control Record and exported to the customer's own SIEM. Keys stay with the customer and the model is swappable. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

The page rests on standards and taxonomy sources, peer reviewed and preprint research, vendor telemetry research and published defense research, all read as of October 13, 2026. OWASP's LLM01:2025 entry in the Top 10 for LLM Applications and NIST AI 100-2e2023, the adversarial machine learning taxonomy, supply the definitions and the direct and indirect distinction (standards and official guidance). Greshake et al. (arXiv:2302.12173, 2023, preprint) supplies the indirect prompt injection threat model. Palo Alto Networks Unit 42's "Fooling AI Agents" supplies the delivery method families observed in live web telemetry (industry analysis). Microsoft Research's spotlighting paper (arXiv:2403.14720, 2024, preprint) supplies the provenance marking defense and its reported results on the test sets used in that work.

The page is a synthesis of published findings, not a new measurement. No pages were crawled, no corpus of caught injections was supplied, and no frequency claim is made about the share of injections that are hidden in HTML. The headline describes one practitioner experience, and the sections explain mechanisms that would produce it, including selection effects in what gets caught. No hands-on testing of any named product, extractor or browser configuration was performed. Concealment techniques evolve, and counts reported by any single telemetry source reflect that source's network and time window rather than the whole web. Vendor features change; the page carries its date. The product page and marketplace examples describe page types, not any organization; no customer or prospect is described.

Whether any control, extraction method or review process meets an organization's requirements belongs to its counsel, its assessor and its security and compliance officers, not to this page.

What the record shows

The injections a practitioner keeps catching live in the HTML because attacker and defender look at different pages. People review what renders; pipelines read what was served, and markup, comments, attributes, and hidden elements let an instruction exist for the machine while staying invisible to every human who approved the page. Stripping tags does not rescue the pipeline, since words inside hidden elements survive as plain text. Testing the extraction pipeline, comparing what the system feeds the model against what a person sees, exposes that difference.

Frequently asked questions

Why does stripping HTML tags fail to remove the payload?

Because stripping removes the markup, not the words it contains. An element hidden with styling still holds its text, and once the tags around that text are discarded, the extraction result keeps the instruction as ordinary readable content with no marker that it was ever invisible. The pipeline has, in effect, promoted the hidden layer into the visible one. Defenses have to decide visibility before or during extraction, using how the page renders, rather than cleaning text afterwards.

Which parts of a page can carry a hidden instruction?

The parts of a page a reader never reviews: HTML comments, element attributes, metadata, and text placed inside elements that style rules keep off screen. Palo Alto Networks Unit 42 grouped the web based delivery methods it observed into visual concealment, obfuscation, dynamic execution, and URL manipulation. The common property is placement outside rendered view while remaining inside the source an agent or summarizer ingests.

Should reviewers inspect the raw source or the rendered page?

Both, because the attack lives in the gap between them. Reviewing only the rendered page shows the clean version a person approved. Reviewing only the source buries the payload among thousands of legitimate lines. Comparing the two outputs, what a person sees against what the extraction pipeline produces, turns an invisible instruction into a visible difference, and that comparison is the review step that the concealment methods documented by Unit 42 are designed to evade.

Does rendering the page in a headless browser solve the problem?

Partly. Rendering with an accessibility tree that respects visibility drops elements that are never presented, which removes the visual concealment family. It does not remove payloads inserted by scripts after load, delivered in a URL fragment, or written in zero width characters and homoglyphs, and it does not help if a fallback path returns raw HTML when rendering fails. Rendering is the first layer; provenance marking, limited consequence and detection on the mechanism are the others.

Can a keyword filter catch hidden prompt injections?

Rarely, and not reliably. A filter that looks for phrases such as an instruction to ignore earlier directions misses paraphrases, translations, encodings and payloads that contain no suspicious phrase at all. An instruction to send a copy of a record to an address is ordinary English; its malice comes from where it sits, not from its words. Detection tied to provenance, such as diffing rendered text against extracted text, fails in different ways from a keyword filter, which is why the two belong together.

What should an agent be allowed to do after reading an untrusted page?

Read, summarize and propose, not act. OWASP advises constraining model behavior, separating privileges and keeping a human in the loop for sensitive actions because no input filter is complete. An agent that cannot send mail, move money, change records or reveal credentials without a named person's approval turns a successful injection into a contained event. Least privilege per task, short lived credentials and allow listed destinations shrink what any hidden instruction can achieve.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.