Notifications
Clear all
Topic starter
07/06/2026 8:23 pm
TL;DR: Browserbase says AI agents are now handling browser-based work like gas price lookups, rebate forms, and KYB research, with internal metrics measuring years of browsing time saved and public evals tracking model performance across real browser tasks. The identity question is no longer whether agents can click through a browser, but what access, boundaries, and accountability models make that safe for enterprises.
NHIMG editorial — based on content published by WorkOS: Browserbase is deleting hundreds of years of busy work
Questions worth separating out
Q: How should security teams govern AI agents that use browsers to complete work?
A: Security teams should govern browser-using AI agents as task-scoped identities with a named owner, a bounded workflow, and an auditable session.
Q: Why do browser-based AI agents create new IAM risk?
A: Browser-based AI agents create IAM risk because they can act across sites, forms, and sessions at machine speed while inheriting trust that was designed for human operators.
Q: What breaks when browser automation is not tightly scoped?
A: When browser automation is not tightly scoped, the same agent can drift from one workflow into another, reuse session state, and reach data or services that were never approved for the original task.
Practitioner guidance
- Classify browser agents as governed identities Map each browser-using agent to a named owner, purpose, and approved workflow.
- Separate task scope from browser reach Limit each agent to a narrow task definition and verify that the browser can only reach the sites and forms needed for that task.
- Bind credentials to the browser session Use scoped credentials that expire with the task and cannot be reused after completion.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Paul Klein's firsthand examples of browser work automation in enterprise and consumer settings
- The Stagehand evals and the specific browser challenges used to compare model performance
- The discussion of open source model options for teams that want to run browser automation in their own environments
- The re:Invent context and the broader AI adoption signals from CIOs
👉 Read WorkOS's interview on browser automation for AI agents and work completion →
Browser automation for AI agents: what it means for IAM teams?
Explore further
07/06/2026 10:15 pm
Browser automation turns web access into an identity problem, not just a UX problem. Once an AI agent can open pages, submit forms, and navigate third-party sites, the real question becomes who or what is allowed to act in that browser session. Traditional IAM assumptions treat browser use as a person-driven activity with a stable operator behind it. That breaks when the actor is software completing work across multiple sites at machine speed. Practitioners should stop treating browser automation as a helper feature and start treating it as a governed identity surface.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: Who is accountable when an AI agent completes a browser workflow incorrectly?
A: Accountability should sit with the business owner, the system owner, and the identity team that approved the access model. If no owner can explain the allowed task, the allowed data sources, and the session boundary, the workflow is not ready for production use.
👉 Read our full editorial: Browser automation for AI agents is moving from demo to work
