Google Chrome Prompt Injection: Copy Google’s 5 Layers (Your Agents Can Add a 6th)

Chrome’s agentic mode ships with the most complete public architecture for securing one class of agent, and the post that describes it names the residual in the same breath.

Gemini in Chrome browses, clicks and fills forms on a user’s behalf inside logged-in sessions, and Google’s design document states that the planning model is inherently vulnerable to indirect prompt injection because it reads page content. Five layers wrap that planner. Read as a reference design, each has a counterpart in the agents a platform team runs on Kubernetes, and the mapping is worth doing carefully, because Google built two of the layers deterministically and most agent stacks have built none that way.

One layer is missing from the design, and it is missing for a structural reason that does not apply to your agents.

Chrome Treats Prompt Injection as a Site Isolation Problem

The most deterministic control in Chrome’s design is a fifteen-year-old browser primitive applied to an agent.

Site isolation and the same-origin policy already keep one site’s code from reading another site’s data. Google’s post extends the idea to the agent with Agent Origin Sets: for each task, a gating function decides which origins are relevant and sorts them into read-only origins, which the model may consume, and read-writable origins, which the agent may also type into and click on. An iframe outside the readable set is never sent to the model, and data from the readable set can only flow to the writable set. The gating function never sees untrusted page content, so a page cannot talk its way into the set. Model-generated URLs are checked deterministically against known public destinations, because a URL is the classic exfiltration channel.

That instinct is right, and it bounds the thing that matters most for a browser agent: cross-origin leakage from a logged-in session to an attacker’s origin. If the bank is outside the task’s origin set and the page’s server is outside the writable set, an injected page cannot route the one to the other.

Google also states the limit. The post says the team implemented a simpler version first, tracking only the read-writable set, and will tune the gating functions as it learns how real tasks interact with the guardrails. So the deterministic layer is live in a reduced form, and its final shape is a design decision still being made.

A Second Model Judges Every Action From Metadata Alone

The User Alignment Critic is a separate model that sees only a description of what the planner wants to do, never the page that persuaded the planner to want it.

After the planner proposes an action, the critic receives metadata about it and asks one question: does this serve the user’s stated goal? Yes, and the action proceeds. No, and the critic vetoes it, the planner replans, and after repeated failures control returns to the user. Google describes the critic as architected to see no unfiltered untrustworthy web content, which is what makes it a high-trust component: a page cannot poison a model that never reads pages. The lineage is explicit in the post, which credits the dual-LLM pattern and CaMeL, Google DeepMind’s work on separating a privileged planner from a quarantined reader.

The blindness is the guarantee, and it is also the limit. A critic that sees no page content cannot be manipulated by page content. It also cannot see that the action it is approving was suggested by page content, because from where it sits the action arrived from the planner like every other action. It judges whether the step fits the goal. It does not judge where the step came from.

Underneath the critic sit the model-level protections Google already ships: spotlighting so the planner prefers user and system instructions over page text, and training on known attacks. The pattern family the critic belongs to fixes which action fires and leaves the arguments to the planner, and where a control sits relative to the model’s decision decides what it can catch. The critic sits after the decision, with less context than the decision had. That is the right side and the cost, in one design choice.

Confirmations, a Classifier, and Red Teaming Close the Five

The remaining three layers put the user in the loop, scan the page, and attack the system on a schedule.

Confirmations are partly deterministic and partly model-based. Before a site in a sensitive category such as banking or medical, the agent asks. Before signing in through the password manager, it asks, and the model never sees stored passwords. Before a purchase, a payment, a sent message or another consequential action, it pauses for permission or hands the final step to the user. Google notes it is still improving accuracy on edge cases, which is what a list plus a model looks like.

The classifier is the layer that reads the page. It runs in parallel with the planner’s inference and blocks actions based on content it determines has intentionally targeted the model. Google’s sentence about it is the one every summary skipped: while it cannot flag everything that might influence the model with malicious intent, it is a valuable layer in defense in depth. That is a vendor describing a rate, and it matches what the same layer does and does not cover on a cloud provider’s agent platform: the payloads that announce themselves get caught, and the ones phrased as ordinary text do not.

Red teaming is continuous. Automated systems generate sandboxed malicious sites, seeded by researchers and expanded by models, weighted toward broad-reach vectors such as user-generated content and ads and toward high-harm outcomes such as transactions and credential leaks. Attack success rate feeds engineering, auto-update ships the fixes, and the rewards program pays up to twenty thousand dollars for breaches of the security boundaries the Chromium project defines for AI features.

Five layers. Two deterministic, one dual-model check, one classifier, one process. Google stated a limit on three of them.

The Residual Google Names Is the Ask That Fits the Task

Put the three stated limits together and they leave the same hole every published agent design leaves: an injected instruction phrased as a step of the task the user asked for.

Judging alignment to the stated goal is the right first design. Most injections in the wild are goal hijacks: the page wants the agent to abandon the shopping task and do something else, and a critic asking whether a step serves the shopping task vetoes that on sight. The common case is caught by a component that cannot itself be attacked.

The residual is the ask that does not hijack the goal. A page in the readable set contains a line, written as ordinary site copy, saying that to complete checkout the visitor should also confirm their account by entering details on this page. The planner proposes typing into a form on an origin in the writable set. The critic sees a form fill on a task-relevant site during a checkout task, which is aligned. The classifier sees a sentence with no override vocabulary and no encoding. The confirmation layer fires only if the action is on its sensitive list. Every layer did its job, and the step completed, because the step was shaped like the task.

Perplexity’s browser documented the same structure from the incident side: four action classes were gated, and every recorded exfiltration completed through actions that were not on the list. A gate is a list, and the list is also a list of everything ungated. The technique that produces this outcome performs no evasion at all, and it has a name: coercion, where every step the agent takes is authorized and the sequence is the attack.

Five layers with two deterministic ones is more than most agent stacks in production can claim, and the origin-set primitive is one most of them should copy. The residual is the shape of the problem, and Google’s post says as much when it calls agent security an emerging domain.

Here is what changes for your agents. A browser agent starts every task with no past. It has a goal, a set of origins and a critic, and when the task ends the agent is gone. An agent you run on Kubernetes has been doing the same job for weeks, and the record of that job exists. The residual Chrome cannot close is the one that record was built for.

Map the Five Layers to the Agents You Run, Then Add the Sixth

Each Chrome layer has a counterpart in a server-side agent stack, and most of the counterparts are things a platform team already owns.

Chrome layer	What it does in Chrome	Counterpart for an agent on Kubernetes	What carries over, and what does not
Agent Origin Sets	Limits reads and writes to task-relevant origins; deterministic	Tool scope plus credential scope plus egress network policy	Carries over fully; it is the same primitive. Most agent stacks have not made it per task.
User Alignment Critic	Second model approves actions from metadata; isolated from content	A policy evaluated on each tool call, in Audit before Enforce	Carries over as a policy check. A model-based critic is optional; a deterministic policy on the call is stronger where the policy can be written.
User confirmations	Pauses before sensitive sites and consequential actions	Gated actions: human or second-system approval on enumerated rows	Carries over as the gated half of the consequence ledger, with the same limit: ungated rows complete on the model’s say-so.
Prompt injection classifier	Scans page content in parallel; blocks targeted content	Prompt-layer signal in the gateway or guardrail	Carries over as one signal category with a rate, never as detection on its own.
Automated red teaming and VRP	Generates attack sites; pays for breaches	One plain-request test per ungated consequence, rerun on capability change	Carries over as the ledger; the denominator is your consequence list rather than a payload library.

The sixth layer has no row on the left because a browser agent cannot have it.

Your agent has a self. Over weeks of real traffic it has called specific tools with specific argument shapes, exercised one identity against specific resources, and opened connections to a known set of destinations. ARMO records that from the kernel with an eBPF sensor and builds it into a per-agent behavioral profile, Application Profile DNA (APD™), so the residual step above, a form fill or a lookup that fits the task, meets a different question from the critic’s: has this agent done this before? A task-shaped ask the agent has never performed is a deviation, whatever the critic would have said about its alignment. That is coercion observed from below, and only an agent that persists can be observed that way.

Arming it follows the same discipline Google describes for its own layers, applied per agent: observe first in Audit, review what a policy would have blocked against real traffic, then Enforce, so that a wrong boundary is found in the record rather than in production. Credential isolation adds a bound the origin set does not: when the agent holds placeholder credentials and the real ones are substituted outside its reach, a coerced step that needs the key completes with a key that opens nothing.

ARMO’s runtime security for AI workloads is the sixth row. Bring one production agent and its tool registry to a working session and the five Chrome layers get mapped against what that agent actually has, with the sixth filled from its runtime record.

Enterprise Custody: What Chrome Gives an Admin and What Reaches Your Servers

For the CISO, the Chrome question is custody: which of these controls does the enterprise hold.

Google’s Chrome Enterprise team answered part of it in an August 2026 post. Chrome Enterprise Premium applies data loss prevention to agent flows, extends context-aware access from the employee to the agent so the agent cannot reach or export what the employee could not, and tags agent-navigated pages in Chrome history. Those controls sit with the admin. The five defense layers sit with Google.

What reaches your servers is unchanged by any of it. When an auto browse task operates inside your CRM, your ticketing system or an internal portal, your application receives a session carrying the employee’s identity, and in origin-set terms your application is a read-writable origin. The agent’s clicks arrive as the employee’s clicks. Google’s design bounds what the agent can carry between origins and leaves untouched what your application does with a valid session. That is the sixth layer’s question, asked of a different identity: what did it do, and is that what it does.

A Browser Agent Is a Reference Design for Yours

Two deterministic layers, one dual-model check, one classifier, one process, and a gap where the agent’s history would go.

Copy the origin sets first; they are tool scope and egress policy under another name, and the cheapest property you can buy. Treat the critic as a policy on the call. Keep the classifier as a signal. Turn the red team into a ledger. Then add the layer Chrome’s agent cannot have, because yours has run long enough to have a past.

The examples on the public record run from a translation bot to agents that forward instructions to each other, and a browser agent with five layers is the most defended entry on that list. The gap it leaves is the one your runtime record was built to close.

FAQ

Does Gemini in Chrome protect against prompt injection? Google ships five layers for agentic browsing: origin sets, the User Alignment Critic, user confirmations, a page classifier and continuous red teaming. Its design post also states that the planner is inherently exposed because it reads page content, that the classifier cannot flag everything, and that the first origin-gating release is reduced. Protection is real and bounded, and the bound is an injected step that fits the user’s task.

Can Chrome’s auto browse be prompt injected? Google treats it as an open problem and pays up to twenty thousand dollars for demonstrated breaches of the agentic security boundaries, which answers the question in principle. The layers make a successful injection expensive and bound what it can reach across origins. An instruction that stays inside the task’s origin set and reads as a step of the task is the case the published design does not structurally exclude.

What is the User Alignment Critic? A second model built with Gemini that runs after the planner proposes each action and decides whether the action serves the user’s stated goal. It receives metadata about the action and never sees unfiltered page content, so a malicious page cannot poison it. It vetoes misaligned actions and sends feedback to the planner; after repeated failures the planner returns control to the user. Google credits the dual-LLM pattern and CaMeL as its inspiration.

Can enterprises control Chrome’s agentic features? Google’s Chrome Enterprise posts describe controls that sit with the admin: data loss prevention applied to agent data flows in Chrome Enterprise Premium, context-aware access policies that the agent inherits from the employee, extension visibility, and agent-tagged entries in browsing history. The five defense layers themselves are Google’s. What your internal applications receive from an auto browse session is a request carrying the employee’s identity, and your own controls decide what that identity can do.

How is securing my own agents different from Chrome’s approach? Every Chrome layer has a counterpart: origin sets map to tool, credential and egress scope; the critic to a policy on each tool call; confirmations to gated actions; the classifier to a prompt-layer signal; red teaming to a test per reachable consequence. The difference is that your agents persist and so have a history, and deviation from that history is a control a fresh-per-task browser agent cannot have. Build the five, then add the sixth.