You already have the login. So does the AI.
Claude in Chrome is now generally available on every paid Claude plan. It can read what's on screen, type into fields, click buttons, fill forms, and navigate between pages—inside your vendor portals, your internal dashboards, your legacy systems. It does all of this using the credentials your employee already has in their browser. No API project, no IT integration, no additional access provisioning. Just open Chrome and start. [1]
That last part is what makes this worth your attention, and also what makes it worth being deliberate about.
What the browser agent actually does
Most AI tools sit beside your work. They read documents you paste in, suggest text you copy out, and hand control back to you before anything changes. A browser agent works differently. It operates inside the page.
It can authenticate as your employee, navigate a vendor portal the way that employee would, locate the right fields, enter the right information, and submit. It can do this across internal dashboards and legacy systems that would otherwise require integration work to automate. From a pure capability standpoint, that is a meaningful change. The barrier that once kept AI agents out of older systems was the engineering cost of connecting to them. A browser agent sidesteps that entirely. [1]
For a manager weighing where to apply AI this quarter, that opens options that weren't realistic before. It also changes the risk calculation in ways that don't always get explained clearly.
The risk lives in the browser session
When you connect an AI to a formal system integration, your IT team controls what the AI can reach. They define the scope, write the permissions, and own the connection. A browser agent skips that process. It inherits whatever the employee's active session can access.
That scope is usually wider than people assume. An employee logged into your vendor portal may have access to pricing configurations, contract history, and order submissions. An employee logged into an internal dashboard may have access to operational data across multiple departments. The browser agent, working inside that session, can reach all of it.
Anthropic says a safety classifier evaluates each action before the agent takes it, and users can turn off auto-approval so every step requires a human confirmation. Those are meaningful controls. They are also vendor-published and have not been independently audited. The safety picture is early and still developing. [1]
The threat your firewall does not cover
Prompt injection is a specific risk category that deserves its own space.
Malicious instructions can be embedded inside web pages, emails, or form fields in ways that a human would never notice but a browser agent reads as a command. A page that looks like an ordinary vendor invoice could contain hidden text directing the agent to submit a different amount, navigate to a different destination, or extract data and relay it somewhere else. Anthropic has publicly acknowledged that prompt injection is an unsolved, moving risk, and that every webpage the agent visits is a potential attack vector. [2]
This is not a reason to rule out browser agent use. It is a reason to be intentional about which pages you send the agent to, and which you do not.
The site-permission decision you need to make now
If your organization runs on an Enterprise plan, administrators can restrict Claude in Chrome to an approved list of domains. That control exists today. Whether your organization has configured it, left it open, or even considered it is a decision that should be made explicitly, before deployment, rather than discovered after something goes wrong. [1]
The most defensible starting position is a narrow site list. Pick one internal process on one specific site where the tasks are clear, the stakes are manageable, and the outputs are easy for a human to verify. Keep consequential actions—anything that submits a transaction, changes a record, or sends a communication—under human review until you have real-world evidence about how the agent behaves in your environment.
This is not overcaution. It is the appropriate posture when the safety evidence is vendor-published and the risk surface includes every page the agent visits.
Who checks the work
One gap managers consistently underestimate: browser agents produce outputs that look finished. A form was submitted. A record was updated. A status changed. Unlike a draft document sitting in a queue, browser actions can take effect immediately, without a natural review moment built in.
Name someone, before you start, whose job is to review what the agent did. Not a general understanding that the team will keep an eye on it, but a specific person with a specific cadence. Give that person the authority to pause agent access if something looks wrong. The oversight loop has to close somewhere, and it closes more reliably with a named owner than with shared responsibility.
The operating consequence
Claude in Chrome removes the engineering barrier that used to keep AI agents out of legacy systems and vendor portals. That is genuinely useful for teams managing fragmented tooling and manual data-entry work. It is also an expansion of what an AI can reach inside your organization's existing permissions structure, with no new provisioning process to slow it down or create a paper trail. [1]
Start with one task, one site, one reviewer. Confirm your Enterprise domain settings before this week is out. Treat any site that handles financial records or employee data as out of scope until independent evidence, not vendor assurances, shows that prompt injection risks are manageable in your specific environment.
The browser is now part of your AI risk surface. Treat it that way from the first deployment.