> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation.md). # 3.4 Internet access and browser automation Browser agents operate near the user’s signed-in sessions, so controls must cover page context, blocklists, per-site approval, and browser bridges. *Last reviewed: August 18, 2026* {% hint style="info" %} Browser agents act inside a live web session. Sensitive sites need explicit policy before an agent can read, click, submit, or copy from them. {% endhint %} ## Internet access and browser automation: what security teams need to know Browser automation gives agents a high-context view of the web. It also exposes them to hidden instructions, malicious pages, customer data, admin consoles, and live authenticated sessions. The browser should be treated as an action surface, not a research tool. Reading a page, clicking a button, and submitting a form are different risk levels. This handbook uses "browser bridge" as an umbrella term for the connection that lets an AI client observe or control a live browser session; Claude in Chrome and the ChatGPT Chrome extension are the current named examples. ## Common internet access and browser automation security failures * Sensitive sites are allowed because the browser is considered user-driven. * The agent reads pages in a signed-in admin console. * Default blocked categories are treated as a complete policy. * A page injects instructions that steer later tool calls. * Users approve site access without understanding the account context. ## Internet access and browser automation security controls checklist * Create a sensitive-site list for HR, finance, healthcare, cloud, identity, password, legal, and customer systems. * Require explicit approval for sensitive sites and write actions. * Disable browser bridges for groups that handle regulated data unless there is a reviewed use case. * Log URL, page class, action type, approval, and resulting tool calls. * Pair browser policy with network and DLP controls. ## Anthropic ### Overview The Anthropic browser surface is Claude in Chrome: a browser extension that lets Claude read, click, and navigate websites inside the user's signed-in session. It has two modes, "Ask before acting" (plan approval scoped to listed websites) and "Act without asking", with per-site permission prompts, and downloads, sensitive data entry, and authorizations always require approval regardless of mode. Team and Enterprise admins can set allowlists and blocklists that constrain which sites Claude can access no matter what an individual user permits. Who gets the extension at all is a role decision: Enterprise custom roles include Claude for Chrome as a controllable capability, so security can restrict the browser surface to reviewed groups. Cowork can also use Claude in Chrome from remote sessions through the desktop app; if the device or app is offline, the remote session cannot reach the browser. Treat everything the extension reads on a page as untrusted input that can steer later actions. Claude Tag separates web search from sandbox network access. Channel sessions can use Anthropic's server-side web search without an Access-bundle domain entry, while opening a URL or calling a service from the sandbox must pass Agent Proxy. Review search as an untrusted-content source even when the egress allowlist correctly blocks direct page fetches. ### Anthropic documentation * [Claude in Chrome permissions guide](https://support.claude.com/en/articles/12902446-claude-in-chrome-permissions-guide) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) * [Use Claude Cowork safely](https://support.claude.com/en/articles/13364135-use-claude-cowork-safely) * [How Claude Tag agent identity works](https://claude.com/docs/claude-tag/concepts/agent-identity) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI has three current browser patterns with different boundaries. ChatGPT agent mode runs on an OpenAI-hosted virtual computer. The built-in browser is available in ChatGPT on the web and in the ChatGPT desktop app, where it uses a profile separate from the user's regular browser. The ChatGPT Chrome extension is the high-context option because it attaches Work or Codex to the user's existing signed-in Chrome state. The permission and evidence plan must follow the chosen pattern. A separate browser profile reduces accidental access to existing sessions but still holds any accounts the user signs into for the task. The Chrome extension carries the authority of the regular profile. ChatGPT Work on web and mobile follows workspace browser and network controls, while desktop Work follows the local permission plane. Atlas is no longer a rollout target: OpenAI says it will stop working on August 9, 2026 as browser capabilities move into ChatGPT and Codex. ### OpenAI documentation * [Introducing ChatGPT agent: bridging research and action](https://openai.com/index/introducing-chatgpt-agent/) * [ChatGPT Chrome extension](https://learn.chatgpt.com/docs/chrome-extension) * [Browser](https://learn.chatgpt.com/docs/browser) * [ChatGPT Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) * [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [ChatGPT desktop app and Codex clients](https://learn.chatgpt.com/docs/features) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about internet access and browser automation ### Why are browser agents risky? They read and act inside a signed-in web session, where the page itself is untrusted input: hidden text or malicious markup can inject instructions that steer later actions, and the session carries the user's real authority in admin consoles, mail, and SaaS tools. The combination of attacker-controlled content and user-level credentials is what makes this surface different from an API tool call. ### Which websites should be blocked first? Start with password managers, identity-provider admin pages, cloud consoles, HR, payroll, healthcare, financial, legal, and customer-admin systems: sites where a single agent action or copied page is an incident. Use the platform blocklists where they exist; Claude in Chrome and the Codex Chrome extension both support admin-managed blocklists. Vendor default protections are a floor, not your policy. ### Is read-only browser access safe? Safer than write access, but not safe by default: an agent that only reads can still copy sensitive page content into prompts, outputs, or tool calls, which is an exfiltration path in itself. Injected page content can also steer what the agent does next outside the browser. Treat read access to sensitive sites as a data-handling decision, not a harmless default. ### What is a browser bridge? Browser bridge is this handbook's umbrella term for the connection that lets an AI client observe or control a live browser session; concretely, extensions such as Claude in Chrome and the ChatGPT Chrome extension. Disabling the bridge removes the whole path, while per-site permissions and allowlists narrow it. The term does not appear in vendor documentation, so use the product names when reading vendor docs. ### How should browser actions be audited? Record the site, account context, action type (read, click, form submit), the approval that permitted it, and any downstream tool calls the page content triggered. Be realistic about coverage: hosted browser surfaces, the desktop app's separate browser profile, and extensions attached to a regular profile emit different evidence. Keep endpoint and target-system logs in the plan. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy.md) * [3.3 Network egress control](/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control.md) * [3.5 Computer Use / desktop control risks](/handbook/3.-runtime-sandbox-and-autonomy/3.5-computer-use-desktop-control-risks.md) * [5.1 Prompt injection: the connective risk](/handbook/5.-threats-and-adversarial/5.1-prompt-injection-the-connective-risk.md) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.