TL;DR: ChatGPT page summaries can render attacker-controlled Markdown links and images from third-party web pages as live elements inside the assistant UI, while auto-fetching remote assets also leaks IP, User-Agent, Referer, and timing data, according to Permiso Security. The control problem is the trust boundary between retrieved content and rendered assistant output, not the browser alone.
At a glance
What this is: This research shows that browser-summarised pages can push attacker-controlled Markdown and remote images into ChatGPT’s rendered answer, turning normal browsing into a phishing and tracking surface.
Why it matters: It matters because identity and security teams now have to govern not just the source page, but the trust boundary around assistant output that users may treat as authoritative.
Context
Browser-based prompt injection is a trust-boundary problem: a page the user intends to summarise can shape the assistant’s output, and the output can inherit the assistant’s credibility. In this case, the risk is not simply malicious web content, but the way rendered AI responses can blur the line between retrieved material and trusted interface elements.
For identity and security programmes, that matters because phishing, telemetry leakage, and UI redress are no longer confined to inboxes or malicious attachments. Any workflow that lets an assistant render untrusted links or images inside a familiar workspace creates a new control surface for social engineering and data collection.
Permiso Security’s findings focus on browser-summarised content flowing into a trusted AI surface. The underlying pattern is broader than one product: when untrusted page content can be displayed back as if the assistant produced it, user trust becomes the exploit path.
Key questions
Q: How should security teams stop browser-summarised pages from becoming phishing payloads?
A: Treat summarisation output as an untrusted rendering problem, not just a model-inference problem. The safest pattern is to isolate source material, strip or inert unverified links, and prevent remote images from loading automatically. If users can see attacker-controlled content in the same visual frame as the assistant’s answer, phishing risk persists even when the model itself behaves as intended.
Q: Why do rendered links and images in AI assistants create security risk?
A: Because they inherit the assistant’s trust while still originating from untrusted content. That enables link spoofing, passive tracking through image loads, and user confusion about what the assistant actually generated. The risk is highest when the interface does not preserve source labels, making external content look native to the assistant response.
Q: What are the signs that an AI summarisation flow is misusing untrusted web content?
A: Look for assistant answers that preserve Markdown links, display remote images, or reproduce alert-style language taken from the page. If the user can click, scan, or fetch content that originated on a third-party site without clear labelling, the summary flow is crossing the boundary from explanation into delivery.
Q: What should teams do when assistant output can include QR codes or tracking pixels?
A: Treat those elements as active delivery mechanisms. QR codes can move the user off desktop controls onto a phone, while tracking pixels can reveal who viewed the page and when. Teams should block or tightly gate those render paths, and require explicit provenance before any such element appears in an assistant response.
Technical breakdown
How browser summarisation becomes a rendering trust problem
The issue starts when a summarisation flow ingests page content and then re-renders part of that content inside the assistant response. If Markdown links and image URLs are preserved rather than isolated, the assistant output stops being a pure summary and becomes a rendering channel for attacker-controlled elements. That changes the security boundary: the browser is no longer only retrieving content, it is feeding a model that can present that content in a privileged UI. Once the assistant output inherits the surrounding product trust, users may click links or scan images that were never validated as assistant-generated content.
Practical implication: separate retrieved web content from assistant-authored output so untrusted links and images are never rendered as trusted UI.
Why auto-fetched images create passive tracking risk
When a client auto-fetches remote images embedded in a summarised page, the request itself becomes an observable event. The endpoint can collect IP address, User-Agent, Referer, and timing metadata tied to when the answer was rendered. This is a classic beaconing pattern, but the delivery path is unusual: the user does not need to click anything for the request to happen. The security issue is not only exfiltration of content, but confirmation that a specific target viewed a specific page through the assistant. That makes the rendering layer a telemetry source for pre-targeting and follow-on social engineering.
Practical implication: block or proxy remote asset fetching in assistant renderers and treat image loads as potential beacons.
How QR-code payloads bypass desktop link defenses
A QR code in an assistant-rendered image changes the attack from on-screen navigation to cross-device transfer. Desktop protections such as hover previews, domain blocklists, and password-manager domain checks offer little value once the user scans the code on a phone. The QR code becomes a hidden destination encoded inside what looks like ordinary assistant output. This is especially effective when the code is framed as a status alert or account notice, because the user’s attention shifts from source verification to perceived urgency. The control failure is not just content moderation, but the absence of strict source labelling inside the rendered response.
Practical implication: prevent QR-code rendering in summarised assistant output unless the source and destination can be separately verified.
Threat narrative
Attacker objective: The attacker wants to turn ordinary page summaries into a delivery mechanism for phishing, tracking, and cross-device social engineering without requiring a malicious attachment or obvious compromise.
- Entry occurs when an attacker places instruction-like text, clickable Markdown, or remote image references on a public page that a user later asks ChatGPT to summarise.
- Credential or data access is not the objective here; the attacker instead abuses the assistant’s rendering path to surface attacker-controlled links, fake alerts, or image beacons inside a trusted reply.
- Impact is achieved when the victim clicks a spoofed link, scans a rendered QR code, or triggers a remote image request that reveals browsing telemetry and confirms interest in the page.
Breaches seen in the wild
- EchoLeak (Microsoft 365 Copilot) 2025: A crafted email could make Microsoft 365 Copilot leak data from its context with no click, a zero-click prompt injection fixed as CVE-2025-32711.
- ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.
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
Rendered assistant output has become part of the attack surface. The article shows that once a summarisation system preserves Markdown links and image URLs from a third-party page, the trust boundary shifts from the source page to the rendered answer. That is not a browser quirk, it is a governance failure around what the assistant is allowed to present as its own output. The implication is that identity and security teams must treat the rendering layer as a privileged control plane, not a harmless presentation detail.
Browser injection is a cross-channel phishing primitive, not just prompt injection. The same payload can deliver clickable links, spoofed account alerts, passive image beacons, and QR-code pivots. That mix matters because it combines social engineering, telemetry leakage, and UI redress in one delivery path. Practitioners should stop modelling the issue as a single prompt-security problem and instead view it as an assistant-mediated trust transfer problem.
Trust labeling is the missing control concept. The central failure is that untrusted web content can reappear in a trusted assistant frame without a durable label showing where it came from. Without source separation, users cannot reliably distinguish assistant-authored guidance from attacker-injected artefacts. The implication is that provenance, not just content filtering, becomes the core governance requirement for browser-integrated AI workflows.
Browser-integrated AI will force IAM teams into content provenance decisions. The more assistants are used for summarisation, research, and workflow acceleration, the more often users will interact with content that looks native to the product but originated elsewhere. That creates a new class of trust abuse that sits between web security, social engineering, and identity assurance. Practitioners need to recognise this as a programme-level control gap, not a user-training edge case.
What this signals
Trust labeling is now a browser-security requirement for AI workflows. When an assistant can render third-party links and images inside its own reply, the safest assumption is that the user will trust the frame more than the source. That means provenance controls need to sit in the rendering path, not just in the browser or mail gateway.
The practical test is simple: if untrusted page content can be made to look like native assistant output, the environment is already vulnerable to phishing-by-presentation. Security teams should focus on where content is displayed, not only where it was fetched from.
For practitioners
- Separate retrieved content from assistant-authored output Ensure summarisation flows visually and structurally distinguish model-generated text from quoted page content, links, and images so users can see what came from the page and what came from the assistant.
- Disable automatic remote image fetching Prevent assistant renderers from loading third-party images by default, or route them through a safety proxy that strips tracking headers and blocks passive beaconing.
- Suppress clickable links from untrusted summaries Render hyperlinks from summarised pages as inert text unless the destination is verified and clearly labelled as external content rather than assistant output.
- Block QR-code rendering in high-risk contexts Treat QR-code images in assistant summaries as a policy exception and require explicit provenance checks before they can be displayed in a way that invites mobile scanning.
Key takeaways
- ChatGPT-style page summaries can turn ordinary web pages into phishing and tracking delivery surfaces when untrusted Markdown and images are rendered inside the assistant UI.
- The core failure is trust transfer, not browser compromise, because attacker content can inherit the credibility of the assistant frame.
- Security teams should isolate source content from rendered output, suppress passive remote fetches, and make provenance visible before users click or scan.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI09 — Human-Agent Trust Exploitation | The attack exploits user trust in assistant-rendered output. |
| ASI06 — Memory & Context Poisoning | The page content is injected into the assistant context and shapes output. | |
| ASI05 — Unexpected Code Execution | Auto-fetched images and clickable rendering create unintended actions in the UI layer. | |
| Recommendation — Treat assistant-rendered links and images as trust-boundary content and label all untrusted elements clearly. Limit how untrusted page content can influence summarised assistant responses. Constrain rendering paths so untrusted content cannot trigger unintended client-side actions. | ||
| NIST CSF 2.0 | PR.DS-10 — Confidentiality of Data at Rest and In Transit | Remote image requests can leak metadata through the rendering channel. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The problem is the assistant’s permission to present untrusted content as trusted UI. | |
| Recommendation — Reduce metadata exposure by proxying or blocking remote asset loads in assistant output. Restrict which page-derived elements can be authorised for display inside assistant responses. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | The summary flow becomes an uncontrolled path for phishing and telemetry delivery. |
| Recommendation — Inventory and gate assistant rendering flows that can deliver external content to users. | ||
Key terms
- Browser Injection Attack: A browser injection attack is when malicious code is inserted into a web session or client-side flow to alter what the system sends or receives. In identity verification, it can change images, data, or requests before they reach the service, undermining trust in the verification outcome.
- Rendered Trust Boundary: A rendered trust boundary is the point where untrusted source material becomes visible inside a user interface that people treat as authoritative. In AI assistants, this boundary matters because links, images, and alert-style text can inherit the product’s trust unless the interface preserves provenance.
- Passive Beaconing: Passive beaconing is the collection of metadata when a client automatically loads a remote resource without the user explicitly clicking it. In assistant workflows, image loads can reveal IP, user agent, referer, and timing, creating a low-friction tracking channel for an attacker.
- Cross-Device Phishing Pivot: A cross-device phishing pivot is an attack pattern that moves the victim from one device to another during the trust decision, often using QR codes or mobile login flows. For AI-assisted browsing, it weakens desktop protections because the final destination is hidden until the phone takes over.
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 3, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org