Notifications
Clear all
Topic starter
14/07/2026 6:08 pm
TL;DR: Browser-based prompt injection can turn a single malicious or hijacked extension into a covert data theft path for ChatGPT, Google Gemini, and other LLM-connected tools, according to Swarmnetics. The practical problem is not the model alone but the browser permissions and connected data sources that let attackers read, log, and erase sensitive content without obvious detection.
NHIMG editorial — based on content published by Swarmnetics: Browsers are Wide Open to LLM Prompt Injection Attacks
Questions worth separating out
Q: How should security teams control browser prompt injection risk in LLM tools?
A: Start by treating browser extensions, connector permissions, and session telemetry as a single control surface.
Q: Why do cryptographic changes matter to IAM and NHI programmes?
A: IAM and NHI programmes rely on certificates, signing keys, and token trust to establish who or what is authenticated.
Q: What breaks when extensions can issue hidden prompts to LLMs?
A: Auditability breaks first, because background interactions can erase the user-visible trail by deleting chats or hiding activity in tabs.
Practitioner guidance
- Inventory and approve browser extensions Maintain a living inventory of extensions allowed on endpoints that access GenAI tools, and remove anything that no longer has a clear business need.
- Restrict LLM connector scope Limit which mail, document, messaging, and contact sources an LLM can reach, then review connector permissions as part of access recertification.
- Monitor DOM and extension behaviour Add telemetry for unusual DOM interaction patterns, background tab activity, and repeated prompt execution from the same extension.
What's in the full analysis
Swarmnetics's full article covers the operational detail this post intentionally leaves for the source:
- Proof-of-concept attack flow showing how a malicious extension injects commands into ChatGPT and Google Gemini sessions.
- Specific examples of how browser history and chat cleanup can hide the evidence trail after exfiltration.
- Discussion of DOM permission abuse and why existing browser trust models fail to flag the behaviour.
- Practical monitoring ideas for teams that need to validate browser-to-LLM interactions in their own environment.
👉 Read Swarmnetics's analysis of browser prompt injection attacks on LLMs →
Browser prompt injection attacks: are your LLM controls keeping up?
Explore further
14/07/2026 6:13 pm
Browser prompt injection is now an identity and access problem, not just an LLM safety problem. The attack path depends on existing browser permissions, extension trust, and the LLM’s delegated access to connected services. That places it squarely in the governance space that IAM and PAM teams already manage, even though the abuse surface looks like application behaviour. Practitioners should treat browser-mediated LLM access as part of the access control plane.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when a browser extension exposes LLM-connected data?
A: Accountability usually spans endpoint security, IAM, and the team operating the GenAI tool. Endpoint owners govern the extension, identity teams govern the connector and access scope, and platform owners govern logging and detection. Frameworks like the NIST Cybersecurity Framework and NIST AI RMF both point to shared ownership rather than a single control team.
👉 Read our full editorial: Browser prompt injection exposes a new LLM data theft path
