Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Is Claude in Chrome Safe to Use for Work?
No, not on work accounts whose pages carry customer, account or financial data, because Anthropic's own safety page says the extension can't filter sensitive content out of what it sees. It becomes workable only when values are replaced on the screen before the model reads it, a named person approves each action, and a record exists.
A marketing manager who asks Claude in Chrome to pull last week's spend from an ads console is handing the model a screenshot of whatever that tab shows, and if the company bank is signed in two tabs over, the same Chrome profile holds that session as well. The security team's question is where the line sits. Anthropic draws part of it: the extension does not filter sensitive content out of what it sees, so the vendor's advice is a profile set aside for the agent. That advice puts the boundary around the profile, and leaves the values on the pages inside it where they were. The dedicated profile narrows which tabs exist; it does nothing to the pages inside it, so the account IDs, billing contacts and customer names on those pages still reach the model, and in an everyday profile every open tab is within reach of the next screenshot as well. That is why the answer for work accounts is no as shipped, and why the condition that changes it is a control on the screen itself. What follows reads the vendor's safety guidance against the research on web agents and prompt injection, with one ads-console task worked through the record twice, once in a profile that also holds the bank and once in a profile that holds only the console, to show what the model received each time and what a team should ask for in writing before the extension touches a work account.
Key findings
- For Claude in Chrome to be safe on those accounts, the values on a rendered page would have to be replaced with consistent tokens such as ACCT_001 before the model reads the screen, with the real values resolving only at the approved destination at the moment of an approved action (What Is Render-Layer Tokenization?).
- It would also require a named person approving every payment, submission and record change the agent proposes, with every screen the model received, every action and every approval landing in a record the employer holds (What Is Supervised Delegation?).
- Anthropic's own safety page describes site blocking, permission prompts and password-manager fills; it does not describe replacing values on a rendered page before the model reads it (Anthropic, 2026).
- Anthropic's help center states that Claude "can't filter sensitive content out of what it sees" and recommends a separate profile for Claude in Chrome, a statement of scope rather than a control on the page the model reads (Anthropic, 2026).
- The AgentDAM benchmark found that web agents built on GPT-4, Llama-3 and Claude "are prone to inadvertent use of unnecessary sensitive information" (Zharmagambetov et al., 2025).
- Harvard's guidance for AI systems states that "the riskiest agent setup combines three things: access to private data, exposure to untrusted content, and the ability to send data outward," and advises removing any one of the three where it can be done (Harvard, 2026).
What does Claude in Chrome receive from the screen?
Take the marketing manager's task as the record. She opens the ads console in her everyday Chrome, where the company bank, the payroll portal and her own mailbox are signed in, and asks Claude to pull last week's spend by campaign. The safety page states that "Claude takes screenshots of your active browser tab to understand webpage content" and that "whatever is visible in one of those tabs is captured in the screenshots and becomes part of the conversation" (Anthropic, 2026). The screenshot carries the campaign table she asked about, the account ID in the header, the billing contact in the sidebar and the notification that slid in from the mailbox while the page loaded.
The extension reads the page as a picture of everything the tab renders, the same surface a computer-use agent perceives, which is why neighboring records and open tabs end up in its context. OWASP's entry on sensitive information disclosure warns that "personal identifiable information (PII) may be disclosed during interactions with the LLM," and a screenshot is one such interaction (OWASP, LLM02, 2025). The vendor's own account of what the extension can reach, on its help pages, is laid out in What Can Claude in Chrome Access in Your Browser?.
For the manager, the task she gave and the data the model received are two different sets, and only the first was chosen by her. Nothing on the console page is replaced before the screenshot leaves the browser, so the account ID and the billing contact sit in the model's context for the rest of the session. Every control the vendor documents sits downstream of that fact. Claude in Chrome is one of the 15 AI agents reviewed for screen-data controls, and none of the 15 describes replacing customer data on a working page with tokens the agent can work with (Do AI Agents Ask Before Making a Payment?).
Does a separate profile make Claude in Chrome safe for work?
Anthropic recommends a separate profile for Claude in Chrome, and inside that profile the model still receives whatever the open tab shows (Anthropic, 2026). The profile boundary keeps the bank, the payroll portal and the mailbox in a different Chrome, a real reduction in what a screenshot can carry and the right first step. Measured against the three-part rule quoted above, it removes part of the private data from reach and leaves untrusted content and the ability to send data outward in place.
Coder's guidance for running agents says "be sure not to give agents full permissions on behalf of a user, and instead use separate identities with limited scope whenever interacting autonomously," advice written for coding agents that applies with equal force to an extension in a person's own browser (Coder, 2026). The extension also sits outside the software inventory a desktop team manages, as Thomas Livers, Associate Athletic Director for IT Services, University of North Carolina at Chapel Hill, said: "our users can't install software just on their computers, but obviously you could probably get a browser plugin without having elevated access." (Does Banning AI Work? A University IT Leader on Athlete Data, FERPA and AI Governance). Columbia's DAPLab states that "trustworthy agent automation cannot be solved at a single layer of the stack," and a profile boundary is one layer (Columbia, 2026).
For the ads-console task the profile decides which accounts the agent can reach, and leaves what the model receives from the console unchanged, since the campaign table, the account ID and the billing contact render the same way in either profile. The same split appears wherever an agent runs inside a person's own browser: the vendor's controls govern what the agent may do, and what its model is shown on a permitted page is left to the page (Should an AI Agent Use the Employee's Own Browser?). Which profile an agent opens with and which values it is shown are separate decisions. The recommendation is best read as a scope statement: keep these accounts away from the extension, because it has no control of its own over what it reads from the accounts that remain.
What do the vendors themselves say?
Anthropic's safety page is the primary record, and it is specific about where its controls act. Anthropic documents that "for your safety, Claude cannot access sensitive, high-risk sites" and that "Claude asks for permission before accessing financial sites," controls on where the extension may go rather than on what the model receives from a permitted page (Anthropic, 2026). With the 1Password integration, "1Password fills the login directly, and your passwords and one-time codes never enter Claude's context," a control on the login step and not on the pages that open after it (Anthropic, 2026). The page also lists "action confirmations for certain high-risk actions such as downloading a file or entering sensitive information," confirmations addressed to the person at the keyboard rather than to an employer (Anthropic, 2026). An employer-held record of which screens the model received is not described in the pages reviewed.
| Dimension | Anthropic, per its documentation | What a buyer should verify |
|---|---|---|
| What the model receives | Screenshots of the active tab; whatever is visible becomes part of the conversation | Which values on a permitted page reach the model, field by field |
| Where the extension may go | Sensitive, high-risk sites blocked; permission asked before financial sites | Who sets the list for a work profile and whether a user can change it |
| Logins | 1Password fills the login; passwords and one-time codes never enter the context | What the pages after login show, since the control ends at the login step |
| Consequential actions | Action confirmations for certain high-risk actions | Who, other than the user, can see or hold the confirmation |
| Pages with hidden instructions | Claude may treat malicious instructions as requests from the user; review proposed actions | What a successful injection can collect from the open tab |
| Record | No exported record of what the model received appears on the safety page | What an auditor can be shown for one run, screen by screen |
Read together, the documented controls govern three things: which sites the extension opens, how a login is typed, and whether a high-risk action pauses for the user. None of them changes the content of a permitted page before the model reads it, which is the gap the ads-console record exposes. Whether the extension uses sessions already open in the browser is a separate question with the same shape, which Does Claude in Chrome Use Your Saved Logins and Open Sessions? takes up on its own.
What happens when a page the agent reads carries hidden instructions?
An ads console renders text that other people wrote: ad copy, landing-page previews, comments left by an agency. On prompt injection, Anthropic warns that "Claude may interpret these malicious instructions as legitimate requests from you" and advises users to "review Claude's proposed actions before approving them, especially on new websites" (Anthropic, 2026). That places the defense on the person reviewing each proposed action, and on a long task a person approves quickly.
The research record says the defense should not be expected to hold on its own. OWASP's prompt injection entry states that "indirect prompt injections occur when an LLM accepts input from external sources, such as websites or files," and its mitigation is to "restrict the model's access privileges to the minimum necessary for its intended operations" (OWASP, LLM01, 2025). An adaptive-attack study bypassed 12 published defenses against jailbreaks and prompt injections with an "attack success rate above 90% for most," many of which had reported near-zero rates (Nasr et al., 2025). Instructions can also sit where a person would never notice them and a screenshot-reading agent would, as faint text inside an image (Can Hidden Text on a Web Page Hijack a Browser Agent?).
For the manager's task the question that matters is what a successful injection collects. In her everyday profile it collects the account ID, the billing contact and anything the bank tab showed, with open sessions to act through. In the dedicated profile it collects the console's own values, which is less, and still the data the organization would least like to see leave. The useful control limits what the model holds when the defense misses.
What should a security team ask for in writing before approving it?
The approval memo for a browser extension that reads work screens should answer five questions, each in a form the vendor or the environment can put in writing.
- What does the model receive from each rendered screen on a permitted site, and which values on that screen are replaced before the model reads it? If the answer is the whole screenshot, record that as the exposure for every task the extension will run.
- Which profile does the extension run in, who configured it, and which accounts are signed in there? A dedicated profile that drifts back to everyday use within a month has stopped being a control.
- Who approves a consequential action, and does that approval reach anyone other than the user at the keyboard? A confirmation shown to the person who asked for the action is a safeguard for that person, and an employer needs a named approver whose decision is kept.
- What record exists of one run, screen by screen, and can it be exported to the organization's own logging? Ask to be shown it for a real task, including the page as the model read it.
- What does a successful injection collect? Ask the vendor to answer for a permitted page in the configured profile, since the answer for a blocked site is not the one that matters.
For the ads-console record, the memo would note that the first question is answered by the vendor's own statement that the extension cannot filter what it sees, that the second is answered by configuration the team controls, and that the third and fourth are answered on the safety page only for the user's side. The fifth is answered by the first. Written down, the five answers are a baseline to compare against any other browser agent and against the same extension after its next update.
What does a governed environment change?
A governed environment changes the first answer, and the others follow from it. Values a policy names, such as an account ID, a billing contact or a customer name, are replaced with consistent tokens on the rendered page before any model reads the screen, so the same account appears as ACCT_001 on every page of a run and the model works on the token. The real value resolves only at the approved destination at the moment of an approved action, which means a value the model never held cannot be carried out of the session by a summary, a chat message or an injected instruction. A named person approves each payment, submission and record change, and every screen the model received as tokens, every action and every approval is written to a record the organization exports to its own logging.
Applied to the ads-console task, the campaign table reaches the model intact, the account ID and billing contact reach it as tokens, and the profile question becomes less load-bearing, because a bank tab rendered inside the governed environment would also render as tokens. The profile still matters for sessions and reach; the control on the screen does not depend on it. That is the difference between an enterprise browser control that travels with the browser and acts on what a person copies, pastes or uploads, and a control that acts on what the model is shown; the comparison with one such product sets the two side by side (RedactSure vs Akamai Workforce Protector: 2026 Comparison & Alternative). For a team deciding on Claude in Chrome, the control class answers the approval memo without relying on filtering the vendor has said the extension does not have.
What the record shows
What the model receives from a rendered screen, who approves the action and what record remains are the three facts that decide whether a browser agent is safe on a work account, and the first decides the other two. For Claude in Chrome, the vendor's documentation settles the first: the model receives the screenshot of the active tab, and the extension does not filter sensitive content out of it. So the extension is not safe on a work account whose pages carry sensitive data: the dedicated profile the vendor recommends narrows which tabs exist and leaves every value on a permitted page in the model's context, with approval resting on the user and no employer-held record of the screens described. What changes the answer is a governed environment that replaces those values with tokens before the model reads the page, puts a named person on each action, and keeps the record. A security team can test this on its own system by opening one console in the dedicated profile, running one read-only task, and listing every value visible on that screen beside the values the task needed; the gap between the two lists is the exposure the profile does not close.
Methodology and limitations
This page rests on vendor documentation (Anthropic's safety page for Claude in Chrome and Coder's guidance for running agents), peer-reviewed and preprint research on web agents and adaptive attacks, OWASP's entries on prompt injection and sensitive information disclosure, and university guidance from Harvard and Columbia, read in full. Public documentation read in full gives a sound view of where each product applies its control. Vendor pages were read between October 16, 2026 and October 20, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation and none was tested for this page; "not described" means the pages reviewed, vendor features change, and the page carries its date. RedactSure is deploying now with enterprise and government customers. The ads-console example describes a record type, not an organization. Determinations belong to counsel, assessors and the organization's own security and compliance officers, and nothing on this page replaces a pilot of one workflow on the organization's own screens.
Frequently asked questions
Is Claude in Chrome safe to use for work?
No, not on accounts whose pages carry customer, account or financial data, because the model receives the whole screenshot of each permitted page. Anthropic's safety page says the extension cannot filter sensitive content out of what it sees and recommends a separate profile, which limits which tabs exist rather than what a tab shows. For read-only tasks on pages that carry no sensitive data, the profile is enough. For pages that do, the answer changes only when values are replaced on the screen before the model reads it and a named person approves each action.
What does Anthropic recommend for the browser profile?
A separate profile for the extension, kept apart from the user's everyday browsing. The reasoning follows from the vendor's own statement that the extension takes screenshots of the active tab and that whatever is visible becomes part of the conversation, so the fewer accounts signed in, the less a screenshot can carry. The recommendation is addressed to the user; a security team should decide who configures the profile, who audits what is signed in there, and how often that check is repeated.
Does blocking financial sites keep account data away from the model?
Only for sites on the blocked list. The vendor documents that the extension cannot access sensitive, high-risk sites and asks permission before financial sites, which governs navigation. An ads console, a CRM or a support desk is a permitted page, and the account IDs, card fragments and customer names it renders reach the model in the screenshot like any other pixel. Site blocking decides where the extension goes, and a permitted page decides what the model sees.
Does the 1Password integration keep passwords out of Claude's context?
Yes, for the login step: the vendor states that 1Password fills the login directly and that passwords and one-time codes never enter the model's context. The control ends when the login succeeds. The account page that opens next, with its balances, contacts and identifiers, renders to the model in full. A password manager protects the credential; it says nothing about the pages the credential unlocks.
What can a hidden instruction on a page make the extension do?
Whatever the user could do from that tab, subject to the action confirmations the vendor shows for high-risk steps. Anthropic warns that the model may treat malicious instructions on a page as requests from the user and tells users to review proposed actions, especially on new sites. The research on adaptive attacks shows published defenses failing at high rates, so plan for the case where the review misses, and ask what the model holds at that moment.
What record does an employer get of what the extension read?
Not from the pages reviewed. The safety page describes confirmations shown to the user and advice to the user, and no exported record of the screens the model received. An employer who needs to show an auditor what an agent read on one run needs that record from the environment the agent runs in, screen by screen, with the approvals attached. Ask for it before approving the extension for any account that holds regulated data.
How RedactSure Keeps Account Data on Work Screens Away From the Model
A dedicated profile decides which tabs the extension may open and leaves every value on those tabs in the screenshot. Anthropic's safety page says the extension can't filter sensitive content out of what it sees.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the ads console rendered the campaign table with the account ID and billing contact, and the screenshot of all of it entered the model's context. Inside the governed environment: the console renders with ACCT_001 and CONTACT_001 in their place, the model works on the tokens, the real values resolve only at the approved destination when a named person approves an action, and every screen, action and approval lands in the AI Control Record.
RedactSure is deploying now with enterprise and government customers.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
Whether a work account is safe behind the extension comes down to what the model read from the screen. Bring one console task your team runs and see, with test values, the page as the model receives it, the approval, the record. Book a demo