An agent can fire a thousand tool calls in the time it takes an employee to write one prompt. Each call reads a file, queries an API, touches a SaaS tenant, or writes data somewhere new. Nobody approves them one by one, and nobody is watching. That is the shape of enterprise work now, and it is nothing like the shape enterprise security was built for.

A decade ago the assumptions held together. Employees worked on managed devices, inside corporate networks, reaching applications that lived in data centers. Data moved across wires you controlled. The perimeter was a real thing you could draw on a whiteboard, and architectures like SASE were designed to defend it. For that era, it was the right answer.

Work moved, and AI security broke down along the old seams. An analyst pushes a financial model through an AI assistant and the assistant writes the output to personal cloud storage. A coding agent reads a proprietary repository, calls three external APIs, and opens a pull request. A support agent queries the CRM under a service account, summarizes twelve customer records, and sends the summary to a destination nobody reviewed. Your data moved right along with it.

That traffic crosses the network, and that’s exactly the problem. By the time an agent's activity shows up as packets, it looks like an encrypted stream to a popular API endpoint, and the network has no way to tell the difference between an agent reading a public document and an agent draining your customer database.

Security architecture built for a different era

Traditional SASE standardizes on a single execution pattern. Network traffic gets backhauled to a cloud proxy, broken down, inspected, and forwarded to its destination. Every part of that chain assumes the proxy can sit in the middle and see what is inside. Enforcement depends entirely on routing sessions through centralized inspection points in distant points of presence.

Modern web protocols are engineered so that no middle agent can intercept and inspect. The majority of traffic runs over TLS 1.3. HTTP/2, HTTP/3, and QUIC ship in every major browser. Certificate pinning prevents decryption for a growing list of applications, and post-quantum cryptographic implementations are already in production. These protocols were built for speed and privacy, and they are structurally incompatible with break-and-inspect.

Even where the proxy can still decrypt, browser-based work has moved to interaction patterns the proxy cannot interpret. Modern SaaS and AI tools hold persistent connections, WebSockets especially, carrying continuous bidirectional streams rather than the discrete request and response pairs a proxy can parse into a file upload or a form submission. The proxy sees an open pipe with data flowing through it.

So the middlebox faces two problems at once. It increasingly cannot decrypt, and when it can decrypt, it cannot interpret. Both follow directly from where the proxy sits relative to where the work and the encryption now live.

Why SASE can’t govern AI

AI turns those two problems into three, and every one of them lands on the same architecture.

Treating AI as a network problem is only half the story

Agents do not live on the wire. They run at the OS level, reading and writing local files, invoking local binaries, and reaching into whatever the host will give them. They run at the identity level, acting under service accounts, OAuth grants, and delegated tokens that belong to a person without being that person. They run at the browser level, holding authenticated sessions across multiple tenants at once. 

Some agents never touch your network at all. They live inside the SaaS platforms your business already runs on. They execute in the vendor's cloud, and they increasingly call each other, one platform's agent invoking another's, reading records in one system and writing them into the next. None of it crosses your perimeter. No packet ever reaches your proxy. To a SASE vendor this activity does not exist, and you cannot inspect traffic that was never yours to route.

Governing agents means seeing all of those layers at once, including the ones that never route through you. A network chokepoint gives you one of them, and the least informative one.

Packets don't carry intent

Intent is the unit of policy in an agentic world. Not the destination, not the port, not the byte count. The question worth asking is whether this agent, acting for this user, under this identity, should be allowed to read this data and send it there.

Inspecting packets to reconstruct that is hard when a human is driving. It gets much harder with an agent, because the operations arrive faster than any analyst can review them, they arrive without a human in the loop to sanity-check the next step, and the model deciding what to do next is not yours. You have some influence over how an employee behaves. You have far less over a model, and a prompt injection buried in a document the agent happens to read can redirect it entirely. Policy has to understand what is being attempted, and packet metadata never answers why.

AI breaks the economics of inspect-everything

An employee generates a few thousand network events across a workday. An agent generates that in a minute, and one prompt can fan out into hundreds or thousands of tool calls. Multiply that by every employee running every assistant, then add the agents running with no employee attached at all.

Backhaul all and inspect all was already expensive. At agentic volume it stops being an architecture and becomes a bill, paid in latency, in point of presence capacity, and in the growing list of bypass rules teams write to keep critical applications usable. Every entry on that bypass list is a hole in the enforcement model you are paying for.

Which leaves one control

SASE can only act on what it can see, and what it can see is a destination. That yields exactly two options.

• Blocking AI pushes usage into personal, unmanaged tools and fuels shadow AI. Employees route around the limits to reach the tools they want, expanding the attack surface the block was meant to shrink.
• Allowing AI without visibility means data leakage, compliance exposure, and no accountability.

Two bad options are not a choice. This is not a missing feature waiting for a future SASE release. The architecture cannot resolve it, because enforcement sits at a chokepoint the work has already outgrown.

What effective AI data security looks like

If the risk lives at the endpoint, the identity, and the browser session, enforcement has to live there too.

Governing the last mile, before data leaves the device, gives you the context the network never had. You can see which user is driving, which identity an agent is acting under, which tenant a session is authenticated to, what a tool call is reading, and where the output goes. You can see the prompt and the thousand operations that follow it.

• Tool calls, MCP interactions, prompt content, agent identity, tenant context, and output destinations are all visible
• Enforcement runs on what actually happened, not on what packet metadata implies
• Zero Trust applies per user, per session, per action, and per agent

AI governance stops being a binary. It becomes saying yes without losing control. Operational overhead drops too, because one policy engine and one audit trail replace service chaining across separate consoles and the work of reconciling overlapping SWG, CASB, and ZTNA rule sets. Policy gets defined once and enforced consistently. Deployments that used to take months compress to days.

How Island does SASE differently

Island starts from a different premise. Enforcement belongs at the last mile, in the browser and on the endpoint, before data ever leaves the device. Island calls this the Perfect Packet. Policy chooses the most efficient and secure path for every session rather than defaulting to a single route. Most sessions go direct, with enforcement running locally. Cloud inspection gets invoked only when policy calls for it.

The practical differences:

• Most traffic goes direct. No mandatory backhaul, no forced TLS inspection degrading performance, no bypass lists needed to keep modern applications working. Every session stays governed.
• Enforcement sees the operation, not just the packet. Prompts, tool calls, MCP interactions, uploads, tenant context, and output destinations are visible at the moment they happen, because policy runs where the work runs.
• Agents are governed like users. Island sees the identity an agent acts under and the operations it performs across users, devices, and agents, so the answer is yes within policy rather than block or allow.
• SaaS-resident agents are governed too. Island integrates with the agent platforms inside Copilot Studio, Salesforce, ServiceNow, Snowflake, and Slack, so agents running in a vendor's cloud fall under the same policy as agents running on your endpoints. Agent-to-agent activity between SaaS platforms lands in the same audit trail as everything else.
• One control plane. A single policy engine and one audit trail span browser, endpoint, and network. No service chaining, no overlapping rule sets, no policy re-evaluation across points of presence.

That is the trifecta traditional SASE promised and rarely delivered: stronger security, a better user experience, and operations that scale without compounding complexity.

Read the report to go deeper

Island’s guide The Perfect Packet:
A Guide to Modern SASE Architecture dives much deeper. Learn the four critical AI governance controls, follow a phased deployment path, and read five real-world use cases of customers using Island to protect their data, enable their employees, and safely say yes to AI. It also includes a SASE evaluation checklist: a structured set of questions across visibility, performance, deployment, AI risk, and operations, designed to surface the gaps dashboards tend to hide.

FAQs

Does blocking AI tools eliminate the risk of data leakage?

No. Blocking pushes employees toward ungoverned tools and fuels shadow AI. The attack surface expands rather than shrinks when work moves out of your line of sight.

Can Island govern AI prompts, tool calls, and MCP interactions?

Yes. Because enforcement runs in the browser and on the endpoint, Island sees prompt content, tool calls, MCP interactions, agent identity, tenant context, and output destinations at the moment they happen. AI governance becomes yes within policy rather than block or allow.

Why can't a SASE proxy just inspect AI traffic?

Two reasons. Most of it cannot be decrypted, thanks to TLS 1.3, QUIC, and certificate pinning. And even decrypted, packets do not carry the context that matters: which identity an agent is acting under, what it read locally, or what it intends to do with the result. Volume compounds both problems, because a single prompt can produce thousands of operations.

Does Island require separate policy engines for SWG, CASB, and ZTNA?

No. Island consolidates governance into a single policy engine and one audit trail across browser, endpoint, and network. No service chaining across consoles, no overlapping rule sets to reconcile, no policy re-evaluation between points of presence.

Can Island deployments scale faster than traditional SASE rollouts?

Yes. Deployments that take months with traditional SASE compress to days with Island, because policy gets defined once and enforced consistently at the endpoint. No service chaining, no point of presence routing logic, no compounding operational complexity.

Will my existing apps work with Island? What about desktop applications?

Yes. Island works with the web and SaaS applications your organization already uses. For desktop and legacy applications, Island Desktop extends the same governance model beyond the browser, so the controls you apply in the browser carry through to the rest of your stack.

Is using Island like using other browsers, or something employees have to learn from scratch?

It is the browser they already know. Island is built on the Chromium engine, the same foundation as Chrome and Edge, with familiar navigation, extensions, bookmarks, and developer tools. The security and governance capabilities run underneath, so adoption requires no training and no behavior change.

Can Island secure contractors, third parties, and BYOD users without managing their devices?

Yes. Because the controls live inside the browser itself, Island governs the work session regardless of who owns the device or how it is managed. Contractors, vendors, and BYOD users reach corporate applications through Island under the same policy enforcement as fully managed employees.

What about AI agents that run inside SaaS platforms like Copilot Studio or Agentforce?

Those agents execute in the vendor's cloud and often call other SaaS platforms directly, so their activity never crosses your network and never reaches a SASE proxy. Island integrates with those platforms to apply the same policy to SaaS-resident agents that it applies to agents on the endpoint and in the browser, with one audit trail covering all of them.

‍