Chrome Prompt API exposes browser agents to indirect prompt injection

At a glance

What this is: This is an analysis of Chrome’s on-device Prompt API and how indirect prompt injection can turn browser AI agents into tools for cross-tab fraud and exfiltration.

Why it matters: It matters because identity and access assumptions break down when browser agents can act inside authenticated sessions without reliable user intent, auditability, or a meaningful privilege boundary.

By the numbers:

• 17 minutes.

👉 Read Mint's analysis of Chrome Prompt API prompt-injection risks

Context

Chrome’s Prompt API turns the browser into an execution environment for local AI, which means page content, extension logic, and authenticated user actions can be blended into the same trust domain. That creates a governance gap for browser AI agents because the model cannot reliably separate instructions from attacker-supplied content, and the organisation cannot depend on a conventional server-side audit trail to reconstruct what happened.

The identity angle is direct: once an agent can read tabs, fill forms, click buttons, or send requests inside a logged-in browser session, it behaves like a non-human identity with delegated access but without the lifecycle controls IAM teams expect. This is no longer a theoretical edge case; it is the kind of operational pattern that appears whenever AI agents are granted broad browser privileges without explicit scoping.

Key questions

Q: What breaks when browser AI agents can act on untrusted page content?

A: The separation between reading data and executing actions breaks first. If a model can see attacker-controlled text and then call tools inside an authenticated session, the prompt becomes a command channel. That creates prompt-to-action collapse, where comments, emails, or ticket text can trigger form fills, transfers, or exfiltration without a real user decision.

Q: Why do local AI agents complicate identity and access management?

A: They can retain legitimate permissions while changing timing, prioritisation, and action sequence outside human presence. That means the visible identity may remain stable even as the operational behaviour becomes autonomous. IAM teams then lose the simple link between user session, authorisation, and accountability.

Q: How do security teams know if an agentic browser is operating outside its intended boundary?

A: Look for unexpected page traversals, unapproved form submissions, unusual data movement, and actions taken outside the user’s normal workflow. If the browser is acting across systems without a clear approval trail, the intended boundary has been crossed. The signal is behavioural drift, not just malware detection.

Q: Who should be accountable when a browser agent exposes files or credentials?

A: Accountability should sit with the team that governs the delegated session, the identity permissions behind it, and the systems that allowed secret exposure or recovery changes. If an organisation lets an agent act inside a human session, then access review, PAM, and browser governance all share responsibility for the resulting blast radius.

Technical breakdown

How indirect prompt injection works in browser AI

Indirect prompt injection happens when attacker-controlled text becomes part of the prompt an AI system consumes. In a browser, that text can come from comments, posts, emails, tickets, or any field the agent reads while acting on behalf of a user. The model does not have a reliable way to distinguish developer instructions from hostile page content, especially when the page text is concatenated with system prompts and tool instructions. That ambiguity matters more on-device because the browser session itself is the execution context, not a remote API boundary.

Practical implication: treat any content the agent reads as potentially executable input and constrain which pages can reach the model.

Why tool catalogs matter more than model quality

A browser agent is only as safe as the tools it can call. Generic primitives such as read, click, fill, and fetch can be composed into high-impact actions even when the model has no explicit money-transfer or exfiltration tool. Smaller on-device models may be less capable at reasoning, but they still follow malicious instruction chains if the tool surface is broad enough. In other words, the risk is architectural: a flexible tool catalog creates a control plane that hostile content can steer.

Practical implication: minimize generic tools, scope them per origin, and separate read-only assistance from state-changing actions.

Why on-device inference does not remove the security problem

On-device inference changes the privacy path, not the abuse path. If the model runs locally, prompts may never leave the machine, but the agent can still post attacker-chosen data through browser forms or HTTP requests. That means privacy assurances do not equal security isolation. The absence of provider-side logs also makes detection harder, because there is no central record of the prompt, the model output, or the resulting tool calls unless the enterprise instrumented them locally.

Practical implication: add local telemetry, action logging, and policy enforcement around browser AI use instead of assuming on-device processing is inherently safer.

Threat narrative

Attacker objective: The attacker wants to use browser AI as a proxy for fraud or reconnaissance inside the victim’s authenticated session.

1. Entry occurs when a user loads attacker-influenced content such as a comment thread, email, or page that the browser agent reads as part of normal assistance.
2. Escalation happens when the malicious text is folded into the agent prompt and the model selects generic tools such as read, fill, click, or fetch inside an authenticated browser session.
3. Impact follows when the agent transfers funds, exfiltrates tab data, or performs other state-changing actions that the user did not intend.

NHI Mgmt Group analysis

Browser AI agents are becoming a new identity boundary, not just a UX layer. Once a model can act inside an authenticated browser session, it inherits the user’s trust and access context without inheriting the controls that normally govern delegated access. That makes the browser agent behave like a non-human identity with broad runtime authority. The governance question is therefore not whether the model is helpful, but how its privileges are constrained across pages, tabs, and actions.

Tool surface design is the real control plane for browser-agent risk. The article shows that generic primitives create a composable attack surface even when the model is small and the user never leaves the page. This is a classic least-privilege failure, but with AI in the loop the failure mode is more subtle because attacker text can drive tool selection. The named concept here is prompt-to-action collapse: the moment untrusted content can directly shape a state-changing tool call, the intended separation between reading and acting disappears.

On-device AI shifts where the evidence lives, not whether abuse is possible. Security teams often treat local inference as a control, but local execution only removes cloud egress from the model provider. It does not stop the agent from reading sensitive pages, issuing requests, or altering account state. That means browser AI governance must be measured against actual action boundaries, not model hosting location. For practitioners, this is a lifecycle problem for AI-enabled access, not a model-quality problem.

Existing IAM assumptions break when the same session can both observe and act. Traditional access review assumes a human or service account has a relatively stable entitlement set that can be reviewed after the fact. Browser agents compress observation, decision, and execution into one runtime loop, which makes after-the-fact review too late to prevent abuse. The practical consequence is that identity teams need policy controls for browser-assisted delegation, not just identity governance after the fact.

NHI governance now has to extend into the browser. The browser is no longer just an endpoint application when it hosts an AI that can perform authenticated actions on behalf of a user. That changes the boundary for non-human identity oversight because the agent’s authority is derived from the user session but exercised autonomously at runtime. Teams that already govern service accounts, tokens, and workload identity should apply the same scrutiny to browser AI agents before they become an unmanaged class of privileged automation.

What this signals

Prompt-to-action collapse is the operational risk teams should now track for browser AI. Once untrusted content can steer a model into a state-changing tool call, the control problem shifts from model accuracy to privilege containment, which is why the relevant references are OWASP Agentic AI Top 10 and MITRE ATLAS adversarial AI threat matrix.

For identity programmes, the practical signal is whether browser AI is being managed like a delegated non-human identity or left as unmanaged convenience software. If the enterprise cannot say which origins can invoke the model, which tools are exposed, and which actions require approval, then the programme has already accepted an uncontrolled automation layer.

The next governance step is to align browser-agent policy with existing NHI and PAM controls rather than invent a separate exception process. The organisation that already understands privilege scope, lifecycle ownership, and auditability has the right vocabulary for this problem, and the programme that ignores it will discover browser AI only after an unintended action has already happened.

For practitioners

• Scope browser AI to read-only use cases first Restrict browser agents to summarization, classification, or extraction tasks that cannot change state in authenticated applications. Avoid exposing generic click or fill primitives to pages that can ingest third-party content, and require explicit approval for any action that submits forms, moves money, or modifies account records.
• Apply per-origin and per-tab privilege boundaries Do not let every page reach the same model and tool set. Tie tool availability to trusted origins, limit cross-origin iframe access, and block sensitive tabs such as banking, admin portals, and cloud consoles from being read by browser AI unless there is a documented business need.
• Log model actions locally and centrally Capture prompt inputs, model outputs, and tool invocations on endpoints where browser AI is enabled so investigators can reconstruct what the agent saw and did. Without local telemetry, there is no reliable evidence trail when a prompt injection causes a transfer, exfiltration, or other unintended action.
• Default-deny browser AI in managed environments Use enterprise policy to disable the Prompt API and similar features until a specific application has been risk assessed. If a business unit wants browser AI, require a control review for allowed origins, supported tools, user consent, and containment around high-value sessions.
• Treat state-changing browser actions as privileged workflows Any transfer, payment, account change, or data export initiated by an agent should require a separate control path from normal browsing. That can mean human approval, step-up authentication, or a dedicated workflow that the browser model cannot improvise from page content alone.

Key takeaways

• Browser AI agents collapse the boundary between reading content and acting on it, which makes indirect prompt injection an access-control problem as much as an AI problem.
• The browser’s tool catalog, not model quality, determines how far a malicious prompt can travel inside an authenticated session.
• Identity teams should govern browser AI like privileged non-human automation, with tight scoping, logging, and explicit approval for any state-changing action.

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.
• Prompt-to-Action Collapse: A failure mode in which untrusted content can directly influence a model to perform a state-changing action through available tools. It matters because the model is no longer just summarising or classifying data, it is driving execution inside an authenticated session with the user’s authority.
• 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.
• State-Changing Action: An action that alters an account, system, or record rather than simply observing it. Examples include submitting a transfer, exporting data, changing settings, or approving an item. These actions require stronger controls because they can cause direct business impact if steered by hostile content.

What's in the full report

Mint's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step browser-agent architecture and tool-call sequence for the single-shot and ReAct models.
• The exact malicious comment flow used to trigger cross-tab banking actions and tab harvesting.
• Screenshots and video evidence showing the transfer modal and exfiltrated tab payloads.
• Chrome Prompt API and Chrome 148 release references used to ground the technical findings.

👉 Mint's full post covers the attack scenarios, tool-chain details, and defensive boundaries in depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management for practitioners building stronger access controls. It helps security teams translate identity governance into practical policy for automation, delegated access, and emerging AI-driven workflows.