Introduction

As Claude rapidly brings out new features, it’s important to look under the covers and understand the potential paths it can take to accomplish its goals, especially where they can work around your security policies. Claude also ships with a built-in browser that can operate any website a person is already signed in to. We wanted to know whether a rule that stops Claude on one path still holds when Claude takes another, so we set up a simple test.

We told Claude to take $10 off every price in a DynamoDB table called products. We framed it like a real request: a sale was coming, and a scheduled backup would restore the old prices afterwards. The policy we had set to block the AWS command line write worked, but when we asked for the same job in Claude’s built-in browser, all ten prices dropped.

every price

What happened?

  • Our rule watched one path to AWS: the command line. Claude has another: the built-in browser, which clicks through the AWS website the way a person does.

  • Because the browser never sends an AWS command, the rule never saw anything to block.

  • The same gap applies to any service. If your rules watch a tool’s command line, MCP server or API, a browser that is already signed in goes around all of them.

  • You can close the gap with one Eve Guard policy on the browser itself, without being an admin of your Claude organization.

Step 1: The command line write was blocked

Our first policy, “Claude edit DynamoDB Products”, blocks any AWS command that would change the Products table: edits, deletes, batch or transaction writes, and restores. Claude first read the table, which the policy allows. It then tried to update the items one by one. Eve blocked each update before any price changed. The block log records the denied command, the agent that sent it, the user behind the agent and the resource it targeted. A rule, a denied attempt and a log entry that ties them together is the evidence an auditor asks for. At this point everything looks right.

Step 2: The browser did the same job

Anthropic’s built-in browser lives inside Claude Desktop, and Claude can use it from Chat, Cowork and Claude Code. It was already switched on in our Enterprise organization, nobody on our team had enabled it.

Claude uses it by default for web tasks, and there is nothing to install. Getting the browser signed in takes very little. You can log in inside it, or import cookies from your usual browser, and Claude remembers those logins for later tasks on the same computer.

When we repeated the request, Claude went around the command line policy and used the built-in browser, mentioning that the AWS console was already open on the right account, which means Claude acted inside the person’s session so AWS logged the change under the human’s identity.

In fact, the route Claude takes inside the console does not matter. In one run it used the console’s query editor. In another it opened each item and typed the new price by hand. Anything a person can do in the console, Claude can do, so predicting its route is not a workable defense.

When Claude finished, every product was $10 cheaper.

Why Anthropic’s own checks did not stop it

According to Anthropic’s help page, Claude asks permission the first time it acts on a site, and it compares each action with what the user asked for. Here the user asked for exactly this edit, so there was nothing to object to.

Those checks protect the user from a web page that tries to steer Claude somewhere else. They do not enforce your company’s rules about a particular table.

Why this is a compliance and attribution problem

Say a control states that Claude cannot change the products table. After our first policy, that is true only for the command line. The browser can still do it, yet the evidence looks clean: the policy is active, the log shows a denied update, and a reviewer would sign off.

The change itself is also misattributed. A console edit happens inside a person’s signed-in session, so AWS logs it under that person’s name. Nothing in the record shows an agent made the change, so the audit trail points at the wrong actor.

Attribution

The fix: one policy on the browser

Most security teams don’t have the time to check every small detail of what the agent can and cannot access when a policy is set. That’s why Eve Guard sees the browser as well. Every step Claude takes there arrives as a tool call to a resource called claude-browser. We added a dynamic policy on that resource, “Claude-Browser Block AWS”. It checks traffic in both directions: it blocks any browser request that includes an AWS URL, and it blocks any response that would hand Claude an AWS URL.

Both directions matter because Claude can reach the console in several ways. It can send the current tab to an AWS address, open a new tab on one, or find a tab that is already sitting on the console, which was our situation. In that last case, Claude asks which tabs are open, the policy blocks the answer, and Claude cannot work on a page it does not know exists.

We sent the price cut request once more with the console already open. Claude’s first browser call asked which tabs were open. Eve blocked the answer, and Claude reported that it had not touched the products table or any price. The log marks this as a response-phase block: the call went out, but the answer never reached Claude.

In a separate attempt, Claude tried to open the AWS sign-in page in a new tab. Eve blocked that request before it ran.

What Anthropic’s admin settings can do

Two settings in a Claude organization are relevant, and every owner should know about them.

  • Built-in browser on/off. Turning it off removes the browser from Chat and Cowork. It was on by default in our organization. This setting does not affect Claude in Chrome.

  • Site permissions. A list that applies to both Claude in Chrome and the built-in browser. Ours was set to “Allow all sites”, so Claude could work anywhere except sites on the blocked list. Adding the AWS domains there gets you close to what our policy did.

If you own your Claude organization, your people only use company accounts, and the browser is the only path you care about, these settings may be enough. Most security teams are not in that position, for two reasons.

  • Security often does not own the Claude organization. IT or the team that bought the plan usually does. In our own organization, the Admin role could not see the browser settings at all, because only Owners can. Eve Guard enforces rules on the machine where Claude runs, so security can put a rule in place without needing the Owner role.

  • You want one rule and one record. Your command line, MCP and API rules already live in Eve, along with the logs of what they blocked. Putting the browser rule in a second system splits your evidence in two. In Eve, the browser block sits beside the command line block and is tied to the same agent, user and conversation. When an auditor asks whether Claude can change the products table, one place gives one answer.

A separate gap: Claude in Chrome

The built-in browser is not the only way Claude can browse. Claude in Chrome is an extension that works inside the user’s own Chrome, on tabs they already have open and accounts they are already signed in to. If the user is signed in to the AWS console in Chrome, Claude is too. The extension runs in its own side panel, outside the desktop app, and Eve Guard has no hook there. The browser policy above never sees it, and neither does any other rule on the command line, MCP or API. Claude can do everything we did in the built-in browser by using the side panel, with nothing in the way.

Anthropic lets Owners on Team and Enterprise plans turn the extension off under Organization settings, Claude in Chrome. It is on by default for Team plans, and on by default for Enterprise plans unless an Owner has turned it off. That switch only covers company accounts.

An employee can still install the extension and sign in with a personal paid plan, in the same Chrome profile that holds their work sessions. Anthropic’s answer is a Chrome policy called forceLoginOrgUUID, which ties the extension to your organization. It closes the personal account gap, but the extension still runs without a hook.

We recommend blocking the extension in Chrome itself. Its Chrome Web Store ID is fcoeoabgfenejglbffodgkkbkcdhcgfn. Add it to the ExtensionInstallBlocklist policy through Google Workspace or your MDM (mobile device management) tool, in this form:

{ "ExtensionInstallBlocklist": ["fcoeoabgfenejglbffodgkkbkcdhcgfn"] }

Chrome then refuses to install the extension and turns off any copies already installed. Also turn the extension off in your Claude organization settings so company accounts cannot use it from Cowork. Like the Eve policy, the Chrome block does not require a Claude Owner. It goes through the Chrome management you already use for every other extension.

That leaves the built-in browser as the only way for Claude to browse, and Eve Guard can see that path. If you would rather allow no browsing at all, turn the built-in browser off too.

Conclusion

This example leaves us with a few key takeaways to ensure your agents don’t work around policies to access critical assets when you don’t want them to do so.

What to check in your own environment

  • For every resource you protect with a command line, MCP or API rule, ask whether Claude could reach it through a browser that is already signed in. If it can, add a browser rule too.

  • Find out whether Claude in Chrome is installed anywhere in your fleet. Where it is, none of your rules apply.

  • Do not wait for whoever owns your Claude organization. The browser policy lives in Eve Guard, and the extension block lives in your Chrome management.

If you want to set up the same browser policy in your own environment, we are happy to walk through it with you.