The whole design, in writing
Every step of the build above, written out: the problem each piece solves, the option that was taken and the ones that were not, the numbers, and how it fails in production.
The big idea
A perimeter for a fleet, not a leash on one agent
An agentic browser can read a page, fill a form, click "send," move money. That's useful — and it's a data-exfiltration and unauthorized-action risk running on thousands of employee machines at once. The standard advice is "block them," but people run them anyway, so a blanket ban just creates shadow usage you can't see. How does an enterprise contain a whole fleet of agentic browsers?
We'll build the fleet perimeter: one gateway every agentic action flows through, a central policy engine, taint tracking so untrusted web content can't silently drive a sensitive action, an action allowlist with risk classification, human-approval breakpoints for irreversible actions, and full fleet audit. This is the org-level containment layer — not the per-agent injection defense a single computer-use agent already ships.
What the new pieces do
- Agentic Browser Fleetclient
- The employees running agentic browsers that click, type, and act on the web and internal apps on their behalf. Blocking them outright doesn't work — people run them anyway — so the goal is to contain the whole fleet, not ban it.
Step 1 · The baseline
Agentic browsers act on the web, ungoverned
The reality on the ground: employees install agentic browsers that read pages and take actions directly, each configured (or not) by whoever set it up. IT's official stance is "don't," but a meaningful fraction run one anyway. What's the actual enterprise risk?
Thousands of employees run agentic browsers that act on the web and internal apps, with no central control. What's the core risk?
Distributing responsibility to thousands of individuals is exactly how a company loses control of its data. One agent that reads a malicious page and obeys it can exfiltrate customer data or take a destructive action — and with no central perimeter, nobody sees it happen or can stop the pattern across the fleet.
Exactly: agentic browsers act with the employee's authority across web and internal apps, so an injected instruction from a page can drive real, damaging actions. Without a perimeter there's no consistent policy, no way to stop tainted data from driving sensitive actions, and no visibility — and a ban only pushes it into the shadows where it's worse.
Resource use is trivial next to the real problem: autonomous agents taking real actions with employee authority, driven partly by untrusted web content, with no central containment or visibility.
Agentic browsers act with the employee's full authority across web and internal apps, so an injected instruction from a page can drive real exfiltration or destructive actions — and with no central policy, no data-flow control, and no fleet visibility, the enterprise can neither prevent nor even see it. Banning them just converts visible usage into shadow usage.
Why this piece earns its place
The reason this risk goes unmeasured is that an agentic browser acts inside the employee’s own session. Every downstream system — the SaaS audit log, the identity provider, the DLP console — records a person’s name on an action a model chose. There is no actor=agent dimension to query, so before a perimeter exists you cannot answer the first question a security team asks, which is how much of this is already happening. The absence of alerts reads as absence of usage. It also breaks incident response: when data leaves the company, scoping the breach means separating what a human did deliberately from what an agent did because a page told it to, and after the fact those are the same log line. So the first deliverable of a gateway is attribution, not enforcement. A mode that only labels and records agentic actions, blocking nothing, is already worth shipping on its own — it is what lets you write the policy and the allowlist below from observed traffic instead of guessing, and guessing is how you end up with rules that block real work on day one.
What the new pieces do
- Web / SaaSdata
- The external web pages and internal SaaS the agents operate — the source of both the task and, dangerously, of untrusted content that can carry injected instructions.
Step 2 · The perimeter
Route the fleet through one gateway
First move: agentic-browser actions don't touch the web and internal apps directly — they flow through a Security Gateway that mediates on the fleet's behalf. Why is a single perimeter the prerequisite for containing a fleet?
Why funnel all agentic-browser actions through one gateway instead of securing each agent locally?
Speed isn't the goal. The perimeter exists to be the one place org-wide policy, data-taint rules, action gating, and approval can be enforced and observed — consistently, for every agent, regardless of how each was configured.
Per-employee settings are exactly the problem — inconsistent, unauditable, and only as good as the least careful person. The gateway centralizes enforcement so security doesn't depend on each agent's local config.
Right: the gateway is the enforcement and observation point for the whole fleet. Funneling every action through one perimeter is what makes consistent, org-wide containment possible — a single place to enforce policy and see everything, instead of thousands of independently-configured agents.
Every agentic-browser action flows through the gateway, which mediates on the fleet's behalf. This single perimeter is the one place org-wide policy, taint tracking, action gating, and approval can be enforced and observed consistently — turning thousands of independent agents into one governable, visible fleet.
Why this piece earns its place
Start with what the gateway keys its state on, because everything downstream inherits that choice. A session has to span an agent’s whole task and bind to the human it acts for, not to the device or the browser instance — key it to a machine and a shared laptop merges two people’s work under one set of labels, and a held action arrives with nobody to route it to. Give that session a defined lifetime too: when the task ends, its taint labels and any pending approvals end with it, or a stale hold blocks unrelated work tomorrow and the fastest fix anyone finds under pressure is to clear state for the whole fleet. The second property worth saying out loud is that this is the cheapest piece to build early and the most expensive to retrofit. Put the seam in the action channel now and policy, gating and approval arrive later as configuration. Let agents reach systems directly first and every integration has to be unpicked one at a time while people already depend on it — and that unpicking lands on whoever asks for the control, never on whoever skipped it.
What the new pieces do
- Security Gatewaygateway
- The single perimeter every agentic-browser action flows through. It applies central policy, tracks data taint, gates actions, and routes high-risk ones for approval — so containment is enforced org-wide, not configured agent-by-agent.
Step 3 · One policy
Enforce a central, org-wide policy
The gateway needs to know what the fleet is allowed to do. Where does that come from — each agent's local config, or one central place? And why does it matter for a fleet?
Where should the rules for what agents may do come from?
Local config means thousands of different, unauditable policies — as strong as the least careful employee. A fleet can't be contained if every agent decides its own rules; a single lax config is a hole in the whole perimeter.
Right: one policy, centrally managed, applied uniformly. Which sites agents may act on, which actions are allowed, which data classes they may touch — decided once for the organization and enforced at the perimeter, so security doesn't vary agent-to-agent and can be updated fleet-wide in one place.
Asking the model to decide policy is exactly what an injected page tries to subvert. Policy is an organizational decision enforced before the model's judgment is trusted, not delegated to the agent being contained.
A central Policy Engine defines one org-wide policy — permitted sites, actions, and data classes — enforced identically for every agent at the gateway. Security no longer varies agent-to-agent or depends on the least careful employee's config, and the whole fleet's rules can be updated in one place.
Why this piece earns its place
Centralizing policy centralizes the blast radius with it. One bad rule now stops the whole fleet at once, and the people it stops are doing their jobs, so this needs the discipline any config-as-code system needs: policy is versioned, changes roll out staged, and a change can run in shadow — logging what it would have blocked — before it blocks anything. Stamp the deciding policy version onto every decision. Without that, a record read six months later says an action was refused and nothing about the rule that refused it, and nobody can tell a deliberate tightening from a mistake. The second thing policy needs is an exception path. Deny-by-default on day one stops work that was fine last week, and if the only route around it is a ticket that takes a week, people go back to the ungoverned browser this design exists to pull them away from. Exceptions need an owner and an expiry, or they quietly become the policy. Evaluation itself should be cached at the gateway — and then a short cache lifetime is the price of a revocation that actually lands.
What the new pieces do
- Policy Engineservice
- The central source of what the whole fleet may do — which sites, which actions, which data — so security isn't left to each agent's local config or each employee's discretion.
Step 4 · The key mechanism
Track taint from untrusted content
Here's the mechanism that makes fleet containment actually work against injection. An agent reads a web page (untrusted) and later takes an action (sensitive). How do you stop the page's content from driving the action — without banning the agent from reading pages at all?
An agent reads an untrusted page, then attempts a sensitive action. How do you prevent the page from driving it?
You can't reliably detect every injected instruction in arbitrary web content — and blocking pages breaks the agent's job of reading the web. The problem isn't reading untrusted content; it's letting that content flow into a dangerous action.
That defeats the entire purpose of an agentic browser. The goal is to let it read the web safely, not to blind it. Containment has to allow reading while controlling what the read data can go on to do.
Right: this is data-provenance / taint tracking, the core containment mechanism. The agent can read anything, but every value derived from untrusted content is labeled tainted and tracked. Policy then forbids tainted data from reaching a sensitive sink — so "email this to X" is fine if X came from a trusted source, and blocked if X was injected by the page. You control the data flow, not the reading.
The Taint Tracker marks every value derived from untrusted web content as tainted and follows it through the workflow. Policy then forbids a tainted value from driving a sensitive action — so the agent can read the whole web freely, but content injected by a page can never cross into an exfiltration or a destructive action. You control the data flow, not the reading.
Why this piece earns its place
The hard part is not marking the data, it is stopping the mark from spreading to everything. The agent’s context mixes your instructions with page text, so the moment it summarizes a page the summary is tainted too, and a naive implementation taints the entire session on the first read and then refuses every action for the rest of the task. What makes taint usable is declassification: a narrow, explicit path by which a value stops being tainted at all — a human endorses it, or it matches a strict shape like an internal record id that leaves an attacker no room to write anything. Design that path with more care than the rule that blocks, because it is where an attacker will aim. Keep it distinct from a sink exemption, which permits one flow to one approved destination and changes nothing about the value itself: there the label stays on, and it has to, or a value laundered through one blessed destination comes back clean everywhere else. Then watch the asymmetry in your feedback. Over-tainting is loud: someone is blocked, files a ticket, and you hear about it that afternoon. Under-tainting is silent, because a leak that succeeds produces no signal at all. Every operational pressure pushes toward loosening and nothing pushes back, so loosening has to be a reviewed change with a name on it, not a knob someone turns during an outage.
What the new pieces do
- Taint Trackerservice
- Marks every value the agent derives from untrusted web content as tainted and follows it through the workflow, so policy can forbid a tainted value from ever driving a sensitive action.
Step 5 · Bounding actions
Allowlist and classify every action
Taint controls what data can drive an action; now bound the actions themselves. The agent attempts to click, submit, delete, send. How should the gateway decide what's permitted?
How should the gateway handle the actions an agent attempts to take?
Correct: an allowlist plus risk classification. Most actions the fleet takes are routine and can run automatically; the small number that are sensitive or irreversible (bulk delete, fund transfer, mass send) are classified as high-risk and routed to the approval path. This bounds what agents can do while keeping the common case frictionless.
Reviewing after the fact doesn't bound anything — an irreversible action is already done by the time you read the log. High-risk actions need a decision before they execute, which requires classifying and gating them at the perimeter.
The agent deciding its own actions are safe is exactly what an injection subverts. Action permissions are a policy decision enforced by the gateway, not a judgment delegated to the agent being contained.
The Action Gate checks every attempted action against an allowlist and classifies its risk. Routine actions pass automatically; sensitive or irreversible ones are flagged for the approval path. This bounds what any agent can do while keeping the frequent, low-risk actions frictionless — containment without grinding the fleet to a halt.
Why this piece earns its place
An allowlist needs a unit, and a click is not one. The same submit is trivial or a fund transfer depending on what it hits, so the gate has to key on the verb, the target resource and the scope — and none of those can be recovered from a mouse event on a rendered page. That is what forces the integration down to the structured action the agent requests rather than the pixels it moves: if an agent cannot declare what it is about to do in a form the gate can read, the gate is guessing. Split the knobs accordingly. Which verbs exist and how risky each one is belongs in central policy; the scope belongs in the request, because deleting one record and deleting the quarter are the same verb and only the request knows which. The operational trap is the half-finished task. A refusal that lands after a side effect is already written leaves the workflow in a state nobody designed, so the gate sits in front of the effect, and the agent needs a defined behaviour on refusal — stop and report, not retry by another route.
What the new pieces do
- Action Gateservice
- Checks every action the agent attempts against an allowlist and classifies its risk — routine actions pass, sensitive or irreversible ones are flagged for the approval path.
Step 6 · The human checkpoint
Approval breakpoints and fleet audit
A high-risk or tainted action reaches the last line. What happens to it, and how do you keep the whole fleet visible without drowning humans in approvals?
How should the perimeter handle a flagged high-risk action, and record fleet activity?
Auto-approving high-risk actions removes the entire point of flagging them, and logging nothing leaves you blind to incidents. The whole design exists to catch the consequential actions and to see what the fleet did.
Approving every action creates instant approval fatigue — humans rubber-stamp to keep working, and the checkpoint becomes theater. The point of risk classification was precisely so that only the small consequential minority needs a human.
Right: human-approval breakpoints for the consequential minority (with enough context to decide well), automatic execution for the routine majority (so no approval fatigue), and an immutable fleet-wide log of everything for visibility and investigation. That balance is what makes the perimeter both safe and usable at scale — and the audit trail is how a security team finally sees the agentic-browser activity that was invisible before.
Only high-risk and tainted actions are held for a human decision with full context; routine actions run automatically, so approval fatigue never sets in. Every action and decision across the fleet is appended to an immutable audit trail — giving the security team the fleet-wide visibility that ungoverned agentic browsers never provided, and making any incident reconstructable.
Why this piece earns its place
The approval screen is itself an attack surface, and this is the part teams get wrong. If it shows the agent’s own description of what it is about to do, then the page that injected the instruction also wrote the sentence the human reads, and the checkpoint has been defeated politely. Show the raw target and the provenance instead — this value is tainted, it came from that page — and let the approver look at the thing rather than a summary of it. Give the queue a timeout and a default, and make the default refuse: a request that expires into an execution is worse than having no checkpoint, because everyone believes there is one. The queue needs a named owner and a response time too, or it becomes the slow path people learn to route around. What the record has to add beyond the decision itself is causality — one correlation id tying an action back to the page that was read and the labels that value carried — and, for a held action, what the approver was actually shown at the moment they said yes. Without that second half, a misled approval and a deliberate one are the same entry afterwards — which is the first thing an investigation has to tell apart. And treat the log as sensitive: it holds excerpts of everything the fleet touched, which makes it the richest single target in the design.
What the new pieces do
- Approval + Auditcontrol
- Holds high-risk and tainted actions for a human decision with full context, and appends every action and decision across the whole fleet to an immutable record for visibility and investigation.
The payoff
A fleet you can let run
Put it together: thousands of agentic browsers can do their useful work across web and internal apps — and the company keeps one policy, controls where untrusted data can flow, bounds every action, holds the dangerous ones for a human, and sees it all.
That's the agentic-browser security gateway. A fleet perimeter with central policy, taint tracking, action gating, approval breakpoints, and audit — the org-level containment that a single agent's own injection defenses can't provide across thousands of endpoints.
Everything you assembled, in order
- Agentic browsers can't be banned effectively — the goal is fleet containment, so every action flows through one gateway perimeter.
- A central Policy Engine defines one org-wide policy, enforced identically for every agent — security no longer depends on each employee's local config.
- Taint tracking marks data from untrusted web content and forbids it from driving a sensitive action — controlling the data flow, not banning reading.
- An action allowlist with risk classification passes routine actions automatically and flags the sensitive, irreversible ones.
- Human-approval breakpoints catch only the consequential minority (no approval fatigue), and an immutable fleet-wide audit trail finally makes the activity visible.