CSIPE

Published

- 21 min read

When a Browser Extension Becomes the AI Agent’s Command Channel

AI Agents Browser Security Extension Security DevSecOps

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

A browser extension asks for permission to change pages and network requests. You approve it because that is what an ad blocker or privacy tool does. Later, the browser gains an AI panel that can read a tab, open a file, take a screenshot, or click through a task. The old extension has not requested those new powers. Yet a security boundary now sits between it and a component that has them.

On 16 September 2026, Forever Security published research showing how that boundary failed in five Chromium-based products. Its proof-of-concept extension reached Gemini Live in Chrome, Perplexity Comet, Microsoft Edge Actions, Opera Neon, and Claude in Chrome. The researchers called the family of demonstrations BragJack. Depending on the product, they said the extension could inject commands into the AI path, read local files, obtain browser information, take screenshots, or reach the camera and microphone (Forever Security: BragJack technical overview).

The restraint around that finding matters. These were controlled demonstrations, not reported attacks in the wild. Every path began with a malicious extension already installed in the browser. Two findings have public vulnerability records; the other three rest on the researchers’ account and coordinated bug-bounty results. By 16 September, both recorded flaws had been repaired, and neither appeared in the US Known Exploited Vulnerabilities catalogue, according to independent reporting (The Hacker News: one extension could hijack five browser AI products).

That does not make the work a curiosity. It exposes a design problem that will outlive these exact bugs. Browser extensions and browser agents are usually reviewed as separate features. On the same machine, they form one permission system. A low-authority component can become dangerous when it can speak through a high-authority one.

What the researchers actually showed

BragJack was not one universal software defect. Forever Security built five related demonstrations around the same architectural seam: a browser-side AI component trusted messages or code arriving through a particular web origin, marketing page, or extension channel. The malicious extension found a way to influence that trusted route and make the AI component accept work the user had not requested.

The Chrome case had the clearest public record. Chrome’s Gemini Live interface paired an internal browser page with an embedded Gemini web page. Extensions were supposed to be unable to tamper with that embedded, privileged context. Forever Security found that extension rules for modifying network requests still applied inside the embedded page, allowing its proof of concept to replace a script and inject code. Google’s vulnerability record describes the prerequisite plainly: an attacker had to convince the user to install a malicious extension (CVE Program: CVE-2026-0628).

Google fixed that flaw in Chrome 143.0.7499.192, released on 6 January 2026. The Chrome release note names CVE-2026-0628 as a high-severity policy-enforcement problem in the WebView component and credits Forever Security researcher Gal Weizman (Chrome Releases: stable channel update for desktop). The September article joined that earlier Chrome work to four later demonstrations, so “new research” does not mean every underlying fix arrived in September.

In the researchers’ Chrome demonstration, injected code could ask the privileged browser component to open a local file and return its contents or a screenshot. They also reported access to browser profile information. The camera and microphone consequence came from the attacked Gemini pane’s existing media authority, according to Forever Security. Those are claims about the demonstrated path, not evidence that ordinary extensions have silently gained those powers on current Chrome builds.

Perplexity Comet used a different connection. Its built-in agent extension accepted messages from a list of Perplexity web origins. The main origin received extra protection, but a test origin on the accepted list did not receive the same treatment. Forever Security said its extension prevented that test address from redirecting away, attached code there, and then sent messages to the browser agent. In the demonstration, that route exposed browsing history, screenshots, local files, and agent actions.

Microsoft Edge had stronger obstacles, which makes its failure useful to study. Its sample marketing page could place a suggested task into the AI panel, but Microsoft separated passive “think” behavior from active “do” behavior. Forever Security reported a timing flaw that let its extension force a prompt while action tools were disabled, then enable those tools before the agent checked what it could do. Microsoft tracks the issue as CVE-2026-55945, a race condition that could disclose information locally, and identifies Edge versions before 150.0.4078.48 as affected (CVE Program: CVE-2026-55945).

The Opera Neon and Claude in Chrome findings had no public CVE as of 21 September 2026. Forever Security said an Opera web page could send commands to Neon’s agent while remaining open to extension interference. It said Claude’s browser extension included a page that could populate its side panel from a page element, which another extension could manipulate. The Hacker News independently reported the disclosure claims, bounty amounts, and product distinctions, while making clear that these three cases depended on Forever Security’s account rather than public vendor advisories.

The numbers deserve the same care. Forever Security’s table lists rewards of $7,000 for Chrome, $7,000 for Comet, $5,000 across two Edge findings, $900 for Opera, and $600 for Claude. Those rows total $20,500, although its prose says $20,000. That small mismatch changes nothing about the mechanism, but it is a useful reminder not to turn a bug-bounty total into proof of impact.

No single “BragJack patch” exists because the products did not share one broken line of code. Chrome needed to stop an extension’s request rules from crossing into the privileged embedded page. Edge needed to close a race and tighten a trusted marketing route. The other vendors had their own message boundaries to repair. The shared failure was architectural: a component with ordinary extension permissions could influence the channel feeding instructions to a more capable agent.

How ordinary permissions inherited extraordinary reach

The browser extension model tries to make authority visible. An extension declares the permissions and website access it needs. The browser shows some of that request to the user, and managed organizations can decide which extensions are allowed. The model is imperfect, but the intended question is understandable: what can this add-on touch?

Agentic browser features add a second authority system. The agent may read the active page, capture a screenshot, open tabs, fill forms, use local files, or take actions in a signed-in session. Each product exposes a different set of powers, and some require confirmation. The crucial point is that these powers belong to the browser-side agent, not to every installed extension.

BragJack connected the two systems. The extension did not need a permission named “read every file through Gemini” or “make Edge act on a hidden prompt.” It needed influence over a page or message path the agent already trusted. Once the agent accepted the instruction, the action happened under the agent’s authority.

That is a confused-deputy problem in practical clothes. A deputy has legitimate power to do something for an authorized caller. Trouble begins when another caller can make the deputy exercise that power without proving who asked. The AI model can be perfectly obedient and still participate in the failure. It is obeying a command that arrived through a channel the product treated as trusted.

The request-modification permission used in several demonstrations deserves a plain explanation. Chrome’s declarativeNetRequest application programming interface lets extensions declare rules that block, redirect, or modify network requests. It is useful for content blockers because the browser can apply those rules without giving the extension the contents of every request (Chrome for Developers: declarativeNetRequest). The power is not malicious by itself.

The danger came from where those rules were allowed to operate. In the Chrome demonstration, the extension could modify responses inside a web page embedded by an internal browser feature. Forever Security said it removed protective response headers and redirected a JavaScript resource, causing attacker-controlled code to run where the agent expected vendor-controlled code. A normal web capability crossed into a privileged conversation.

Several later demonstrations used an even simpler pattern. A vendor created a web page for onboarding, marketing, testing, or prompting the AI side panel. That page received a trusted route to the agent. If another extension could run code on the page, alter its response, or simulate the interaction it expected, the extension could borrow the page’s authority.

This is why the attack family matters beyond browsers. Teams often protect the obvious production endpoint and forget the helper routes around it. A staging hostname remains accepted by an internal extension. A marketing demo can call a private browser interface. An onboarding button can pass a prompt into a side panel. None of those routes looks like the product’s central control plane, but each can carry control-plane messages.

The model does not repair that ambiguity. Natural language can make it worse because the message channel accepts goals rather than one rigid command. A conventional interface may expose openTab and takeScreenshot as separate operations. An agent interface may accept “collect the recent invoices and send them to this address,” then choose the operations needed to finish. Hijacking the instruction channel can therefore produce a chain of actions from a short prompt.

The correct conclusion is not that natural language is uniquely unsafe. A compromised automation API can also chain powerful calls. The difference is reviewability. A fixed API request reveals the operation and parameters. A goal given to an agent delegates some planning to the model, so the receiving boundary must be stricter about who may submit that goal and which tools may satisfy it.

“The extension was already installed” is a boundary, not a dismissal

Every BragJack path began after a malicious extension was present. That prerequisite cuts against the most breathless reading of the story. A random website could not simply take over a fully patched browser agent by displaying a sentence. The demonstrations did not show remote compromise of users who had installed nothing.

Yet an installed extension is not the same as a fully compromised computer. Browser architecture depends on keeping those categories separate. Users install extensions because the browser promises that declared permissions and internal barriers limit what each one can do. If “a malicious extension was installed” ended the analysis, extension isolation would have little purpose.

The useful question is what authority the user knowingly granted. A request blocker may need broad access to network requests across many sites. A writing tool may need to read and change page content. Neither description tells a reasonable user that the extension can send hidden instructions to a browser agent, read a local report through that agent, or operate an authenticated website as the user.

Permission combinations also age. A team may approve an extension in January, then enable an agentic browser feature in June. The extension’s manifest has not changed, so the extension review system sees no new request. The effective blast radius has changed because a new high-authority component now trusts a surface the extension can influence.

That creates a versioning problem for security decisions. An extension approval is usually treated as a statement about the extension alone: this ID, from this store, at this version, with these permissions. It should also be a statement about the environment in which the extension runs. New browser agents, side panels, enterprise integrations, password managers, and signed-in profiles can all change what the same permissions reach.

The reverse is true when evaluating the browser agent. A product may test that websites cannot directly command its tools. The test is incomplete if installed extensions can rewrite the trusted page, call a private interface exposed to a demo origin, or send messages to the built-in extension. The agent’s threat model must include every extension permission supported by the host browser.

This does not mean every extension deserves incident-response treatment today. The public reporting gave no evidence of BragJack exploitation, and the two public CVEs have fixes. A calm response begins with versions and inventory. It does not begin by wiping every browser or claiming that camera recordings occurred.

It also does not stop at updating. Chrome’s January fix and Edge’s July fix close the two recorded flaws on repaired builds. They do not prove that every remaining browser-agent channel is correctly isolated, and they do not tell a company which old extensions still have unnecessary reach. Patch the known defects, then use the story to inspect the permission system that made them consequential.

The developer workstation makes the consequence larger

A personal browser holds valuable sessions. A developer’s browser often sits beside a much wider set of authority: source control, cloud consoles, package registries, incident tools, internal dashboards, and local files containing architecture notes or exported data. The browser may be the front door to systems that deliberately resist command-line access.

An agentic browser can turn those signed-in pages into an action surface. That may be exactly why a team wants it. The agent can gather information across tabs, fill repetitive forms, or walk through a deployment console. Convenience comes from joining perception, planning, and action inside the session the user already trusts.

An extension that reaches the instruction path may not need to steal the session cookie. It can ask the agent to use the session. That distinction matters to defenders because a control focused only on token theft can miss actions performed through the legitimate browser process. The activity may look like the real user clicking the real interface from the real device.

The researchers’ public demonstrations were product-specific and did not establish compromise of development platforms. The workstation scenario is a consequence model, not a claim about observed attacks. Its purpose is to decide how much authority an agent should receive before the next boundary bug arrives.

Start with local files. A browser may open downloaded reports, configuration exports, design documents, or logs. A coding agent may also save patches, transcripts, and environment information near the project. If the browser agent can inspect local files, decide which directories it should ever see. “The user selected a file once” is a safer grant than broad, durable file access.

Then consider web sessions. Separate daily browsing from release and administration work when the consequence warrants it. A browser profile used for documentation and issue tracking does not need to remain signed in to a production cloud console. A profile used for sensitive administration does not need a long list of convenience extensions or experimental AI features.

The separation must be practical or people will route around it. A dedicated administrative profile with a short allowlist is often enough. High-risk actions such as publishing a package, changing identity policy, rotating secrets, or approving production should still require a separate control the browser agent cannot satisfy alone. Hardware-backed reauthentication, a second approver, or a service workflow can provide that boundary.

Network controls help, but they need the right target. Blocking an extension from one domain does little if the agent can reach the same destination through its own vendor service or browser process. Monitor what leaves the workstation and what sensitive services receive, while recognizing that encrypted vendor traffic may hide the prompt contents. Destination, volume, timing, and administrative audit events can still provide useful evidence.

A stronger design limits the agent’s tools at the receiving system. A cloud role used from the browser should not have more authority because an AI panel is present. Package publishing should use short-lived credentials and protected release steps. Repository administration should remain distinct from routine code review. If the browser becomes confused, downstream authorization still decides what the session may do.

The Secure Harness argues for exactly this arrangement around coding agents: let the system do useful work inside limits it cannot quietly expand. Browser agents deserve the same treatment. The extension boundary is one layer. Profile separation, short-lived authority, destination controls, and independent approval are the layers that keep one missed check from becoming the whole incident.

What to check now

The response should produce evidence, not a vague instruction to “be careful with extensions.” You need to know which browser build is running, which agents are enabled, which extensions can influence pages or requests, and which valuable sessions share that profile. That inventory can be small on one laptop and centrally managed across a fleet.

  1. Prove the browser versions that are actually running. Chrome users should be beyond 143.0.7499.192, the version Google identifies for CVE-2026-0628. Edge users should be beyond 150.0.4078.48, the affected-version boundary in Microsoft’s CVE record. Open the browser’s version page after updating and restarting. A downloaded update is not the same as a repaired process.

  2. List enabled extensions by profile. Record the extension ID, source, owner, business purpose, installation method, update channel, requested permissions, and last review date. Include extensions installed by policy and those added by the user. An allowlisted extension can still become unnecessary or change ownership.

  3. Mark extensions that can change many pages or network requests. Host access across all websites, content-script access on broad patterns, debugging authority, and request-modification permissions deserve closer review. Those permissions do not prove danger by themselves; they expose the routes most likely to interact with a trusted agent page or browser interface.

  4. List browser-side AI features and their reach. Note whether each feature can only summarize the active page or can also open tabs, fill forms, use local files, take screenshots, access media devices, or act across signed-in services. Product names are not enough because capability changes by version, account, preview flag, and administrator policy.

  5. Map the combinations. Put the broad extensions and capable agents in the same table. Add the signed-in services and local data present in that browser profile. A request blocker in a low-value browsing profile deserves a different response from the same extension beside a browser agent and a production console.

  6. Remove what has no current owner. Disable extensions installed for a finished trial, old conference tool, retired vendor, or one-time debugging task. Fewer extensions shrink both direct extension risk and the number of components that can collide with future browser features.

  7. Separate sensitive sessions. Move cloud administration, release publishing, finance, and identity management into a browser profile with a short extension list and conservative AI settings. Do not synchronize that profile’s extension set from a convenience-heavy personal profile.

  8. Test the policy from the managed endpoint. A console showing an allowlist is an intended state. On a representative device, try to install an unapproved extension, inspect the active browser policy, and confirm that existing exceptions match the approved list. Google documents a “block all, allow selected” model for managed Chrome deployments (Google Chrome Enterprise Help: allow or block apps and extensions). Microsoft documents the equivalent blocklist-plus-allowlist approach for Edge, where blocking * leaves only named extensions installable (Microsoft Learn: Edge ExtensionInstallAllowlist).

  9. Keep high-impact actions outside the agent’s sole control. A browser agent may prepare a release, but a separate identity should approve publishing. It may draft an access change, but another channel should confirm it. Design the last gate so that a hidden prompt inside the browser cannot complete the whole operation.

  10. Write a short receipt. Record the measured browser versions, enabled agent features, extension list, profile separation, exceptions, test results, and next review date. Store it outside the browser profile. The receipt makes the next feature launch or vulnerability disclosure a comparison instead of a fresh investigation.

Home users can use a shorter version. Update and relaunch the browser, open the extensions page, remove anything unfamiliar or unused, and keep experimental browser agents away from the profile used for banking or other sensitive accounts. Do not install a “BragJack cleaner.” The known repairs arrive through normal browser updates, and an extra extension would add another party to the same trust problem.

Developers should resist one tempting shortcut: checking only whether an extension came from an official store. Store review helps, but it cannot prove that every future update remains benign or that an old permission will never compose badly with a new browser feature. Approval needs an owner, a reason, and a review trigger when the environment changes.

Design the agent channel as a security boundary

Vendors can repair this class more durably by treating the instruction path as a security boundary of its own. The agent’s trusted caller should be identified by more than a web origin that another extension can modify. The browser needs an authenticated, narrow channel between the user-facing surface and the component that owns the tools.

Web content should not gain browser-level authority simply because it appears inside a privileged wrapper. If a browser embeds a vendor page, extension request rules, content scripts, debugging interfaces, and navigation behavior must be denied or mediated at that boundary. The Chrome CVE demonstrates why each extension subsystem must be checked, rather than assuming one internal URL protects every nested context.

Marketing and onboarding pages should not carry production command authority. A demo button can place harmless text into a local field without receiving a general bridge into the agent. If a web origin must submit a task, bind the capability to one action, one context, one user gesture, and a short lifetime. Do not expose a broad “send any prompt” interface because the initial examples are benign.

Agent tools need their own authorization. A prompt arriving through an approved surface should not automatically inherit every capability the agent has ever been granted. Reading the active tab, opening a local file, accessing a camera, and clicking a final purchase button are different decisions. Tool grants should be narrow, visible, and revocable.

Confirmation must describe the consequence. “Allow this AI task?” is weak if the task can choose among dozens of tools after approval. A useful prompt says which file will be read, which site will receive data, or which irreversible action will occur. The confirmation surface must also be outside the content the agent or extension can edit.

The system should preserve provenance. Every consequential tool call needs a record of the initiating surface, browser profile, extension or built-in component, user gesture, prompt, selected tool, destination, and result. Sensitive content may need redaction, but removing provenance entirely leaves responders unable to distinguish a user request from a forged one.

Extensions need composition testing. A browser team may test an agent against hostile websites and still miss hostile extensions. The test matrix should include broad host access, request redirection, response-header changes, debugger access, synthetic input, embedded frames, built-in extensions, staging origins, and every page allowed to call the agent. Run the same tests when a new agent tool is added because the consequence changes even if the message bridge does not.

Rollout controls matter too. Agent features should be separately switchable by profile and policy. Administrators need a way to disable action tools while retaining summaries, to block local-file access, and to keep preview features out of administrative profiles. One global “AI on” switch makes measured adoption harder.

Finally, product security claims need exact scope. “Extensions cannot access the internal page” is weaker than “request rules, content scripts, debugging, frames, redirects, and messages cannot influence the authenticated agent channel.” Precise statements become test cases. Broad assurances become assumptions.

The permission review has to include the neighbour

BragJack did not show an AI model deciding to rebel. It showed software components trusting the wrong route. The extension supplied influence, a web surface supplied legitimacy, and the browser agent supplied authority. Each part looked different when reviewed alone.

That is the durable lesson. Security reviews often draw a box around one product and ask what it can do. Composed systems fail across the lines between boxes. The browser extension beside the agent, the marketing page beside the private interface, and the test hostname beside the trusted origin belong in the same model.

For users, the immediate work is modest: update, relaunch, remove unused extensions, and separate sensitive sessions. For teams, add a combined extension-and-agent inventory, enforce an allowlist where the risk warrants it, and preserve a receipt from the endpoint. Keep the final approval for high-impact work outside the browser agent’s reach.

For vendors, the hard requirement is simple to state and demanding to implement. A component should not gain authority merely because it can speak in natural language through a page the agent recognizes. Authenticate the caller, bind every tool grant, and record the path from user action to consequence.

An extension permission has meaning only in the environment where it runs. Add a capable neighbour, and the old review may no longer describe the real system. Review the pair.

If you want practical security writing without a daily alarm bell, the newsletter is one email per month. The signup lives on this site.

Sources