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.

How to read this: Each step opens with a real design decision — make the call before I show you what ships. Watch the diagram grow, hover the boxes, and at the end let a web page hijack an action and trigger a bulk irreversible action to see the perimeter hold. Hit Begin.

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?

Design decision: Thousands of employees run agentic browsers that act on the web and internal apps, with no central control. What's the core risk?

The call: An unbounded, invisible attack surface: any agent can read a malicious page and be induced to exfiltrate data or take an unauthorized action, with no central policy, no data-flow control, and no fleet-wide visibility — and banning them just hides the usage. — 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.

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.

You can't ban your way out: The design premise is that agentic browsers are here and useful, so the job isn't prohibition — it's containment. Everything below builds a perimeter that lets the fleet run while bounding what any agent in it can do with company data.

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?

Design decision: Why funnel all agentic-browser actions through one gateway instead of securing each agent locally?

The call: A single perimeter is the one place to apply one org-wide policy, track data taint across actions, gate and approve actions, and get fleet-wide visibility — none of which is possible if each agent acts directly and independently. — 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.

One perimeter to contain the fleet: Containment at fleet scale requires a choke point. The gateway is where "each agent does its own thing" becomes "every action is subject to one policy and one audit," no matter whose machine it runs on.

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?

Design decision: Where should the rules for what agents may do come from?

The call: A central Policy Engine that defines one org-wide policy — which sites, actions, and data are permitted — enforced identically for every agent at the gateway. — 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.

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.

Policy is organizational, not per-agent: A fleet perimeter is only as strong as its weakest configuration, so the rules can't live on the endpoints. Centralizing policy is what makes containment uniform and updatable across thousands of agents at once.

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?

Design decision: An agent reads an untrusted page, then attempts a sensitive action. How do you prevent the page from driving it?

The call: Track taint: mark everything derived from untrusted web content as tainted, follow it through the workflow, and let policy forbid a tainted value from driving a sensitive action — read freely, but tainted data can't cross into a dangerous action. — 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.

Provenance beats detection: Rather than trying to detect every malicious instruction (impossible), you track where data came from and refuse to let untrusted-origin data reach a dangerous sink. This is the mechanism a per-page content filter can't provide, and it's what makes fleet-scale injection containment tractable.

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?

Design decision: How should the gateway handle the actions an agent attempts to take?

The call: Check each action against an allowlist and classify its risk — routine actions pass automatically, sensitive or irreversible ones are flagged for approval. — 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.

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.

Not all actions are equal: The perimeter distinguishes the thousands of harmless clicks from the handful of consequential ones. Allowlisting plus risk classification is what lets the fleet run at speed while the dangerous minority is caught for a closer look.

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?

Design decision: How should the perimeter handle a flagged high-risk action, and record fleet activity?

The call: Hold only the high-risk/tainted actions for a human decision with full context, let routine actions run automatically, and append every action and decision across the fleet to an immutable audit trail. — 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.

Humans for the few, automation for the many: The perimeter reserves scarce human attention for exactly the actions that warrant it and logs everything for accountability. That's what turns "contain the fleet" from a slogan into a system people will actually keep switched on.

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.

• 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.