Your AI Agents Belong Inside Your Perimeter

Over the last sixty days, the largest names in browser security and SASE have converged on a single product story. Menlo Security launched a "Browser Security Platform to Govern AI Agents." Palo Alto Networks rebuilt Prisma Browser for "the agentic AI era." Island rolled out a new Enterprise AI suite that includes a hosted agent automation layer. Akamai signed a $205 million deal to acquire LayerX and bring its AI usage controls under the Akamai SASE umbrella. Versa shipped a Secure Enterprise Browser positioned as the control point for agents inside the VersaONE platform.

Each of these announcements is interesting on its own. Read together, they describe a single, coherent industry bet: AI agents are about to outnumber human employees inside the enterprise, the browser is the place to govern them, and the vendor cloud is the place where that governance should run.

Half of that bet is correct. The browser is the right control point. The other half is structurally wrong for any buyer who has spent the last decade pulling sensitive workloads back inside their perimeter. If an AI agent is acting on behalf of your organization, the agent's reasoning, its visible context, its credentials, and every decision it makes are some of the most sensitive telemetry your enterprise produces. Routing that telemetry through a third-party multi-tenant cloud, then trusting the vendor's runtime to make policy decisions on your behalf, is a model that defense, intelligence, financial services, healthcare, critical infrastructure, and regulated EU buyers should not accept by default.

This post lays out what the major vendors are actually shipping, why their architecture works against the most security-conscious end of the market, and what the inverse position looks like. Surface Security has been building toward this inverse position from day one. The recent round of competitor announcements makes the contrast unusually clear.

What the Major Vendors Just Announced

Menlo Security: cloud-rendered "Guardian Runtime" for agents

On March 18, 2026, Menlo Security announced its Browser Security Platform purpose-built to secure the agentic enterprise (also published on the Menlo press releases page). The headline framing is direct: "the next billion users will not be human." The product introduces Menlo AI Agent Security as a "Guardian Runtime" that enforces instruction-data separation, least-privileged agent access, and exfiltration controls.

The deployment model is also direct. Menlo describes the platform as "deployed globally on Menlo's elastic cloud infrastructure," and the architecture brief describes "Architectural Immunity" produced by "a cloud runtime processing with multimodal visual analysis before reaching an AI reasoning workflow or a human endpoint." Menlo CEO Bill Robbins frames the value as moving "protection directly into the browser session" so organizations can deploy AI agents "without opening the door to catastrophic prompt injection or data exfiltration." In practice, the agent's view of the web is rendered, scanned, and policy-evaluated inside Menlo's cloud. That is consistent with the Menlo Security architecture write-up at Help Net Security and the SiliconANGLE coverage of the same announcement.

Palo Alto Networks: Prisma Browser, rebuilt for agentic AI

Five days later, on March 23, 2026, Palo Alto Networks announced the industry's most secure browser built for agentic AI. The new Prisma Browser ships an Agentic Workspace that lets organizations route work across multiple LLMs, blocks prompt injection at the page level, claims to draw a line between human and automated actions for audit purposes, and discovers sensitive data across the AI lifecycle.

Prisma Browser is part of the broader Prisma SASE platform. It is cloud-delivered, depends on Palo Alto's cloud-native ZTNA and security services, and is rolled out to endpoints through MDM. The browser is the local enforcement layer, but the policy, telemetry, and analytics surface lives in Palo Alto's cloud. The Prisma Browser deployment guide walks through the MDM rollout against that cloud control plane.

Island: AI Protect, AI Browser, AI Automation

On March 17, 2026, Island unveiled a set of Enterprise AI offerings layered on its enterprise browser. AI Protect governs AI usage across web tools, desktop apps, and connectors. AI Browser embeds a governed chat experience with multiple AI providers and RAG over corporate data. AI Automation lets teams "build and run on-demand agents that operate at machine speed across enterprise applications."

The same week, Island also rebuilt its SASE story around a single enterprise control plane. That control plane lives in Island's Management Cloud, with traffic inspected either inside the browser process or at points of presence deployed on GCP, Azure, and AWS. Agents built and run inside Island's AI Automation product inherit the same control plane.

Akamai and LayerX: $205M for browser-native AI usage control

On May 14, 2026, Akamai announced its intent to acquire LayerX for approximately $205 million, positioned as a "critical step in the evolution of its Zero Trust security portfolio" and aimed squarely at AI usage control. LayerX is a browser-native AI usage control product that extends across consumer browsers and the new generation of agentic browsers including Atlas, Comet, and others. The deal is expected to close in Q3 2026.

LayerX is delivered as a managed extension, but the management plane, telemetry, and policy engine are SaaS by design. Once inside Akamai, the platform will be folded into Akamai's edge and zero trust footprint, both of which are cloud-delivered.

Versa: Secure Enterprise Browser inside the SASE platform

Versa also shipped a Secure Enterprise Browser as part of the VersaONE Universal SASE Platform, with a Zero Trust Model Context Protocol layer designed to authenticate, authorize, and govern AI agent actions across infrastructure. Like Palo Alto and Akamai, the security control plane is part of the SASE cloud.

The common thread across all five announcements is a SaaS-delivered control plane that sits between the agent and the work it does. That is a defensible choice for some buyers. It is the wrong default for the buyers who are most likely to be reading this post.

The Architectural Problem

Take any one of those products at face value and ask a single question. If an AI agent inside my organization is doing real work, what is the data exhaust?

The answer is uncomfortable. An agent operating inside the browser session generates four streams that are individually sensitive and collectively explosive:

1. The page content the agent sees. Every internal SaaS view, every customer record, every financial dashboard, every patient chart the agent reads is part of its context.
2. The agent's reasoning. Prompts, intermediate plans, tool calls, and decision steps describe how your organization actually operates.
3. The credentials and tokens the agent uses. API keys, session cookies, SSO tokens, and machine credentials authenticate against systems that matter.
4. The actions the agent takes. Form submissions, file uploads, downloads, and outbound requests are the record of work done on the organization's behalf.

In a cloud-rendered or cloud-policy-evaluated architecture, all four streams flow through the vendor's infrastructure. That is what "cloud runtime processing" and "elastic cloud" mean in practice. The vendor sees what your agents see, knows what your agents are planning, holds your machine identities, and observes every action the agents take. The vendor's compliance posture, jurisdiction, breach history, subpoena exposure, and contractual fine print all become part of your effective security boundary.

There are legitimate reasons the major vendors are doing this. Cloud rendering provides isolation. A multi-tenant policy engine learns faster across customers. Centralized telemetry enables threat intelligence at scale. None of these are bad arguments. For a mid-market organization without a SOC and without strict data residency obligations, a cloud-delivered platform with strong contractual controls is often a reasonable trade. The mistake is treating that trade as the default for everyone.

For the buyers where Surface focuses, the trade does not pencil out:

• Defense and intelligence customers have explicit prohibitions on routing mission-related data through commercial multi-tenant clouds. An AI agent doing analyst-adjacent work inside a browser is precisely the kind of workload those prohibitions exist for.
• Financial services customers operate under regulatory regimes that treat browser session content, particularly customer-facing data, as material non-public information. A vendor cloud holding that data introduces a third-party risk that is hard to defend in a regulatory exam.
• Healthcare customers subject to HIPAA, GDPR, and equivalent regimes face a covered-entity boundary problem. An AI agent reading patient charts inside a vendor cloud has to be governed by a Business Associate Agreement that is itself a long, fragile contractual artifact, and any breach exposure is doubled.
• Critical infrastructure customers under NERC CIP, NIS2, and similar regimes are already constrained on what telemetry can leave operational technology environments. Adding an agent layer that pipes back to a vendor cloud is moving in the wrong direction.
• EU regulated industries are working through the practical implications of the EU AI Act and Digital Operational Resilience Act. Both lean hard toward sovereign processing and verifiable on-premises options for the highest-risk AI use cases.

For each of these buyers, "send the agent's reasoning and the page content through our cloud" is not a feature. It is a hard constraint. The vendor messaging acknowledges this in fine print (regional clouds, BYOK, "private deployment options on the roadmap") but the architecture is fundamentally SaaS-first. Bolt-on private regions do not change where the trust boundary actually sits.

We made a related argument about cloud telemetry for browser security in general in Surface vs. Enterprise Browsers and in Why Does Surface Security Exist?. The agentic case is the same argument with the volume turned up. If the data is worth protecting, it is worth keeping inside the perimeter. Agent telemetry is some of the most sensitive data an enterprise produces.

The Inverse Architecture

The opposite stance, and the one Surface has held from the start, is that AI agents should run inside your perimeter, with detection and policy enforcement running on-device or on your infrastructure, and with the vendor's cloud nowhere in the data path.

That position is not novel. It is the same architectural posture defenders already apply to SIEM, EDR, vault, and code-signing infrastructure. The reasoning is identical. Tooling that mediates high-value workflows belongs inside the trust boundary it is supposed to defend. Once you accept that browser sessions are the new operational workspace, and that agentic workflows are some of the highest-value sessions inside it, the conclusion is straightforward.

Concretely, this means four things.

Detection on-device, not in a vendor cloud. Prompt injection scanning, exfiltration monitoring, and credential scope enforcement should run inside the browser extension at the moment the agent acts. The detection logic should ship with the extension and execute locally on the page DOM and outbound requests. No page content, no agent reasoning, no credential material should ever leave the user's machine for a third-party runtime in order for a policy decision to happen.

Policy and telemetry on your infrastructure. The control plane that aggregates events, defines policy, and surfaces investigations should run inside your network. On-prem on Docker, Kubernetes, VMs, bare metal, or air-gapped if needed. Your SOC queries it. Your SIEM ingests from it. Your compliance team audits it. No vendor multi-tenant database holds the events.

Agent identity that you control. Watermarks, agent IDs, and behavioral baselines should live in your platform, not in someone else's. When the post-incident question is "which agent did what, and which page convinced it," you should not have to file a support ticket to get the answer.

On-prem AI analysis where applicable. When local LLM analysis is useful for alert triage or anomaly explanation, it should run on your own inference infrastructure (Ollama, vLLM, internal endpoints), not in a vendor-hosted model. Anything an LLM sees as part of analysis is itself sensitive context.

We described how Surface implements the first three layers, on-device detection, exfiltration monitoring, and credential scope enforcement, in Agentic AI Security: Protecting Your AI-Powered Browser Agents. The fourth, on-prem LLM alert analysis, is in the same product. The post you are reading is the architectural framing those features sit underneath.

Why "Just Run It in the Cloud" Will Sound Convenient Until It Does Not

The cloud-rendered model is genuinely easier to ship and easier to demo. Vendors get a global view across their tenants, they can patch detection logic centrally, and they avoid the operational overhead of customer-managed infrastructure. The demo flows beautifully because no piece of the pipeline depends on the customer's environment.

The reasons that convenience breaks down in production for the regulated buyer are predictable, and they are the same reasons cloud-only SIEM, cloud-only DLP, and cloud-only secrets management have all spawned strong on-prem alternatives in their respective markets:

• Data residency. Sovereignty regimes are tightening, not loosening. The EU AI Act, the UK National Security and Investment Act, US Executive Order 14117 on bulk sensitive data, and equivalent regimes in APAC are all moving the trust boundary closer to the customer.
• Vendor breach exposure. Every major SaaS browser security or SASE vendor will, at some point, have an incident that involves a customer's data. The mitigation is to keep the most sensitive data out of the vendor's perimeter in the first place. We wrote about how we think about this from our side of the equation in What If We Got Hacked? How We Protect Our Update Pipeline.
• Subpoena and legal hold exposure. Vendor-held data is subject to legal processes that bypass the customer entirely. Customer-held data is not.
• Latency and air-gap requirements. Operational technology, financial trading floors, classified networks, and clinical environments have hard requirements that no cloud-delivered architecture can satisfy.
• Vendor lock-in on machine identity. If the vendor owns the agent identity layer, switching vendors means re-issuing every agent identity inside your environment. That is a substantial migration that quietly raises switching costs.

These are not theoretical concerns. They are the same concerns that, over the last ten years, drove serious enterprises to demand on-prem and BYOK options across the security stack. There is no reason the agentic browser layer would be the exception, especially as agents start to handle workloads that previously demanded a human analyst.

Where Surface Sits

Surface was built around the on-prem premise. The control plane runs on the customer's infrastructure. The extension runs in the browser the employee or the agent framework already uses. Detection runs on-device. Events flow into the customer's own Redpanda and ClickHouse deployment. Optional LLM analysis runs against an Ollama endpoint inside the customer's network. No browsing or agent telemetry leaves the perimeter.

For agents specifically, Surface ships a framework-agnostic extension bundle for Playwright, Puppeteer, Selenium, Browser Use, and Stagehand. Three protections activate on every page the agent visits:

• DOM-level prompt injection detection across fourteen technique categories, with sanitization before the agent's LLM processes the page.
• Outbound request monitoring across fetch, XMLHttpRequest, and sendBeacon, with allowlist enforcement and full request logging.
• Credential scope pinning, so credentials provisioned to an agent stay tied to the origins they belong to even if the agent is hijacked.

Each blocked attempt is logged with full page context, technique classification, and the watermarked identity of the agent that hit it. The Agentic dashboard surfaces active agent counts, blocked prompt injections by technique, exfiltration attempts, and credential scope breaches in a single view.

None of this routes through a Surface-operated cloud. There is no Surface-operated cloud in the data path. We described the deeper architectural reasoning in Why Does Surface Security Exist?.

The Choice the CISO Actually Has to Make

The vendors converging on the cloud-rendered, cloud-governed agent model are not wrong that the browser is the right control point. They are right. The argument is about where the control plane lives. For most of the security market, a cloud-delivered control plane is operationally simpler, and the trade is acceptable. For defense, intelligence, financial services, healthcare, critical infrastructure, and EU regulated industries, the trade is not acceptable, and the vendors offering "private region" options are offering a partial answer to a structural problem.

If your organization is in one of those segments, the question to put in front of your team in the next planning cycle is straightforward. When an AI agent inside your browser session reads a sensitive page, plans an action, uses a machine credential, and submits a form, where does the policy decision happen, and where does the resulting event live? If the honest answer involves a vendor cloud, the architecture needs another pass.

We built Surface so the honest answer is "on your own infrastructure." If you want to see what that looks like in your environment, get in touch. If you are still early in the evaluation, Surface vs. Enterprise Browsers is the architectural comparison, and Agentic AI Security is the deeper dive into how the agent protections work.