Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Agentic browsers and identity risk: are your controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 9079
Topic starter  

TL;DR: Agentic browsers shift the browser from passive display to autonomous execution, which lets AI agents use active cookies, autofill data, and session context to complete tasks while also widening phishing, prompt injection, and compliance exposure, according to JumpCloud. The central problem is that existing IAM and browser-security controls assume a human remains the decision-maker, but the agent now becomes the actor.

NHIMG editorial — based on content published by JumpCloud: agentic browsers and the changing browser attack surface

By the numbers:

Questions worth separating out

Q: What breaks when agentic browsers can act inside a human session?

A: The browser stops being a passive interface and becomes a delegated actor with the user’s live privilege.

Q: Why do agentic browsers complicate zero trust architecture?

A: Zero Trust assumes each action can be verified continuously, but agentic browsers reuse legitimate sessions while making independent decisions inside them.

Q: How can security teams measure whether browser-agent risk is controlled?

A: Look for evidence that high-risk tasks cannot be completed without a human checkpoint, that browser actions are fully logged, and that sensitive portals are excluded from agentic completion.

Practitioner guidance

  • Define browser action boundaries Classify which browser actions may be completed by software and which require a human confirm step before submission, payment, or permission changes.
  • Separate session use from sensitive task execution Prevent agentic browsers from carrying live cookies into HR, finance, admin, and internal control-plane portals unless the action is explicitly approved and logged.
  • Require auditable prompts and action logs Demand logs that capture prompts, page targets, intermediate actions, and any context retained across sessions.

What's in the full article

JumpCloud's full analysis covers the operational detail this post intentionally leaves for the source:

  • Step-by-step examples of how agentic browsers interpret DOM content and execute multi-step tasks
  • Specific threat patterns such as indirect prompt injection, Cometjacking, and confused deputy behaviour
  • Questions security leaders can use to assess browser memory handling, audit logging, and action attribution
  • Practical guidance on where Zero Trust checks should sit when a browser acts on behalf of a user

👉 Read JumpCloud's analysis of agentic browsers and enterprise identity risk →

Agentic browsers and identity risk: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 8508
 

Browser session authority is now an identity control problem, not just a web security problem. The article shows that the browser can act with the same privileges as the logged-in employee, which collapses the old boundary between user intent and software execution. Traditional controls like SOP and URL inspection were built for human-driven navigation, not software that can carry identity across tabs and tasks. Practitioners should treat browser session authority as governed identity, not mere application state.

A few things that frame the scale:

A question worth separating out:

Q: Who is accountable when an agentic browser submits the wrong action?

A: Accountability stays with the organisation that allowed software to use human sessions and sensitive data without clear guardrails. In practice, that means IAM, endpoint, browser management, and security operations all share responsibility for defining what the agent may do, what must be reviewed, and what must never be delegated.

👉 Read our full editorial: Agentic browsers turn the enterprise browser into a new identity risk



   
ReplyQuote
Share: