TL;DR: A custom font plus CSS can make a webpage look benign to text-only AI assistants while rendering malicious instructions to users, and its tests found every non-agentic assistant failed to flag the trap, according to LayerX Security. That gap means security teams must treat rendered presentation, not just DOM text, as part of AI-assisted web review.
At a glance
What this is: LayerX Security shows that browser rendering can hide malicious instructions from AI assistants that only parse HTML, creating a social engineering blind spot.
Why it matters: IAM, security, and AI governance teams need to treat rendered presentation as part of the trust boundary when assistants are used to review web content or guide user actions.
Context
The security gap is simple: an AI assistant can analyse page text from the DOM while a human sees the browser's rendered output. When a page uses fonts and CSS to change visible meaning without changing the underlying HTML, the assistant and the user are effectively looking at different content.
That matters for AI-assisted review, because the control assumption is that the text the model sees represents what the user will see. LayerX Security's research shows that assumption can fail even when the browser is behaving normally and no script exploit is involved.
In identity and access workflows, this becomes a trust problem as much as a content problem. If an assistant is used to validate links, pages, or instructions before a user acts, the rendering layer itself becomes part of the attack surface.
Key questions
Q: What fails when an AI assistant reviews only DOM text from a webpage?
A: The assistant can miss malicious instructions that appear only after rendering, because the browser's visible meaning may differ from the HTML source. That creates a trust gap where the model approves content the user never actually sees. In practice, DOM-only review is insufficient for pages that use fonts, opacity, or CSS to alter meaning.
Q: Why do rendering-layer attacks create risk even without JavaScript or a browser exploit?
A: They exploit standard browser behaviour rather than code execution. If font mapping and CSS can change what the user sees, the assistant may validate the wrong content and recommend unsafe actions. The risk comes from presentation mismatch, not from a broken browser or a malicious script payload.
Q: How should security teams detect hidden instructions on web pages reviewed by AI tools?
A: Teams should compare the rendered page against the extracted source text, then flag large mismatches in visible language, hidden blocks, tiny text, or strange font behaviour. If the assistant cannot perform that comparison, it should avoid strong claims that the page is safe.
Q: What should organisations change in AI-assisted browsing governance after this kind of finding?
A: They should require rendering-aware review for any assistant that advises users on links, commands, or external pages. Governance should assume that visible meaning can be manipulated separately from DOM text, so the control boundary must include the browser presentation layer as well as the model input.
Technical breakdown
How font glyph substitution creates a rendering-layer payload
The technique uses a custom font as a substitution cipher at the glyph level. The HTML can contain one set of characters, but the browser maps those characters to different visible forms when it renders the page. CSS then hides the benign-looking text by shrinking it or matching it to the background, while the attacker-controlled instructions remain readable. This is not script execution and does not require a browser vulnerability. The semantic mismatch comes from the difference between DOM text and rendered presentation, which text-only assistants do not inspect by default.
Practical implication: review tools that only inspect DOM text cannot be trusted to judge what a user will actually see.
Why text-only assistants misread the page as safe
Non-agentic assistants typically fetch HTML, extract visible text from the source, and reason over that text without running a full rendering pipeline. In this attack, the benign fanfiction is what the assistant sees, while the malicious instructions are exposed only after font substitution and CSS rendering. That means the assistant's safety judgment is based on a partial representation of the page. The failure is structural, not model-specific: if the system cannot render and compare outputs, it cannot detect that meaning has been rewritten in the presentation layer.
Practical implication: safety review must include render-and-diff checks, not just source parsing.
Why this is a social engineering problem, not a browser exploit
The browser is not broken here. The page uses standard rendering behaviour in a way that changes meaning for the user while leaving the DOM unchanged for the assistant. That makes the attack a presentation-layer social engineering technique that can steer users toward unsafe actions such as running commands or following destructive instructions. The important distinction is that the payload is aimed at human interpretation through the browser, while the assistant becomes an unwitting validator because it evaluates the wrong layer.
Practical implication: user-facing AI safety guidance should treat rendered content as authoritative when the assistant is advising on web pages.
Threat narrative
Attacker objective: The attacker wants the user to trust malicious on-page instructions that the assistant failed to detect and then execute harmful actions on their own system.
- Entry begins when the victim or assistant loads a webpage built with benign-looking HTML, a custom font, and CSS that separates visible meaning from source text.
- Credential or instruction abuse occurs when the rendered page presents malicious steps that encourage the user to run commands, while the DOM presented to the assistant remains harmless.
- Impact follows when the assistant tells the user the page is safe, reinforcing the attacker's instructions and increasing the chance of harmful user action or data leakage.
Breaches seen in the wild
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Rendering mismatch is now an identity and trust problem, not just a UX quirk. When an AI assistant is used as a safety layer, the page it inspects must match the page a human will act on. LayerX Security's finding shows that DOM-only analysis can bless content that the user never actually sees, which means trust decisions are being made on an incomplete artefact. The implication is that AI-assisted review needs rendering-aware validation, not text extraction alone.
Prompt injection can live in the presentation layer without any exploit code. The article makes clear that the browser is functioning normally and the weakness sits in the assistant's analysis model. That collapses a common assumption in web security workflows: that source text is the same thing as user-visible meaning. For practitioners, the governance problem is that the review boundary has moved from code to rendered presentation.
Rendered meaning is a new control plane for social engineering. Fonts, opacity, size, and visibility are enough to change what the user perceives without changing the HTML the assistant reads. That creates a named concept worth tracking: rendering-layer trust gap: the difference between machine-parsed page content and human-visible page meaning. Security teams should treat that gap as a review failure mode in AI-assisted browsing and page inspection.
AI model security programs are currently mis-scoping a real user harm path. The vendor responses quoted in the article show a disconnect between platform security boundaries and the harm users experience when an assistant endorses malicious instructions. That does not make the risk less real; it makes ownership harder. Practitioners should expect the burden of compensating controls to sit with the teams deploying assistants, not with the browser vendor alone.
Human-facing AI can be socially engineered through the interface it summarizes. Once an assistant becomes part of the decision chain, attackers do not need to defeat the model's reasoning in the abstract. They only need to distort what the assistant can observe. The practical conclusion is that review workflows, copilots, and browser assistants need separate controls for rendered content integrity and user guidance safety.
What this signals
Rendering-layer trust gap: AI-assisted web review should now be treated as a two-surface control problem. The assistant sees source text, while the user acts on rendered meaning, and those surfaces can diverge enough to create unsafe approvals.
Security teams that allow copilots or browser assistants to judge webpage safety should assume presentation can be weaponised. If the workflow cannot render, compare, and score visible output separately from HTML, it should not be used as a trust decision.
For identity and access programmes, the lesson is broader than browsing: any control that delegates judgment to software must define which layer is authoritative. When the output layer can be rewritten without changing the input layer, the review control is incomplete.
For practitioners
- Audit AI web-review workflows for render blindness Identify where browser assistants, copilots, or helpdesk tools rely on raw HTML or DOM extraction without comparing rendered output. Flag any workflow that issues safety advice on pages whose visible meaning could change after CSS or font processing.
- Add render-and-diff validation Require a second pass that captures the page as rendered and compares visible text against source text before any assistant gives a safety judgment. Escalate mismatches where the rendered page contains instructions, calls to action, or hidden text blocks.
- Treat custom fonts as a threat surface Inspect pages that load uncommon fonts, glyph remapping, or unusual CSS visibility rules when assistants are asked to assess risk. Give higher scrutiny to any page where text size, opacity, or colour is used to separate what the model sees from what the user sees.
- Revise user guidance for assistant-assisted browsing Tell users that an assistant's safe verdict on a webpage is only as reliable as its rendering analysis. If the tool cannot render fonts and styles, users should not treat it as authoritative for pages that ask them to run commands or follow technical steps.
Key takeaways
- Rendering tricks can make an AI assistant approve a page that a human would recognise as malicious.
- LayerX Security's testing found that text-only web review failed across the assistants it evaluated, showing how wide the blind spot can be.
- The practical fix is to make rendered presentation part of the trust boundary for AI-assisted page review and user guidance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI09 — Human-Agent Trust Exploitation | The article shows assistants being tricked into endorsing unsafe user actions through presentation mismatch. |
| ASI02 — Tool Misuse | Browser assistants and copilots are being used as trust tools on content they cannot fully perceive. | |
| Recommendation — Treat render-dependent page approval as a human-agent trust boundary and require independent validation before user guidance. Constrain assistant-based page review to rendered outputs the tool can actually inspect and compare. | ||
| NIST AI RMF | MEASURE — AI Risk Measurement and Evaluation | The finding is about evaluation failure when the model cannot measure what the user sees. |
| Recommendation — Measure whether AI review outputs match rendered page content before allowing safety claims. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about trust decisions made by an AI assistant before a user takes action. |
| Recommendation — Limit assistant-driven approval paths unless the content it sees matches the user-visible page. | ||
| MITRE ATT&CK | TA0001;TA0009 — Initial Access; Collection | The technique uses a webpage to reach the victim and collect user action through deceptive content. |
| Recommendation — Track deceptive web content as initial access and collection activity in user-facing threat detection. | ||
Key terms
- Rendering-layer trust gap: The mismatch between what software parses from a webpage and what a person sees after the browser renders it. In AI-assisted review, that gap becomes a security control failure because the model can approve content whose visible meaning is different from the source text.
- Presentation-layer social engineering: Presentation-layer social engineering uses visual formatting, CSS, and font behaviour to change the meaning of content without changing the underlying source. It attacks the user’s perception layer and can also mislead tools that rely on text extraction rather than rendered output.
- Render-and-diff analysis: Render-and-diff analysis compares the text and structure extracted from source code with the content shown after browser rendering. It is a practical detection method for hidden instructions, font substitution tricks, and other cases where visible meaning diverges from parsed HTML.
- Glyph substitution: A font-level technique where one character maps to a different visible glyph when the browser renders it. Security teams should treat it as a content manipulation method because it can alter visible meaning while leaving the DOM text unchanged.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org