TL;DR: AI browser agents like ChatGPT Atlas and Perplexity Comet act inside your already logged-in sessions, so same-origin policy and sandboxing do not protect you. A web page can hide instructions the agent obeys as if they came from you, a flaw OpenAI said in December 2025 is unlikely to ever be fully solved, and one Brave demonstrated by making Comet leak a one-time passcode. Do not ban these tools outright. Restrict them to a low-privilege profile, keep them away from email, banking, admin consoles, and customer data, and make sure anyone who sees the agent act on its own reports it within the hour. The 7-point policy and 30-day rollout below give you the structure.
Someone on your team has probably already installed one. ChatGPT Atlas, Perplexity Comet, Dia, Opera Neon: a new category of browser that does not just show you the web but acts on it for you. You ask it to book a flight, reconcile an invoice, or clear your inbox, and it clicks the buttons itself. It is genuinely useful. It is also the single largest prompt-injection surface in consumer software, and almost no small team has written a single line of policy about it.
This guide gives you that policy. It explains, in plain terms, why an AI browser agent breaks the security assumptions every other web tool relies on, walks through the real attacks that have already worked, and hands you a 7-point governance policy plus a 30-day rollout you can run without a dedicated security team.
What an AI browser agent actually is
A normal browser is passive. It renders a page and waits for you. An AI browser agent is active: it reads the page, decides what to do, and takes the action, all inside your logged-in session.
The four names you will hear most in mid-2026:
- ChatGPT Atlas, OpenAI's browser, released in October 2025, with an "agent mode" that completes multi-step tasks.
- Perplexity Comet, an agentic browser built around Perplexity's assistant.
- Dia, from The Browser Company, which layers an AI agent over a Chromium base.
- Opera Neon, Opera's agentic browser.
The selling point is the same across all of them: the agent operates with everything you are already signed into. That is exactly what makes it powerful, and exactly what makes it dangerous. When the agent opens a tab, it is not a sandboxed bot with its own throwaway login. It is you, with your email, your bank, your CRM, your cloud console, and your company Slack all one click away.
Why the old browser security model does not apply
For 25 years, browser security has rested on a handful of guarantees. The same-origin policy keeps a script on one site from reading data on another. Sandboxing isolates tabs. Permission prompts gate the camera and microphone. These defenses assume one thing: that the human is the only one issuing intent.
An AI browser agent breaks that assumption. The agent reads untrusted content from the open web and then acts on your behalf. As Brave's security team put it, when an AI agent controls the browser, traditional defenses like the same-origin policy and sandboxing stop working, because the agent operates with the user's complete privilege set across every authenticated session at once.
So the threat is no longer "can a bad site steal data from a good site." It is "can a bad site tell your agent to do something, and will your agent do it." The answer, repeatedly, has been yes.
The mechanism is called indirect prompt injection. The attacker does not hack the model. They hide instructions inside content the agent is going to read anyway: a web page, a Reddit comment, a product review, a calendar invite, even text concealed inside an image. The agent cannot reliably tell the difference between "content to summarize" and "commands to follow," so it follows them.
OpenAI has been unusually candid about this. In December 2025 the company said prompt-injection attacks against AI browsers are unlikely to ever be fully solved, though the risk can be reduced through adversarial training and system-level safeguards. In June 2026, independent researchers reached the same conclusion across Atlas, Comet, and Dia: the property that makes these browsers useful is the property that makes them structurally exploitable. This is not a bug waiting for a patch. It is a design tradeoff you have to govern around.
The attacks that have already worked
This is not theoretical. A few documented cases worth briefing your team on:
- The hidden one-time passcode. In August 2025, Brave's security team disclosed an indirect prompt injection against Comet. They hid instructions inside a Reddit post (using a spoiler tag), and when the agent processed the page, it followed the hidden commands, extracting the user's email address and a one-time passcode. A login code, lifted by a page the user merely asked the agent to look at.
- Unseeable instructions in screenshots. Brave later showed that prompt injections can be embedded in images using colors invisible to the human eye but readable by the agent's OCR, affecting Comet and another agentic browser, Fellou. The user sees a normal screenshot. The agent sees a command.
- A phishing scam in under four minutes. In early 2026, researchers demonstrated an "intent collision" attack that merged a benign user request with attacker-controlled instructions from a web page, walking Perplexity's Comet into a phishing flow in under four minutes.
The common thread: in every case the user did nothing obviously wrong. They asked the agent to read a page or summarize a thread. The damage came from content the agent ingested, not from a file anyone downloaded or a password anyone typed.
The governance gap for small teams
Large enterprises are responding with managed browser policies, network controls, and dedicated AI security teams. Small teams have none of that, and the tools arrive the same way shadow AI always does: an employee installs Comet on their work laptop because it saves them an hour a day, and nobody ever asked.
That leaves a real exposure. The agent has standing access to whatever that employee is logged into, which on a small team is often a lot: the shared Google Workspace, the billing portal, the production admin console, the customer support inbox. There is no separation of duties, no second pair of eyes. One injected instruction in one summarized page can move money, exfiltrate a customer list, or send an email in the founder's name.
You do not need an enterprise budget to close this gap. You need a written policy that does three things: limits which accounts agents can touch, limits which tasks they can perform, and gives you a record when something goes wrong.
The 7-point AI browser agent policy
Copy this into your AI acceptable use policy or run it as a standalone page. It is written for teams of 5 to 50.
1. Approved tools only. Only browser agents on the approved list may be used for work. As of this writing the team has reviewed and permits [list the specific products and versions]. Installing any other agentic browser for work requires sign-off from the security lead. This keeps a typosquatted or malware-laden lookalike from slipping in, the same risk covered in our guide on vetting AI tools.
2. A dedicated, low-privilege profile. Agent mode runs only in a separate browser profile that is not logged into email, banking, payroll, the production admin console, or any customer-data system. Treat the agent profile as untrusted. If a task needs one of those accounts, a human does that step manually.
3. The red-line task list. The agent may never, without a human performing the step directly, do any of the following:
- send email, Slack, or any external message on your behalf
- complete a payment, purchase, or financial transfer
- change account credentials, permissions, or security settings
- read, export, or transmit customer or employee personal data
- approve, sign, or submit anything legally binding
4. Human confirmation for any state change. Reading is lower risk than acting. Configure the agent to require explicit confirmation before any action that writes, sends, deletes, or pays. If a tool cannot enforce that, restrict it to read-only research tasks.
5. Untrusted-content rule. Assume every page the agent reads may contain hidden instructions. Do not point the agent at untrusted or unknown sites and then let it act. Research-and-summarize on the open web is fine. Read-this-page-then-go-do-something-in-my-account is not.
6. Logging and review. Where the tool offers an activity or history log, it must be enabled. The security lead reviews agent activity during any incident and spot-checks monthly. If an agent took an action no one can explain, treat it as a potential injection and follow the incident response plan.
7. Reporting. Anyone who sees the agent do something they did not ask for (sending a message, opening an unexpected account, entering a code) stops, disconnects, and reports it within the hour. No blame for reporting. This is the single most valuable control you have, because injection often looks like a glitch, not an attack.
Approved versus blocked, at a glance
| Use it for | Do not use it for |
|---|---|
| Summarizing public articles and docs | Anything inside email or chat |
| Comparing products across vendor pages | Banking, invoicing, or payroll |
| Drafting text you will review and send yourself | Admin consoles and infrastructure |
| Filling forms with non-sensitive, public data | Customer or employee personal data |
| Research in the low-privilege profile | Approving, signing, or purchasing |
A 30-day rollout
You do not need a project plan. You need four weeks.
Week 1, find them. Ask the team, plainly, who is using an AI browser. Pair it with a short brief on indirect prompt injection so people understand this is about a real attack, not IT being difficult. This doubles as your shadow AI discovery step.
Week 2, set the profile. Help anyone using an agent set up the separate low-privilege profile in point 2. This is the highest-leverage control, because it caps the blast radius of any injection regardless of how clever the attack is.
Week 3, publish the policy. Add the 7 points above to your acceptable use policy, name the approved tools, and name the security lead. Get a quick acknowledgment from everyone.
Week 4, rehearse. Run one tabletop: "the agent sent an email no one wrote, what now." Confirm everyone knows the stop-disconnect-report sequence and where the incident response plan lives.
What this policy does not cover
This governs AI agents driving a browser inside your sessions. It does not replace your broader AI program. Agents your team builds and operates (with their own API keys and tools) belong under your AI agent governance policy. AI features embedded in third-party SaaS belong under vendor due diligence. And general employee use of chatbots belongs in your AI acceptable use policy. The browser agent sits at the intersection of all three, which is exactly why it falls through the cracks if you do not name it explicitly.
The honest summary: AI browser agents are useful enough that banning them outright tends to fail, and risky enough that ignoring them is negligent. The workable path is the middle one. Let people use them for low-stakes work in a profile that cannot hurt you, keep them away from the accounts that can, and make sure that when something looks wrong, someone says so within the hour.
Related reading
- Shadow AI policy for small teams
- AI acceptable use policy template for small teams
- Vetting AI tools for fake malware and typosquatting
- AI agent governance policy for small teams
- MCP server security governance checklist
- AI support chatbot account takeover risk
- AI incident response plan template for small teams
- AI governance complete guide for small teams
