The Architecture Problem SASE Can’t Outrun
The Case for Enforcement at the Edge, Not the Detour
SASE was supposed to be the answer.
When the perimeter collapsed and work scattered across SaaS applications, personal devices, and home networks, the industry needed an architecture that could follow. SASE promised exactly that. Converge networking and security into the cloud, route traffic through centralized inspection points, and apply policy regardless of where the user sits.
For a while, it worked well enough, and then AI entered the picture and accelerated a set of structural limitations that were already forming.
Over 20,000 enterprises purchased SASE solutions in 2025.
Most have only partially deployed the capabilities they own. Licenses sit unused, bypass lists quietly grow, and policies look complete on dashboards while gaps widen in practice. This is not a failure of execution or a vendor quality problem. It is a sign that the problem SASE was designed to solve has changed underneath the architecture and shelf-ware is pervasive.
Understanding where traditional SASE fits in that complexity, and where it falls short, matters for every practitioner evaluating their current stack.
The Detour Tax
The core execution model of traditional SASE is straightforward.
Traffic is backhauled to a cloud proxy, broken and inspected, and forwarded to its destination. Enforcement depends entirely on routing sessions through centralized inspection points at distant points of presence.
When that architecture was designed, it made sense. The problem is not that it was wrong, the problem is that it was designed for a world that no longer exists.
Every session routed through a distant PoP pays what you might call a detour tax. CRM sessions lag, video calls stutter, and ticketing systems stall. In bandwidth-constrained geographies, SaaS workflows become inconsistent or borderline unusable. Users feel this immediately and respond in the most predictable way possible. They find workarounds, they switch to personal devices, and they use unsanctioned tools. Every workaround quietly increases the attack surface, shadow usage, and security teams rarely learn about it until something goes wrong.
The reliability problem compounds this. When a PoP degrades, a certificate chain breaks, or a decryption policy change propagates incorrectly, the blast radius is broad. A user in Toronto connected through a Detroit PoP may find their location misidentified, their compliance posture incorrectly evaluated, and their sessions flagged for a border-crossing that never happened. Traffic shifts during failover can impact thousands of users at once.
Failure in this model is systemic, not local.
This is a pattern practitioners have seen before. Security architectures that create friction do not eliminate the behavior they are trying to govern. They push it into channels where security has even less visibility. As I covered in Bringing Security Out of the Shadows, this cycle has repeated with every major technology wave. Cloud, mobile, SaaS, and now AI. Security policies that default to blocking breed shadow usage, and shadow usage is always harder to secure than governed usage.
The Visibility Gap
Even when SASE works as designed, there is a structural limit to what network-layer inspection can see.
A network proxy can tell you that a file was uploaded. It cannot tell you what was copied into an AI prompt, pasted into a web form, or moved between SaaS tenants before submission. It can see destinations and payloads when decryption is possible. It cannot capture what a user actually did inside an application.
This gap matters because the most common ways sensitive data leaves an organization today do not look like network incidents. A freelancer copies customer data from a CRM and pastes it into an LLM. An analyst downloads a financial model and uploads it to personal cloud storage. A developer pushes proprietary code through an AI assistant to accelerate a sprint. None of these actions generate anomalous traffic patterns or trigger firewall alerts. They occur at the presentation layer, inside the application, at the moment of user interaction, as work is being created and used.
Even more so, they are increasingly occurring via autonomous agents, which have the ability to call tools and take actions in the enterprise, often with users identities, never appearing anomalous or unauthorized on the surface.
Modern encryption is making this gap worse, not better. TLS 1.3 reduces available metadata. Certificate pinning makes decryption impossible for a growing number of applications. Post-quantum cryptographic implementations are already deployed in major browsers, and they are structurally incompatible with break-and-inspect architectures. Organizations are left with a choice that should not exist. Block traffic you cannot decrypt, or accept the blind spot and allow it. Most choose the blind spot, and the bypass lists grow.
Every application added to a bypass list to preserve compatibility is an application outside the security perimeter.
An architecture that requires exemptions to function is not enforcing policy, it is avoiding it.
AI Did Not Break SASE But It Does Expose a Gap
AI did not create the architectural mismatch with traditional SASE, but it made the mismatch impossible to ignore.
Modern AI workflows are fundamentally non-linear. Employees paste sensitive internal data into prompts. AI agents call external tools, access internal documentation, and move generated output downstream at machine speed. That output flows into reports, code repositories, and customer communications. An organization’s agent workforce will soon operate using employees’ roles and access at 100 times human scale.
All of these interactions happen at the presentation layer, inside the application context, before any new network connection is established. By the time traffic reaches the network, the moment of intent has already passed. A network proxy sees the session but cannot see what is happening inside it.
Traditional SASE vendors respond with the only option their architecture permits. Block AI or allow it. Organizations that block AI push usage into personal, unmanaged tools, fueling shadow AI and expanding the attack surface they were trying to reduce. Organizations that allow AI without context accept data leakage, compliance exposure, and zero accountability for what employees send and receive. Neither approach is ideal or acceptable.
IBM’s 2025 Cost of a Data Breach Report found that 63% of organizations lack AI governance policies. Twenty percent of organizations surveyed experienced a breach due to shadow AI, adding $200,000 to $670,000 in costs compared to incidents without shadow AI involvement. The binary enforcement model is not just architecturally limited, it is actively producing the outcomes security teams are trying to prevent.
Leading analysts expects AI security capabilities, including prompt inspection and application controls, to become a key factor in SASE platform decisions over the next two years. Most current vendors stop at basic visibility or binary block controls. The architecture often simply does not support anything more.
The Shelfware Problem Is Structural
There is a pattern practitioners will recognize from their own environments. SASE licenses are purchased at scale then deployments stall, features are enabled but never fully tuned and exception lists accumulate. Multiple service chains and overlapping policies across SWG, CASB, and ZTNA create troubleshooting complexity that compounds over time and unsurprisingly, rollouts stretch from weeks to months.
Organizations end up running fragmented SASE stacks with multiple consoles and policy engines operating in parallel. Enforcement looks complete on dashboards while gaps persist in practice.
This is not a failure of organizational discipline and instead is a predictable consequence of architectures that require mandatory backhauling and extensive configuration before delivering meaningful coverage. When the deployment path is that long and complex, partial deployment becomes the norm rather than the exception.
The shelf-ware problem is structural, not operational, but it does have operational impacts as deployments stall, visibility is limited, the shelf-ware becomes part of the attack surface and concurrently eats away finite security budgets.
What Changes When Enforcement Moves to the Last Mile
If the risk lives at the presentation layer, in the actions users or agents take inside applications, at the moment data is created, copied, uploaded, or sent, then enforcement has to live there too. Not in a distant PoP after the moment of intent has passed, but at the point of work, before the data ever leaves the endpoint.
This is the architectural shift that separates the next generation of SASE from the current one. Moving enforcement to the last mile changes three outcomes simultaneously.
Security gets stronger because the visibility gap closes. Copy-paste actions, prompt content, tenant context, and output destinations all become visible. Enforcement is based on what users actually do, not inferred from packet metadata. Zero Trust is applied at the application layer per user/agent, per session, per action, and because modern protocols are supported natively, organizations do not need bypass lists to keep critical applications functioning, every session is governed.
User experience improves because most sessions go direct, and as we discussed when user experience improves, security doesn’t get undermined. There is no mandatory detour through a distant proxy, no forced TLS inspection degrading application performance, no latency from routing traffic through inspection points. Applications behave the way they were designed to behave. Users stop finding workarounds because they do not need them.
When security stops creating friction, adoption of sanctioned tools increases and IT spends less time managing exceptions.
Operations simplify because policy is defined once and enforced consistently. One policy engine. One audit trail. No service chaining across separate consoles. No overlapping rule sets between SWG, CASB, and ZTNA producing inconsistent outcomes. Deployments that used to take months compress to days.
How Island Approaches This
To provide a concrete example, I wanted to use Resilient Cyber’s Partner Island.
Island’s approach starts from a simple architectural insight, which is that enforcement should happen locally, as close to the action as possible, whether that action is in a browser, a desktop application, or an agentic AI workflow.
As I covered in The Rise of the Enterprise Browser, the enterprise browser represents a Secure-by-Design paradigm shift from bolt-on products focused on the endpoint or network.
Island enables organizations to say yes rather than no, allowing personal email, personal AI usage, and contractor access within governed boundaries rather than blocking everything and hoping shadow usage does not follow, but the enforcement story extends well beyond the browser.
Island Desktop performs local-first enforcement directly on the endpoint, governing agentic actions, MCP and tool calls, and data and file movements at the device level before anything leaves the machine.
This is not just a traffic steering mechanism that routes sessions to a cloud network for inspection, although it does that where policy requires it. The endpoint itself is the enforcement point. For desktop applications and non-web traffic, Island Desktop applies policy locally and steers traffic selectively to Island’s global network only when deeper analysis or routing adds genuine value.
Backhaul becomes the fallback, not the default.
Island Desktop also facilitates Zero Trust Network Access (ZTNA), which allows users to connect directly to private applications and resources, including private MCP servers. For organizations deploying agentic AI architectures that rely on internal tool registries and private MCP infrastructure, this is a meaningful capability. Agents can reach internal resources through governed channels without exposing those resources to the public internet or requiring traditional VPN tunnels.
For browser-based work, policy is applied natively inside Chromium at the DOM layer before content renders and before data leaves the session. No traffic rerouting, no TLS interception, and no break-and-inspect. Island also provides a browser MCP server that allows AI agents to access web pages through Island, but everything the agent does over that MCP server is governed by policy.
Sensitive data that policy blocks is not simply redacted into an unusable gap, it is replaced with a context placeholder, such as <US SSN #>, so the AI agent can still reason about the structure and meaning of the content without ever seeing the actual sensitive value. That distinction matters because outright blocking breaks agent workflows, while context-aware redaction preserves utility within policy boundaries, and avoids perpetuating the reputation of “security is a blocker”.
Island calls this “the Perfect Packet.” For every session, the most efficient and secure path is chosen based on policy. In most cases, enforcement runs locally, whether on the endpoint through Island Desktop or in the browser through DOM-level controls, and the packet goes direct. Cloud inspection is invoked only when deeper analysis or routing adds genuine value.
For a deeper dive on the concept, grab a free guide “The Perfect Packet: A Guide to Modern SASE Architecture”.
The full SASE capability set runs through a single platform. Zero Trust network access, secure web gateway, DLP, CASB, AI governance, remote browser isolation, and digital experience monitoring are all unified under one policy engine and one audit trail. There is no service chaining, no policy re-evaluation at different enforcement points, and no need to route traffic to a separate service for inspection.
On AI governance specifically, Island governs AI at the point of interaction, whether that interaction happens in a browser, a desktop application, or an agentic workflow on the endpoint.
Content-aware detection inspects prompts and uploads in real time. Data boundaries define which AI tools, tenants, and workflows are approved for organizational use. Tool calls, MCP access, and agent-to-agent communication are governed and logged, with enforcement applied locally rather than requiring a round trip to a cloud inspection point.
The result is AI access that works within policy, without block pages, without shadow AI, and without forcing a choice between productivity and protection, which is where security tends to introduce the most friction.
The deployment model matters as much as the architecture.
Island offers a phased approach that starts with an extension on existing Chrome or Edge browsers, requiring no network changes, no agent deployment, and no browser migration, but policy enforcement starts immediately.
Organizations can then move to the full enterprise browser for DOM-level enforcement, add Island Desktop for endpoint-level and agentic AI governance, and extend to the global multi-cloud network for environments that need centralized inspection, with each phase delivering standalone value from day one.
This is important because, as discussed above, the most predictable SASE failure mode is not a security breach. It is a deployment that never gets completed. An architecture that delivers value incrementally from the first day of deployment is fundamentally different from one that requires months of configuration before meaningful coverage begins.
This is a modular type of approach I wish more security vendors would take, to ensure we avoid shelf-ware and instead capitalize on security spend to truly reduce organizational risks.
The Question Practitioners Should Be Asking
There’s no question that SASE as a concept is valuable. The converged model that SASE represents, bringing networking and security together regardless of where users sit, remains the right strategic direction. However, organizations do need to ask if the execution model their current architecture depends on can actually deliver on that promise given how work happens today.
If your bypass lists are growing, if your users are finding workarounds, if your AI governance strategy amounts to allow or block at the domain level, if your deployment is still incomplete months or years after purchase, those are not operational problems to be solved with more configuration. They are architectural signals that the enforcement model needs to change.
The practitioners who will navigate this well are the ones who ask the uncomfortable questions about what their current stack is actually delivering versus what the dashboard says it is delivering. The gap between those two things is where the real risk lives but it requires us being honest about shortcomings rather than glossing over them.