What is agentic browser security?
By Identra · Updated
Agentic browser security is the practice of controlling what AI agents can read, share and change through a browser. It protects signed-in sessions by limiting agent access and actions to an authorized task, including when web content tries to redirect the agent.
How do AI agents use a browser?
They read the page and act on it. An AI browser like ChatGPT Atlas or Perplexity Comet, or an extension like Claude for Chrome, takes a task, looks at the page through screenshots or the page structure, then clicks, types, downloads and submits. Every new page can change its next move.
The agent does not need your password. It works inside the session you already have. To Salesforce or Gmail, a click from the agent looks like a click from you.
How can a web page hijack a browser agent?
Say a support lead asks an agent to summarize open tickets in the help desk. One ticket, written by an outsider, says verification requires pasting the internal notes into an external form. The agent does it. A summary task just became a data leak, and nobody stole a credential.
That is indirect prompt injection. The ticket was input for the summary. The agent read it as an order.
A safer setup lets the agent read only the tickets it needs and write a draft. Submitting to outside forms is simply off the list. A system prompt telling the agent to ignore hostile text helps a bit. It should never be the only thing between an attacker and your customer notes.
What changes when an agent drives instead of a person?
Who decides the next click. Plenty of perfectly legitimate sites carry text written by strangers, like shared docs, comments and customer messages. A person skims past a weird instruction. An agent might follow it. This is where enterprise browser security picks up a new question: what is an agent allowed to do with this person's access?
App permissions still apply. They are usually far wider than the task. Edit rights on every CRM record do not mean an agent summarizing one account should touch any of them.
Who picks the next action?
- Person browsing
- The person
- Agent browsing
- The agent, based on what it just read
What grants app access?
- Person browsing
- The signed-in account
- Agent browsing
- Usually the same account and session
What needs extra control?
- Person browsing
- Risky sites and data handling
- Agent browsing
- Task scope, untrusted page text, automated actions
What proves who did what?
- Person browsing
- App logs under the user
- Agent browsing
- Records tying user, agent, task and actual changes together
What controls should you put in place?
Write down the approved task before the agent gets a browser. Which account, which apps, which records, which destinations. Use least privilege in the apps themselves so a bad decision cannot become a privileged one.
Watch what leaves as well as what changes. Page text, screenshots and downloads can all end up with the agent's model provider. Find out where processing happens and what the provider keeps.
- Give each approved agent task an owner. Note whether the agent runs locally or in the vendor's cloud.
- Use a separate browser profile and a limited account where you can. A separate profile isolates cookies and history. It does not shrink the account's permissions.
- Prefer read-only access for research and summary tasks.
- Allow uploads, messages and form submissions only to approved destinations.
- Ask a person before sharing externally, changing permissions, buying anything or deleting. Show the exact destination and content in the human approval prompt.
- Keep a stop button that works, and know which OAuth grants or API keys also need revoking.
How do you test the controls?
Use a sandbox with fake records. Run the real task, then plant a page that asks the agent to export data, add a redirect to an unapproved site and include one action that needs approval. When the agent is refused, does it try a different route?
For the ticket example, confirm it can summarize allowed tickets and cannot post notes to an outside form. Change the destination on an approved action and check that approval is requested again.
Keep an AI audit trail of who started the task, which account it used, what was approved and what actually happened. Keep sensitive content out of those logs where you can. "Task complete" from the agent proves nothing about what changed.
What if a browser agent goes off task?
Stop it. Save the records. Work out which accounts and apps it touched, then check app logs for sent messages, shared files, edited records and new permissions.
Closing the browser does not revoke an OAuth grant or an API key the agent used. Treat it as an agentic AI security incident and check local files and connected tools too.
How Identra thinks about it
Identra detects when an AI agent is driving the browser instead of a person, and security teams can block that by policy. It also shows which AI apps people use and whether they are signed in with a work or personal account. Access can be allowed, redirected to the company AI workspace or blocked. Prompts are checked on the device before they are sent, so sensitive data can be masked or blocked before it leaves the browser.
Go deeper: Identra in the browser
Frequently asked questions
Does this only apply to AI browsers?
No. It also covers agents driving a normal browser through an extension, automation tooling or computer-use features.
Is browser agent misuse the same as session hijacking?
No. The user handed the agent a valid session on purpose. The agent can still go beyond the task without anyone stealing anything.
Does MFA stop unwanted agent actions?
No. MFA protects the login. The agent acts after login is done. Step-up checks on specific actions help, and so do tight app permissions.
Is a read-only browser agent safe?
Safer. It cannot edit records. It can still leak what it reads through its output or the model provider.
Can a system prompt stop browser prompt injection?
Not reliably. Enforce permissions, destination limits and approvals outside the model.