Blog
Sayers And Global Business Services Provider
Read More
AI powered browsers promise productivity boosts: they summarize articles, autofill forms, help compose emails, and even automate online shopping flows. These gains stem from tight AI integration with the browser’s live context—tabs, page content, and sometimes stored credentials—so the assistant can “see” what you see and act accordingly. Microsoft’s Edge Copilot Mode, for example, can reason across open tabs and (with your permission) perform site actions; other entrants like OpenAI’s ChatGPT Atlas and Perplexity’s Comet push similar “agentic” capabilities.
Yet this new interaction paradigm introduces material security considerations. Industry analysts have begun advising caution: Gartner recently urged enterprises to block AI browsers for now due to prompt injection risk, loss of data visibility, and autonomous transactions performed under user credentials.
This post focuses on the security concerns of AI web browsers and how enterprises should evaluate and govern their use.
Generative AI (GenAI) embedded in a browser dramatically broadens the attack surface. A typical AI workflow can be thought of as:
1. Ingesting input – This includes web page content or user instructions.
2. Run inference – This is running the input through the foundation model, this often includes tools, plugins, and APIs the AI can use during this time.
3. Execute output – This can be a text output to a user, or it can execute actions such as sending input to a separate AI agent.
When the browser’s AI can read everything rendered in tabs and act on your behalf (book travel, check out, send email), then the public web becomes a live input stream to your agent. That is powerful and inherently dangerous.
Security frameworks now explicitly track these risks. The OWASP Top 10 for LLMs identifies “Excessive Agency” and “Improper Output Handling” alongside “Prompt Injection” as leading risks when models are granted tools and permissions. Excessive agency covers scenarios where an AI agent can perform unintended operations—e.g., initiating purchases or modifying data—because it has too much autonomy or privilege.
Practical implications for AI browsers:
• Everything you browse can become model input – Including hidden DOM elements, iframes, screenshots, or documents – expanding adversary control over the AI’s context.
• Agent permissions multiply impact: when the AI can click, fill forms, or transact in authenticated sessions, the blast radius of a bad decision or hijacked instruction increases.
The enterprise challenge is balancing productivity (AI agency) against unacceptable risk.
Prompt injection manipulates an AI system by feeding crafted input—directly in a chat or indirectly via content the AI reads—to override instructions, exfiltrate data, or trigger actions. OWASP ranks Prompt Injection as the top LLM risk.
For AI browsers, indirect prompt injection is particularly severe: attackers hide instructions in web pages, images, or URLs that the agent parses as “trusted context.” Recent research and disclosures show:
• Brave’s team demonstrated invisible prompts in screenshots hijacking Perplexity’s Comet, leading the agent to execute attacker commands when a user simply asked for a screenshot summary.
• LayerX described “CometJacking” – malicious prompts embedded in URLs to coerce Comet into extracting data from Gmail or Calendar, encoded to bypass naive checks.
• Security outlets, as shown by TheHackerNews, highlighted PromptFix attacks that embed instructions in fake CAPTCHAs or hidden HTML, redirecting agent actions.
Prompt injection can lead to credential leaks, fraudulent purchases, and data exfiltration when AI agents operate inside loggedin sessions.
There is currently no way to defend against 100% of prompt injection attacks, however, risks can be mitigated through a defense in depth approach.
Mitigations controls can include: appropriately scoping AI workflows, validating outputs, providing real time input and output monitoring, adding human verification to high impact actions, and more
Attack techniques evolve alongside model guardrails. Because LLMs are nondeterministic, the same input can yield different outputs; safety filters can be bypassed in unexpected ways, and adversaries rapidly test new linguistic patterns. This makes prompt injection closer to a chronic vulnerability class as opposed to a oneanddone fix.
As AI browsers add autonomy through multistep planning, tool access, and “agentic browsing”, the impact of successful injection grows (financial transactions, data movement, account actions); and the attack surface widens.
Due to the impossibly large combination of possible inputs paired with the high agency that AI browsers provide, many enterprises currently view AI browsers as too risky to allow broadly without strong constraints.
Analyst advisories explicitly recommend blocking AI browsers until adequate controls are proven.
Beyond prompt injection, AI browsers raise enterprise governance concerns:
• DLP and guardrail bypass: AI sidebars/agents can read any open page, including sensitive internal web apps, and may transmit context to cloud backends, eroding DLP visibility and policy enforcement.
• Audit trail opacity (“black box”): Agent workflows can chain multiple steps in the background; reconstructing what instructions led to which actions is harder than auditing a manual upload.
• Consumer privacy defaults: AI browser integrations and extensions show extensive data collection (history, identifiers, interactions), with many products using data to personalize or even advertise. A top of mind example, Perplexity docs note Comet may process local page context (including email text) via Perplexity servers to fulfill tasks—raising concerns about what is sent and when.
• Legal/compliance spillover: Ongoing lawsuits about AI crawling/training and paywall bypass (e.g., Tribune vs. Perplexity) illustrate the murky territory of content use and retrievalaugmented generation – relevant when agents summarize behindlogin content.
Recommendation: Disallow AI browsers in enterprise environments for now. The combination of prompt injection risk, excessive agency, weak auditability, and potential data exfiltration through cloudprocessed context makes blanket adoption misaligned with most risk appetites today consistent with recent analyst guidance.
If AI browsers are businessnecessary, treat them as highrisk systems and apply defenseindepth aligned to NIST/OWASP and leading vendor patterns:
1. Isolate usage: Run AI browsers in segmented, nonsensitive VDI/VPA environments; enforce separate identities and block access to crownjewel apps. (Maps to NIST AI RMF & control overlays; CISA emphasizes robust data governance and monitoring.)
2. Harden inputs & context:
o Apply origin isolation and content provenance; restrict agent access to allowed domains (mirroring Chrome’s Agent Origin Sets).
o Disable reading of internal pages unless explicitly whitelisted; block screenshotbased analysis on sensitive sites.
3. Execution controls & humanintheloop: Require user confirmations for purchases, banking, healthcare portals, password manager access, and other high impact actions.
4. Output validation & monitoring: Deploy promptinjection detection, schema filters, and response sanitization; log all AIinitiated actions with full provenance for audit.
5. Privacy posture: Review vendor data handling (what’s sent, retention, training), disable cloud sync by default, and prefer ondevice models where feasible. Independently validate vendor claims against thirdparty privacy analyses.
6. Governance & policy: Align with NIST AI RMF guidance for risk identification, controls, and overlays; integrate AI browser usage into existing DLP, identity, and incident response playbooks.
If you are interested in learning more about how to secure AI within the enterprise, contact us! hello@sayers.com
