By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: IslandPublished August 20, 2026

TL;DR: Legacy SASE is failing in five ways because network enforcement cannot see browser-level intent, unmanaged devices, or shadow AI interactions, according to Island. The practical issue is not proxy tuning but shifting controls to the endpoint and browser, where modern work now happens.


At a glance

What this is: This is an analysis of why legacy SASE is breaking down as work moves into browsers, SaaS, unmanaged devices, and AI tools.

Why it matters: It matters because identity, device posture, and user intent are now being enforced at points where network-centric controls have limited visibility, which changes how IAM-adjacent access and data controls should be designed.

By the numbers:

  • Island routinely finds secure web gateway deployments are blind to 60 to 70 percent of all traffic when they cannot decrypt it.

👉 Read Island's analysis of why legacy SASE is failing in the browser era


Context

Legacy SASE was built to control network traffic, but modern work now happens in browsers, SaaS applications, unmanaged devices, and AI tools. That creates a governance gap because packet inspection and backhauling can observe transport, but not user intent, file interaction, or browser-mediated data movement.

The identity angle is real even though this is not an IAM article. Browser sessions still depend on authenticated users, device posture signals, and policy enforcement boundaries, so when control shifts away from the network, access governance and data protection have to move closer to the point of interaction. That pattern is typical in modern enterprise environments, not an edge case.


Key questions

Q: How should security teams govern browser-based policy enforcement for identity and data risk?

A: Start by classifying which decisions belong at session time rather than at login, then assign ownership across identity, endpoint, data, and SOC teams. The browser should enforce only policy that is clearly defined, logged, and reversible. That prevents the browser from becoming an opaque shadow control plane.

Q: Why do unmanaged devices complicate zero trust access decisions?

A: Because zero trust depends on continuous verification, and unmanaged devices weaken the confidence you can place in the session context. If the device cannot be assessed or controlled, identity alone is not enough to justify broad access. Teams need posture-aware policy, not just stronger authentication.

Q: What do security teams get wrong about Shadow AI?

A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem. The hidden risk can be an undocumented token, an over-permissioned service account, or an autonomous agent with unreviewed reach. Inventory the identity layer before you decide the tool is the issue.

Q: Who is accountable when browser controls fail to prevent data exposure?

A: Accountability sits with the teams that own identity, endpoint, browser policy, and data protection together, not with the sandbox alone. In practice, browser governance spans security architecture, compliance, and access teams because the browser now mediates regulated access and data movement.


Technical breakdown

Why network proxies lose visibility in browser-based work

Traditional SASE inspects packets in transit, usually through backhauling and SSL break-and-inspect. That works only when the security layer can see and reassemble the session with enough fidelity to apply policy. Modern browsers, however, increasingly resist interception through TLS 1.3, SSL pinning, and QUIC, which reduces how much traffic can be decrypted and inspected reliably. The result is not just latency, but structural loss of context. A proxy can see a connection, yet still miss the file, the action, or the intent behind it.

Practical implication: Treat browser-level work as a control-plane problem, not a packet-inspection problem.

How shadow AI changes the enforcement model

Shadow AI is difficult for network tools because the risky act often happens inside the browser when a user uploads a file or sends context into an AI application. A proxy may see encrypted traffic or a websocket, but it often cannot determine what data was selected, whether it was sensitive, or what the model returned. Browser-side enforcement changes that by observing the interaction before data leaves the endpoint. This is especially important where AI use is unsanctioned or loosely governed, because the security decision must happen at the moment of intent, not after the packet is already in transit.

Practical implication: Place policy at upload, paste, and submit actions instead of relying on network-only controls.

Why unmanaged devices weaken zero trust assumptions

Zero Trust depends on continuous verification of user, device, and context, but unmanaged endpoints complicate the control stack because you cannot always deploy the same agent, inspection layer, or conditional access tooling. That creates a split between corporate devices, BYOD, and third-party managed endpoints. In practice, organisations end up choosing between blocking work, allowing visibility gaps, or layering brittle exceptions. The architectural issue is not authentication alone, but where enforcement lives when the device is outside IT control.

Practical implication: Design for policy consistency across managed and unmanaged endpoints, not for perfect device ownership.


NHI Mgmt Group analysis

Browser enforcement is becoming a governance boundary, not just a deployment preference. When the work surface moves into the browser, the old assumption that network controls can see enough of the transaction stops holding. That shifts the centre of gravity from perimeter inspection toward interaction-aware policy. For identity and access teams, this means conditional access, device trust, and data controls must be evaluated against the browser session itself, not just the network path. The practitioner conclusion is clear: governance that ignores the browser will keep missing the real control point.

Shadow AI creates a browser-native data loss problem. The risk is not simply that users adopt unsanctioned AI tools, but that sensitive content can be uploaded through a session that looks ordinary at the network layer. This is where the identity bridge matters: authenticated users on trusted accounts can still leak data through browser interactions that SASE cannot interpret well. The right question is whether the policy engine can see file selection, paste actions, and response handling. Practitioners should treat AI usage as an access and data governance issue, not only as an application allow-listing problem.

Zero Trust on unmanaged devices needs a different enforcement plane. Device trust controls lose consistency when endpoint agents cannot be installed or enforced uniformly. That creates a gap between policy intent and operational reality, especially for contractors and BYOD users. A browser-level control plane can narrow that gap, but only if it preserves the same policy logic across devices instead of building a separate exception path. The lesson for IAM and security architects is to test where enforcement actually terminates. If it ends at the network, the zero-trust claim is weaker than the architecture diagram suggests.

Perfect packet is a useful named concept because it describes compliance at origin, not inspection in transit. The article’s core claim is that policy should already be applied before traffic becomes a packet on the wire. That framing is valuable because it captures a broader shift in enterprise control architecture: from observing transport to governing interaction. In practice, it aligns with browser-mediated identity and access decisions far more than legacy proxy logic does. The conclusion is that modern control design must move upstream to the point of user action.

Legacy SASE is accumulating control debt as environments fragment. The article shows that organisations often still need VPN, VDI, DLP, endpoint controls, and secure web gateways even after adopting SASE. That is a sign the original convergence model is not covering the full use case set. For practitioners, the signal is to reassess whether their current stack is reducing control complexity or simply redistributing it across more exceptions. The governance question is no longer whether SASE exists, but whether it still matches where work happens.

What this signals

The operational signal here is that enforcement is shifting from transport to interaction, which means security teams need to measure where policy actually terminates inside the browser session. If the control only sees packets, then browser-mediated access, file movement, and AI use will continue to outpace it. For identity and access programmes, that means reassessing whether conditional access and data controls are applied early enough in the workflow to matter.

Browser control-plane drift: this is the gap that appears when governance assumes the network can still observe intent. Once that assumption fails, organisations need clearer ownership across IAM, endpoint, and data security teams. The most practical next step is to align browser enforcement with the same access lifecycle logic used for privileged and high-risk identities, rather than treating it as a separate tooling decision.


For practitioners

  • Map enforcement to browser actions Identify where users upload, paste, approve, and submit data inside browser sessions, then decide which of those events require inline policy enforcement before traffic leaves the endpoint.
  • Test unmanaged-device access paths Review how contractors and BYOD users reach SaaS, private apps, and AI tools without relying on a permanently installed endpoint agent or fragile exceptions.
  • Separate transport visibility from intent visibility Document which controls only inspect packets and which can see the selected file, browser context, or user action, then close the gap for high-risk workflows.
  • Treat shadow AI as a policy problem Define controls for unsanctioned AI use at the point of interaction, including file upload, prompt entry, and response handling, rather than depending solely on app blocking.
  • Re-evaluate zero trust control placement Check whether your current zero trust model depends on network steering or can enforce identity, posture, and data policy on devices you do not manage.

Key takeaways

  • Legacy SASE is failing because network-centric enforcement cannot reliably see browser-native intent, unmanaged endpoints, or shadow AI interactions.
  • The evidence points to structural blind spots and control fragmentation, not a tuning problem in the proxy layer.
  • Practitioners should move policy closer to the browser session and re-evaluate how identity, device posture, and data controls are enforced.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-3Browser-based enforcement affects how access permissions and conditions are evaluated.
NIST SP 800-53 Rev 5AC-6Least privilege is strained when access decisions move away from network inspection.
NIST Zero Trust (SP 800-207)The article challenges assumptions about continuous verification on unmanaged devices.
CIS Controls v8CIS-6 , Access Control ManagementAccess control management is directly implicated when browser sessions bypass network controls.

Review browser-facing access paths under CIS-6 and close policy gaps on BYOD and contractor devices.


Key terms

  • Browser Enforcement: Browser enforcement is policy execution inside the browser or closely adjacent endpoint layer where the user interaction occurs. It is relevant when employees use AI tools through web interfaces, because sensitive text can be copied, pasted, or generated without ever passing through traditional network controls.
  • Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
  • Perfect packet: Perfect packet is a browser-first control concept where policy is applied before data becomes a packet on the wire. The idea is that traffic is already compliant at origin, so it can travel without the inspection, decryption, and detours that legacy network security often requires.
  • Unmanaged Endpoint: A device that the organisation does not fully administer, monitor, or harden under its standard endpoint controls. In practice, this includes personal laptops and shared computers used for corporate access, where local storage, browser state, and device posture may not meet enterprise trust requirements.

What's in the full article

Island's full article covers the operational detail this post intentionally leaves for the source:

  • How the browser-side policy model maps to SaaS, private apps, and desktop traffic in practice
  • The article's explanation of SSL inspection failure modes across TLS 1.3, QUIC, and SSL pinning
  • Specific examples of how unmanaged devices and BYOD change enforcement decisions
  • A fuller walkthrough of how shadow AI is handled at the point of interaction

👉 Island's full post covers the five failure modes, browser enforcement model, and modern work assumptions in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and identity practitioners apply lifecycle thinking to modern access and control problems.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 21, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org