Chrome Prompt API exposes browser agents to indirect prompt injection

At a glance

What this is: Mint shows that Chrome’s on-device Prompt API lets hostile page content drive browser agents into cross-tab financial fraud and data exfiltration.

Why it matters: This matters because browser AI agents inherit the user’s authenticated session, so identity and access controls must move from model output review to tool scoping and action gating.

Context

Chrome’s Prompt API turns browser AI into a first-class execution surface, which means page content, extension code, and user actions can all meet inside one authenticated session. The governance problem is not prompt quality alone, but the lack of a clean boundary between untrusted content and privileged browser actions.

Indirect prompt injection is the core failure mode here. Once a browser agent can read arbitrary page text and call tools inside the same session, it becomes vulnerable to hostile instructions embedded anywhere users consume content, from comments to emails to internal tickets. That makes the control problem a mix of content trust, tool permissioning, and identity-bound action limits.

The identity angle is genuine: the agent is acting as the user, inside the user’s browser, with access to tabs that may contain banking, cloud, or corporate sessions. That is a non-human identity problem as much as a browser security problem, because the delegated actor has no native accountability boundary of its own.

Key questions

Q: What breaks when browser-capable agents can browse and send messages in the same session?

A: The main failure is action boundary collapse. A malicious page can influence what the agent reads, what it writes locally, and what it sends externally. Once those privileges share one context, a prompt injection can become a durable artifact, a false status message, or both. The fix is to separate tool permissions and require explicit approval for outbound actions.

Q: Why do browser AI agents create identity and access risk even when the model runs locally?

A: Because local inference only changes where computation happens, not what the agent can reach. If the browser session already contains authenticated tabs, the agent can still act as the user across banking, cloud, or enterprise applications. The risk sits in delegated access, not in cloud model hosting.

Q: What are the signs that a browser agent is too permissive?

A: If a single prompt can trigger cross-tab reads, silent data export, or state-changing actions without a separate approval step, the agent is over-permissive. Another warning sign is a broad tool catalog that combines reading, clicking, form filling, and outbound requests in one execution loop.

Q: Should organisations treat browser agents as shadow AI or as managed identity assets?

A: They should treat them as both, but manage them as identity-bearing automation first. A browser agent that can act inside authenticated sessions needs ownership, scope limits, and revocation just like any other privileged non-human actor. That is the only way to make the control boundary visible.

Technical breakdown

How prompt injection reaches browser tools

Prompt injection works when untrusted text is mixed into the same prompt that carries developer instructions and user intent. In a browser agent, page content, comments, emails, or scraped tab text can be passed into the model as plain input, but the model cannot reliably distinguish instructions from data. If the agent also has tools such as click, fill, or fetch, the injected text can steer those tools into state-changing actions. The weakness is architectural: the browser becomes both the data source and the execution environment, so the trust boundary collapses unless the developer separates reading from acting.

Practical implication: Treat page content as hostile input and gate any state-changing tool behind explicit policy, not model judgement.

Why on-device models do not remove the risk

Running the model locally changes where the data goes, not what the model is allowed to do. On-device inference removes the vendor cloud hop, but it does not stop the agent from using the user’s authenticated browser session to reach banking tabs, cloud consoles, or internal apps. That is why privacy and security are different questions here. The model may never leave the machine, while the consequences of its tool calls still do. In practice, the attack surface shifts from provider logging to local tool exposure, cross-tab visibility, and the permissions granted to the extension or browser feature.

Practical implication: Do not treat local inference as a security control; restrict the agent’s tools, scopes, and reachable origins instead.

Why browser agent architecture matters more than model size

A single-shot agent can be dangerous, but a ReAct-style agent is usually worse because it can iterate, observe, and adapt after each tool call. Each observation expands what the model knows about the environment and gives it another chance to act on malicious instructions hidden in the page. That matters for browser AI because many shipping implementations resemble iterative agents, not isolated classifiers. Smaller models may be easier to confuse, but larger models only increase the agent’s ability to complete multi-step abuse. The decisive variable is not intelligence alone, but whether the architecture permits untrusted content to influence tool execution inside an authenticated session.

Practical implication: Assess the full agent loop, not just the model, and assume iterative observation increases abuse potential.

Threat narrative

Attacker objective: The attacker wants the browser agent to execute privileged actions and exfiltrate sensitive session data while the user remains unaware.

1. Entry occurs when the victim opens a normal-looking page containing a hidden prompt-injection payload in a comment or similar free-form field.
2. The browser agent ingests that content alongside legitimate page text and follows attacker instructions because it cannot reliably separate data from commands.
3. The agent uses its tools inside the victim’s authenticated browser session to either submit a bank transfer or scrape other open tabs and send the results to an attacker server.
4. Impact is cross-tab fraud or broad data exfiltration without compromising the browser vendor, the target bank, or the underlying model.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool catalogs are now the real trust boundary: browser AI fails when developers treat model output as the control point instead of the callable actions. Once an agent can click, fill, or fetch inside an authenticated browser session, hostile page content can redirect those tools regardless of how local the model is. The practical conclusion is that browser agents need permission design, not just prompt tuning.

Prompt injection in browsers is an identity governance problem, not only an AI problem: the agent is operating as a delegated non-human actor with the user’s session context. That collapses the distinction between human intent and machine execution unless action scope, origin scope, and approval rules are enforced at the identity layer. Practitioners should treat browser AI as an identity-bearing execution plane.

Local models create a false sense of safety: on-device processing removes cloud exposure, but it does not remove abuse of authenticated state. The security question changes from where the text is processed to what the agent can reach once the text is processed. Browser security teams should therefore align controls to the reachable actions, not the model host.

Chrome’s Prompt API exposes browser agents to indirect prompt injection as a repeatable governance gap: the same pattern will recur anywhere user-generated content and state-changing tools share one execution context. This is the named concept worth tracking because it captures the boundary failure more precisely than generic “AI risk.” Practitioners need to map this gap to browser policy, not wait for a CVE.

Enterprise controls should assume browser AI can act like shadow automation: if a browser extension can read tabs and issue tool calls, it has effectively become an unmanaged agent. That puts discovery, approval, and revocation on the same footing as any other privileged non-human identity. Security teams should inventory browser agents before they inventory prompts.

What this signals

Browser agents shift the control problem from prompt content to delegated action. Once a page, extension, or comment can influence a tool call inside the user’s authenticated browser session, conventional content filtering is no longer enough; the browser needs identity-aware action controls and explicit scoping at the tool layer.

Browser agent trust gap: the critical failure is the absence of a clean separation between untrusted page content and privileged browser actions. Teams should treat any AI feature that can read tabs and perform actions as managed automation, then decide whether it belongs inside the approved browser estate at all.

For practitioners

• Restrict browser agent tool scope Allow only the minimum callable actions needed for each use case, and separate read-only primitives from state-changing actions such as click, fill, or fetch.
• Gate privileged actions on human approval Require explicit user confirmation before any agent can submit a form, move money, or send data outside the browser session.
• Apply origin and tab scoping Constrain which origins the agent can read or control so page text from one tab cannot drive actions in another authenticated context.
• Inventory browser agents as non-human identities Track which browsers, extensions, and built-in AI features can execute actions on behalf of users, then assign ownership and revocation paths.

Key takeaways

• Browser AI becomes dangerous when untrusted content and privileged tools share the same execution context, because prompt injection can redirect legitimate automation into fraud or exfiltration.
• The article shows that the attack works without a CVE, a malicious extension, or a bank compromise, which means the real weakness is governance of the tool boundary.
• Practitioners should control browser agents the way they control other privileged non-human actors, with explicit scoping, approval for sensitive actions, and ownership for revocation.

Key terms

• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Browser Agent: A browser agent is software that can navigate websites and complete browser-based tasks on behalf of a person or system. In identity terms, it is an execution identity that may inherit access, session state, and trust boundaries that were previously assumed to belong only to humans.
• Tool Catalogue: A tool catalogue is the list of actions, connectors, or capabilities an AI client can discover through an MCP server. When exposed without authentication, it can reveal internal structure, system names, and possible targets, giving attackers reconnaissance value before any direct compromise occurs.
• Authenticated Browser Session: A browser state where the user is already signed into one or more services and the browser can act with those credentials. For agents, this session context is powerful and dangerous because it can turn a simple prompt injection into access to banking, cloud, or corporate systems.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for teams that need to govern delegated access, browser agents, and other non-human actors across modern identity programmes.