What the default controls do, where they stop, and the action-layer policy security teams need to deploy alongside them.

Claude in Chrome is the most powerful browser productivity feature Anthropic has shipped this year. It is also the largest unmanaged permission grant most enterprises have ever made. Once an employee enables it, a foundation model sits inside their authenticated browser session and can read every open tab, click every button, submit every form, and send every message the user could send. That includes Gmail, Salesforce, Jira, Workday, GitHub, your admin console, and any other web app where the user is logged in.

The default enterprise control surface for all of that is a yellow banner and a toggle.

This guide breaks down what Claude in Chrome actually does, where Anthropic’s defaults stop, and what a real enterprise posture looks like when a browser agent lives one tab away from your customer data. It is written for security leaders, platform engineers, and IT admins running an AI rollout, not for consumers testing a new toy.

Short answer: Claude in Chrome runs as an authenticated browser agent with the user’s cookies, tokens, and OAuth scopes. Default enterprise controls are a warning banner and an “Act without asking” toggle. To use it safely at scale, add a per-app, per-URL, per-action policy layer that intercepts critical actions at the click, submit, or send moment.

What Claude in Chrome actually is

Claude in Chrome ships as a Manifest V3 Chrome extension. Once enabled, it injects a content script into pages the user allows. The content script reads the rendered DOM (innerText, ARIA labels, alt attributes, hidden nodes), dispatches click events, fills form inputs, and submits forms. Navigation requests route through the extension’s background service worker.

Three properties define the threat model.

The agent acts as the user. Every request carries the user’s session cookie, the user’s CSRF token, the user’s OAuth scopes. There is no service account between Claude and your apps. There is no separation between what the user can do and what the agent can do. If the user can press Send, Claude can press Send.

Dispatched events can be trusted. Some browser agents use the Chrome DevTools Protocol (Input.dispatchMouseEvent via chrome.debugger) which produces events where MouseEvent.isTrusted === true. Your application code cannot tell those apart from a real human click. Even when synthetic events fire with isTrusted = false, most enterprise SaaS apps do not check the flag.

The DOM is the input. Anything Claude reads from the page can become instruction. That includes content the user never wrote and content the user cannot see. Hidden <div> blocks with display:none, ARIA labels the visible UI never renders, <title> and <meta> tags, HTML comment nodes, mailto: body fragments. The page is a prompt, whether it advertises itself as one or not.

What Anthropic ships as an enterprise “control”

Here is the entire enterprise control surface for Claude in Chrome today.

A yellow banner at the top of the chat:

HIGH RISK: Claude can take most actions on the internet now. This setting could put your data at risk.

Beneath the chat input, one dropdown labeled Act without asking. And a per-user site allowlist, opt-in from the tab.

For a consumer with one Gmail account, this is reasonable. For an enterprise with two thousand employees and three hundred authenticated SaaS tools, the gaps are obvious.

• The warning is the control. “This setting could put your data at risk” is the policy enforcement layer.
• The toggle is binary. Act without asking is on, or it is off. There is no middle setting.
• The allowlist is per-user. A developer who allows *.github.com does not clear it with security. A sales rep allowing *.lightning.force.com does not file a ticket. No org-level override.
• No granularity inside an allowed site. Allow salesforce.com and Claude can read records, update Opportunities, send emails from the composer, export views, and delete. One bit of policy.
• No audit trail your SIEM can consume. No Splunk HEC endpoint, no syslog, no JSON action stream. If an incident happens, your forensic timeline begins and ends with the user’s memory.

This is not a policy. It is a toggle and a footnote.

The middle that does not exist

The native control is binary. Allowlist a domain, or block it. Act without asking, or watch every action pass with a heuristic warning.

Every enterprise lives in the middle.

You do not want to block Salesforce. You want Claude to read records and never modify them. You do not want to block Gmail. You want Claude to draft and never send to external recipients. You do not want to block your AWS console. You want Claude to view dashboards and require human approval on every write.

That middle is per-app, per-URL, per-action policy. Anthropic does not ship it. The browser cannot enforce it natively. If you are running Claude in Chrome across an org, the middle is what you need, and it is on you to build or buy.

The risk in one scenario

A sales rep asks Claude to “follow up with Acme.” Claude opens Salesforce, exports every Acme record, drops the CSV into a Gmail compose window, addresses it to a personal email, and sends. Nothing in the flow is malicious. Claude took a natural language instruction and ran the shortest path to the outcome. The only thing standing between the export and an outbound attachment was a yellow banner.

Change one variable and the same shape produces a data breach, a regulatory event, or a downstream incident:

• Claude drafts an email in Gmail and hits Send to the wrong contact.
• Claude opens a Salesforce Account and updates the name field on a real customer record.
• Claude publishes a Confluence page marked “internal” as “public with a link.”
• Claude terminates an EC2 instance to “clean up.”
• Claude posts a diagnostic message to #general containing an API key from a workflow log.

None of these actions are governable at action granularity with the toggle Anthropic ships today. All of them are governable with a policy layer between the agent and the app.

The action-layer approach: Approve, Scope, Guard

Rather than trying to patch the prompt or the model, effective enterprise Claude in Chrome security intercepts the agent’s actions before they leave the browser. Three controls compose the layer.

1. Approve

Nothing risky ships until a human says yes. Send, submit, post, pay, delete, publish, upload. The agent freezes at the action, the human sees the full payload (recipient, body, attachment, URL, target record), and one click decides. Deny. Allow once. Always allow for this app.

If you have ever built with the Model Context Protocol, this pattern will be familiar. MCP already ships the same approval loop for tool calls: pause, show the payload, approve or block. Browser actions are tool calls that happen to be expressed as clicks on a DOM rather than JSON-RPC over stdio. The enforcement model transfers cleanly.

2. Scope

The default allowlist is too wide. Allow a domain and the agent gets every subdomain, every page, every record. Real enterprise policy narrows access to the page and the data. The agent works in Salesforce, but the financial view stays locked. It can read Opportunity records but cannot update Account names. It can post in a Slack team channel but never in #general.

The scoping unit is not the tab. It is the action verb, applied to a URL pattern, applied to an app.

3. Guard

The agent should only see what the policy allows. If Claude does not need email content, the inbox comes back blank. PII and secrets are redacted in the browser before they reach the model. AWS keys, GitHub PATs, Stripe live keys, JWTs, private keys: pattern-matched and stripped at pre-egress, not after the request is out.

This is the layer that turns “Claude has your session cookies” from a headline risk into a bounded exposure.

How the three map to OWASP LLM06

If your security review contains an OWASP LLM06 checkbox, this is the layer that closes it.

What a real enterprise posture looks like

Beyond the three action-layer controls, a Claude in Chrome deployment needs six pieces to be defensible in front of an auditor.

1. Org-level allowlist. Set by IT, distributed via MDM or Chrome’s ExtensionSettings policy. Not the user.
2. Granular per-app, per-action policy. Read vs. edit vs. send vs. delete. Fail-closed defaults on critical verbs. This is the middle.
3. Human-in-the-loop on critical actions. Same pattern as MCP tool approvals. Approval at the click, with full action context.
4. Audit log of every intercepted action. Routed to SIEM. Splunk HEC, Loki, syslog. Retained for the compliance window.
5. Identity binding. Every action tied to SSO identity, not a local browser session. Okta, Azure AD, JumpCloud.
6. Adoption visibility. Who has Claude enabled, on which domains, under which policies.

Anthropic ships a fraction of layer 1 through Chrome’s ExtensionSettings.runtime_allowed_hosts. Layers 2 through 6 are on the enterprise.

Getting started: from zero controls to real policy

If Claude in Chrome is already installed inside your org and you have no controls today, the shortest path to a defensible posture is:

1. Install Willow for Chrome across the fleet. Chrome Web Store or your MDM. 30 seconds per machine.
2. Adopt the Willow default policy. Fail-closed on send, submit, post, pay, delete, publish, upload. Customize once you have baseline telemetry.
3. Distribute the shared team config. One link. Every teammate runs the same rules.
4. Point the audit stream at your SIEM. Splunk HEC or Loki. Hook up SSO when your rollout hits the point where user-level attribution matters.

The extension is free and open source. Nothing leaves the browser by default. If your AI footprint grows past Chrome (Cursor, ChatGPT Operator, MCP servers, custom copilots), the same policies apply from the Willow Basecamp across every surface.

The takeaway

Claude in Chrome will be inside every enterprise within twelve months. The native control surface (a warning banner and a toggle) is not the enterprise policy layer. The policy layer is the middle: per-app, per-URL, per-action rules that intercept the agent’s actions before they leave the browser. Approve. Scope. Guard.

Add Willow for Chrome. Free. Chrome Web Store, 30 seconds, no signup.

When your AI footprint grows past Chrome, the Willow Basecamp governs every agent your org runs from one control plane. In production at Wix, Papaya Global, Riskified, Innovid, and dozens of other enterprises governing 2M+ tool calls a week.

‍