Browser agents and computer-use agents do not call APIs with their own credentials. They drive a real browser or desktop, clicking, typing and reading the screen like a person. That means they often operate inside a user's signed-in sessions, with the user's cookies, saved passwords and access to every site and app the user can reach. It makes them useful for tasks without APIs, and it creates a distinctive identity problem: to every website, the agent is indistinguishable from the user. This guide explains the identity and security risks of browser and computer-use agents and the controls that reduce them.
Key takeaways
- Browser and computer-use agents typically inherit the user's sessions, so their effective access is everything the user is signed in to.
- They read untrusted web content constantly, which makes indirect prompt injection the main threat.
- Websites cannot distinguish the agent from the user, so attribution and least privilege are hard.
- Reduce risk with separate browser profiles or environments, site allowlists, confirmation for sensitive actions and no access to credential stores by default.
How these agents work
- Browser agents control a browser via extensions or automation, reading page content and interacting with forms and links.
- Computer-use agents take screenshots of a desktop and issue mouse and keyboard actions, working with any application.
- They may run on the user's own machine and browser, in a separate managed browser, or in a cloud-hosted virtual environment.
The identity problem
| Setup | Effective access | Risk |
|---|---|---|
| Agent in the user's main browser profile | Every site the user is signed in to, saved passwords and autofill | Highest: one injected instruction can act across email, banking, admin consoles |
| Agent in a separate browser profile | Only sites signed in within that profile | Lower: access limited to deliberate sign-ins |
| Agent in an isolated cloud environment | Only what is signed in there, often per task | Lowest: ephemeral and contained, but credentials must be provided carefully |
In all cases, websites see the user's session. Actions are logged as the user, and the site's own controls cannot apply different rules to the agent.
Threats
- Indirect prompt injection: hidden text on a web page, in an email or in a document instructs the agent to take actions, such as sending data, changing settings or making purchases (OWASP ASI01).
- Cross-site actions: content read on one site leads the agent to act on another where the user is signed in.
- Credential exposure: agents typing passwords, reading password managers or capturing screens containing secrets.
- Phishing the agent: look-alike sites that the agent does not recognise as fake.
- Screen capture of sensitive data: screenshots sent to a model provider may contain personal or confidential information.
- Irreversible actions: purchases, transfers, deletions and messages sent in the user's name.
Controls
Isolation
- Run agents in a dedicated browser profile or isolated environment, not the user's everyday profile.
- Sign in only to the sites needed for the task, and sign out afterwards.
- Do not give agents access to password managers or saved credentials by default.
Scope
- Allowlist sites the agent may visit and act on; block sensitive categories such as banking and admin consoles unless explicitly required.
- Limit file system and clipboard access for computer-use agents.
Confirmation
- Require user confirmation for purchases, payments, sending messages, changing account settings, sharing files and submitting forms with personal data.
- Pause and ask when the agent encounters sign-in pages, CAPTCHAs or permission prompts, rather than proceeding.
Visibility
- Keep an action log of sites visited and actions taken, with screenshots where appropriate and privacy allows.
- Let users watch and stop the agent at any time.
Enterprise policy
- Decide which browser and computer-use agents are approved, and in which configurations.
- Manage agent extensions through browser management.
- Prefer API-based agents with their own scoped identity where an API exists. See the Agentic AI Identity Guide.
For website and application owners
- Expect agent traffic; consider how you will identify and authorise legitimate agents acting for users. Emerging approaches include signed agent requests and delegated agent credentials. See the Agent Identity Standards Tracker.
- Require step-up authentication for sensitive actions, which also protects against misdirected agents.
Practitioner checklist
- Approve browser and computer-use agents and their configurations.
- Isolate agents from users' main browser profiles and credential stores.
- Allowlist sites and block sensitive categories by default.
- Require confirmation for purchases, messages, settings changes and data sharing.
- Log agent actions and let users stop them.
- Prefer API-based agents with scoped identities where possible.
Standards and references
- OWASP Top 10 for Agentic Applications for 2026: ASI01, ASI02, ASI09
- OWASP Top 10 for LLM Applications (2025): LLM01, LLM06
Related NHI Mgmt Group resources: Agentic AI Security Guide · How to Prevent Prompt Injection in AI Agents · Agentic Commerce Identity Guide · AI Agent Authorisation Guide
