SASE was a genuine architectural shift. It deserved the attention it got. When workforces dispersed and applications moved to the cloud, the traditional network perimeter couldn’t hold. SASE offered something better, converged networking and security, delivered from the cloud and scaled globally. For organizations drowning in point solutions and VPN sprawl, it was a meaningful step forward.

Then came AI and it broke. 

Agentic workflows operate at machine speed, inside applications, between systems that don’t produce the kind of network signal traditional enforcement was built to interpret. Network inspection can see traffic between agents and models, but it struggles to understand the agents’ goals, intent, context, and local interactions happening inside the workflow itself.

What we kept hearing across customer evaluations, told us something more fundamental had shifted. The architecture had evolved, but the core assumption underneath it hadn't. 

These are four of the most persistent assumptions still shaping SASE today that breaks in the new AI era. 

1. SASE eliminated the perimeter

This one took the longest to surface, because the marketing around SASE was convincing. The narrative was clean. Namely, SASE replaced the old castle-and-moat model with a distributed, identity-aware architecture. No more perimeter. Enforcement everywhere.

What actually happened was more nuanced. SASE didn't dissolve the perimeter so much as relocate it from the data center edge to a set of cloud-based Points of Presence (PoPs). The enforcement boundary moved, but the boundary itself remained. Traffic still routes to a central inspection point. Policy still executes there. The model still assumes that controlling the data path controls the risk.

That assumption made sense when most enterprise traffic was linear and predictable. It is much harder to defend now. According to Gallup's Hybrid Work Indicator, 52% of remote-capable professionals work in hybrid arrangements, and another 26% work exclusively remote.

Today, work originates at the layer of intent, at the moment a user acts. According to research from Gartner, single-vendor SASE deployments are growing rapidly as organizations attempt to consolidate, yet the underlying delivery mechanic remains bound to network transit.

Consider how modern work actually behaves:

• A contractor pastes internal source code into a generative AI tool.
• An employee moves files between separate cloud tenants from a personal device.
• A third-party consultant accesses your core systems from an unmanaged laptop.

The conversation we had most often wasn't about threat detection. It was about giving contractors and third parties secure, low-latency access from anywhere without the friction of routing through a distant inspection point.

None of those interactions wait for traffic to route through a distant PoP before the risk materializes. The perimeter didn't disappear. It just stopped being useful where work actually happens.

You can govern AI agents by inspecting their traffic

This is the assumption we see breaking fastest right now. The instinct makes sense. If agents communicate with LLMs over the network, inspect that traffic. It's the same enforcement model applied to a new surface and at the wire level, it's partially true. Network inspection can see traffic between an agent and an LLM.

But partial visibility in agentic workflows isn't a minor gap. It's the gap where risk lives.

Consider what network inspection actually sees. A tool call left the agent. A response came back. The connection went to a known endpoint. What it doesn't see is which files the tool accessed, what was extracted from memory, how the output was composed, or where it traveled inside the subsequent workflow. By the time the generated content re-enters the network, the decision and the exposure already occurred. Just like users have interactions that happen locally on the device without ever leaving to go to the network, so do agents. 

What we heard from security teams wasn't a request for more inspection. It was for prompt-level visibility, MCP flow auditing, agentic tool management, and AI monitoring and control, because those workflows were already happening and nobody could see them.

Deployment compounds the problem. Routing all agent-to-LLM traffic through a network inspection layer requires that traffic to be consistently identifiable and interceptable across a rapidly diversifying stack: different AI models, frameworks, orchestration layers, and MCP-connected tools. As AI architectures proliferate and evolve, that assumption gets harder to sustain operationally.

There's also a more fundamental issue. A significant portion of agentic activity doesn't look like network traffic at all. In-context reasoning, local tool execution, and application-layer interactions all happen inside the application environment before anything hits the wire. Inspection at the network layer simply isn't present for the actions that matter most.

What's needed instead is enforcement that operates at both layers simultaneously: in the network and at the point of interaction, where the agent session begins, where tool calls are initiated, and where output is consumed. That's the vantage point where AI governance becomes practical rather than aspirational.

Governing AI requires enforcement at the layer where those interactions actually happen, not just where their traffic eventually surfaces.

More inspection means more visibility

This one runs deep, because it's intuitive. If you can see the traffic, you can govern the behavior. Inspect more, know more. It's a reasonable assumption for a network-centric world, but a highly flawed one for an AI-application-centric reality.

The problem is that the most critical context in modern work isn't hidden in the network packet; it’s in the interaction.

Network inspection tells you that a session successfully connected to a known AI service. It might tell you the size of the payload. What it cannot reliably tell you is what was pasted into that prompt, which internal document it referenced, what the output contained, or where that output traveled next. The "moment of intent" lives inside the application,  at the presentation layer, before the packet is formed.

The same is true for SaaS behavior more broadly. A file upload looks identical whether it's a sanctioned workflow or a data exfiltration event, unless you have visibility into the application context that generated it. Network flows don't carry that signal. They carry destinations, volumes, and connection metadata.

What organizations actually need, and are asking for, is the ability to allow a user to view a file in Salesforce but block the download, or permit an upload to a corporate Google Drive instance while blocking the same action to a personal one in the same session. Those aren't edge cases. They're the enforcement requirements that matter most, and they're also invisible at the network layer.

As encryption strengthens toward post-quantum implementations, this gap compounds. According to IETF guidance, transitioning to quantum-safe cryptography introduces significantly larger cryptographic keys and signature artifacts, placing greater strain on traditional inspection pathways. When you factor in certificate pinning and mutual TLS (mTLS), the network proxy model forces administrators into a defensive crouch: maintaining extensive bypass lists. Bypass lists grow. Blind spots expand. Teams spend cycles managing exclusions rather than improving coverage.

Applying more inspection at the wrong layer doesn't close that gap. It just adds overhead.

SASE unified security

The promise of unification was real, and for many organizations, it was the primary reason to adopt SASE. Collapse the point solution sprawl and consolidate SWG, CASB, ZTNA, and SD-WAN into a single architecture with a single policy framework. But what most found in practice was something more limited - unified delivery, not unified enforcement.

The traffic routes through one vendor's cloud infrastructure. The console is shared. But enforcement, the actual moment where policy meets behavior, is still fragmented across service chains, evaluated at different points, and often re-evaluated redundantly as sessions traverse multiple inspection layers.

The policy defined in the SWG may not reflect what the CASB enforces. The ZTNA posture check at login doesn't continuously govern what happens inside the session. Context gathered at one enforcement point doesn't automatically inform decisions at another. IT teams end up managing policy across overlapping engines, troubleshooting conflicts between layers, and explaining to users why sanctioned applications run slower than personal ones.

The requirement that surfaces in almost every serious evaluation is deceptively simple: one place to define and enforce policy, with logs that include identity, device, location, and application context, not just traffic metadata. The gap between that requirement and what most architectures deliver is where operational complexity compounds.

As organizations look to frameworks like the NIST Zero Trust Architecture (SP 800-207), the core tenet is explicit: security must be applied as close to the resource and the relationship as possible, continuously. When enforcement is distributed across sequential network proxy layers rather than unified at the immediate point of work, continuous session governance becomes aspirational, not operational.

This isn't a case of vendors failing to execute. It's a structural limitation: traditional SASE backhauling routes traffic through separate security components sequentially, so context doesn't carry between them.

When security is split across multiple layers in a cloud data path, true policy consistency remains a checkbox on a dashboard, not a reality for the IT team. Without a single, unified point of enforcement where the work is actually happening, security teams are left managing a jigsaw puzzle of policies while critical context slips through the gaps.

Unifying delivery is a meaningful step. Unifying enforcement is the harder problem and the more consequential one.

Where this points

None of this means SASE was a wrong turn. It was the right architecture for its moment, and the network and cloud layers it built remain foundational.

But the assumptions that the perimeter just needed to move, that delivery unification equals enforcement unification, that inspection volume equals visibility, and that inspecting agent traffic is enough to govern AI are misguided. Those assumptions were formed for a different era of work. Before AI embedded itself into daily workflows. Before contractors and unmanaged devices became the norm. Before the interaction layer became where enterprise risk actually originates.

The organizations I speak to aren't asking how to inspect more traffic faster. They're asking where enforcement needs to live in order to see and govern work as it actually happens.

That's a different question. And it points toward a different architecture. One that treats the point of work as the first surface for policy execution, not the last stop traffic passes through on its way to a distant inspection point.

The perimeter assumption had a good run. Modern work has moved on.

If you're asking what that architecture looks like in practice, The Perfect Packet: A Guide to Modern SASE Architecture is a good place to start. Download →