TL;DR: Traditional cloud-proxy SWG models fail when AI assistants, autonomous workflows, and encrypted application traffic dominate outbound activity, according to Island, while its endpoint-enforced architecture claims 90% of sessions skip cloud backhaul and 100% visibility into AI sessions and agent workflows. The governance shift is real: identity, data, and session control now have to move closer to the endpoint, where policy can still see the action.
At a glance
What this is: Island argues that SWG control needs to move from cloud backhaul to the endpoint because modern outbound activity now includes AI sessions, agent workflows, and encrypted traffic the network proxy cannot fully inspect.
Why it matters: This matters because IAM, NHI, and security teams need enforcement points that can see and govern the session, the data action, and the identity context together, rather than assuming the network layer will provide enough control.
By the numbers:
- Agents are about to outnumber humans 100 to 1 in the enterprise.
- 90% of sessions skip the cloud backhaul.
- 100% visibility into AI sessions, agent workflows, and data interactions.
Context
Secure Web Gateway control has historically assumed that outbound activity is a human browsing problem that can be enforced by sending traffic through a cloud proxy. That assumption no longer fits environments where AI prompts, background processes, SaaS clients, browser extensions, and autonomous workflows all generate outbound sessions with different data and identity risks.
For identity and access teams, the important shift is not just where traffic is inspected but what kind of actor is generating it. When the actor is an AI assistant or machine-driven workflow, the relevant control plane becomes session-aware enforcement on the endpoint, because the network layer often loses the context needed to govern data movement and application access.
Island frames this as an architecture problem, but the governance problem is broader: enterprises need policy that can follow the action from the device into the application, rather than relying on a proxy to reconstruct intent after the fact. That is especially relevant where encrypted sessions, delegated workflows, and shadow AI activity reduce the value of network-only inspection.
Key questions
Q: Where does traditional SWG fail when AI sessions and desktop apps generate outbound traffic?
A: Traditional SWG fails when the meaningful risk sits inside the session rather than on the wire. AI prompts, desktop clients, and background processes often create encrypted or parallel traffic that a cloud proxy cannot fully interpret, so policy decisions arrive after the action has already started or finished.
Q: Why do encrypted application sessions weaken proxy-based inspection?
A: Encrypted sessions reduce what the proxy can inspect, especially when apps use modern protocols, SSL pinning, or traffic patterns that resist break-and-inspect. The result is not just less visibility, but weaker policy confidence, because the gateway sees transport data without enough behavioural context to govern the request.
Q: How should security teams govern AI assistants that can access files and APIs?
A: Treat each assistant as a non-human identity with explicit owners, least privilege, and a documented lifecycle. Then review every file, API, and memory path it can reach. If a capability is not required for the business task, remove it. Governance only works when the assistant’s identity boundary is narrower than the data it can touch.
Q: What is the difference between cloud backhaul SWG and endpoint enforcement?
A: Cloud backhaul SWG centralises inspection after traffic leaves the device, while endpoint enforcement applies policy locally before or as the action occurs. The difference matters because endpoint control can see browser actions, desktop clients, and AI workflows that never become fully meaningful in the network layer.
Technical breakdown
Why cloud-proxy SWG loses context in AI-heavy traffic
Traditional SWG design centralises inspection by sending outbound traffic to a cloud proxy for decryption, categorisation, and policy enforcement. That model works best when the session is a discrete browser request, but it degrades when the traffic is generated by SaaS clients, AI assistants, background services, or browser extensions that create parallel connections and encrypted interactions. Once the request is opaque or the meaningful risk lives inside the page, the proxy sees transport metadata without enough behavioural context to govern the action. Endpoint enforcement changes the control point, not the policy goal. It places inspection closer to the user and the session so that identity, destination, and data handling can be evaluated before traffic leaves the device.
Practical implication: map which traffic types lose policy context at the proxy and require endpoint-level enforcement instead.
How endpoint-enforced DLP changes web and application control
Endpoint-enforced SWG applies URL filtering, data loss prevention, malware scanning, and application access controls locally, then sends the policy decision consistently through the same management plane. The technical distinction is that policy execution happens at the DOM or local process layer for browser-originated activity and at the intercepted connection layer for non-browser traffic. That means a copy, paste, upload, or application call can be stopped before it becomes a network event. This matters for NHI governance too, because an AI assistant or autonomous process can trigger the same outbound controls as a human user, but with much less tolerance for delayed inspection or post hoc analysis.
Practical implication: extend DLP and application control to endpoint-originated actions, not just traffic in transit.
What unified logging changes for identity and incident reconstruction
A single policy framework with one audit log collapses the common split between browser telemetry, desktop application traffic, and security operations reporting. Instead of reconciling separate logs from different enforcement points, teams get the user identity, destination, action, and outcome in one stream. That improves incident reconstruction, but it also changes governance expectations: if access, data movement, and inspection are all policy decisions, then accountability must be traceable at the same granularity. For AI sessions and agent workflows, the logging model is especially important because an agent can create many small actions quickly; without a unified record, review and response become incomplete by design.
Practical implication: require a single audit trail that can tie endpoint actions to identity, destination, and policy outcome.
NHI Mgmt Group analysis
Cloud-proxy SWG is now a partial control, not a complete control. The traditional model assumes outbound risk can be governed after traffic reaches a central inspection point. That assumption breaks when the session is encrypted, generated by an AI assistant, or carried by a desktop client that never yields full browser-style context. The practical conclusion is that web governance now needs an endpoint-enforced control plane, not just a network checkpoint.
Session visibility has become an identity problem, not only a network problem. If a system cannot see whether a request came from a human, an AI assistant, or a background workflow, it cannot apply meaningful policy consistently. This is where SWG, DLP, and access control converge with NHI governance: the actor type affects how much context exists at enforcement time. The implication is that identity-aware policy must travel with the session.
AI session governance creates a new enforcement category: policy before egress. The article’s strongest operational point is that many risky actions now happen on the device before they ever become inspectable network traffic. That forces security teams to think about control placement differently, because the old assumption that inspection can wait until the proxy sees the request no longer holds. The implication is a shift from backhaul-centric control to last-mile governance.
Endpoint enforcement is the right architecture for the identity blast radius created by modern outbound activity. When a single user session can fan out into browser actions, SaaS API calls, file sync, and AI prompts, the blast radius is not only about exfiltration volume. It is also about how fast policy can be applied before the action completes. Practitioners should treat endpoint inspection as a containment layer for both human and machine-driven sessions.
AI session visibility should be treated as a governance requirement, not a telemetry enhancement. The article’s premise is that if you cannot see inside an AI session, you are not governing AI. That is a stronger statement than logging or monitoring because it ties observability to enforceability. The implication for practitioners is that SWG strategy, NHI policy, and data protection controls now need to be designed together, not stitched together later.
What this signals
Identity-aware enforcement is becoming the default requirement for outbound control. Security teams should expect more sessions to originate from software actors, not just people, and those sessions will increasingly carry the only context that matters at the device layer. That makes endpoint policy a governance issue, not just a technical routing choice.
Policy has to follow the action, not the traffic class. A control model built around browsers alone will miss the growing share of work done through desktop apps, AI prompts, and background services. The practical response is to unify inspection, DLP, and access decisions at the endpoint where the session is still observable.
AI session governance is now part of web security architecture. The organisations that will struggle most are the ones treating SWG as a static network function rather than a dynamic identity and data control point. The next architecture decision is whether policy is defined around packets, or around the actor making the request.
For practitioners
- Define which outbound sessions need endpoint enforcement Classify browser traffic, desktop application traffic, AI assistant sessions, and background services by the point where policy can still see the action. Use that classification to decide where proxy inspection ends and local enforcement begins.
- Extend DLP to device-originated data actions Apply the same DLP policy to copy, paste, uploads, and application calls that occur on the device, not only to traffic that traverses the network. This is the only way to catch data movement that never leaves the endpoint in an inspectable form.
Key takeaways
- Traditional proxy SWG assumptions are weakening because outbound activity increasingly comes from AI sessions, desktop applications, and encrypted workflows that the network layer cannot fully interpret.
- The article’s core evidence is operational, not theoretical: endpoint enforcement is positioned to cover sessions, data actions, and application control that cloud backhaul leaves partially visible.
- Practitioners should redesign SWG policy so that inspection, DLP, and access decisions can occur at the endpoint before the action becomes an ungovernable network event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | AI sessions and delegated workflows blur who or what is acting through the endpoint. |
| NHI-06 — Insecure Cloud Deployment Configurations | The article contrasts cloud proxy dependence with local endpoint enforcement. | |
| Recommendation — Treat software-driven outbound actions as governed NHI activity when policy must see the actor, not only the packet. Reduce reliance on cloud-only inspection paths when the deployment model leaves traffic partially invisible. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-Rest and Data-in-Transit Protections | The article centres on controlling data movement across encrypted outbound sessions. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Endpoint policy decides which identity can reach which destination and action. | |
| Recommendation — Align DLP and inspection controls to protect data in transit at the point of egress. Tie outbound application access to identity-aware authorization decisions at the device layer. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article discusses blocking C2 callbacks and preventing data leaving the device. |
| Recommendation — Map outbound control and DLP rules to credential theft and exfiltration pathways in detection logic. | ||
Key terms
- Secure Web Gateway: A Secure Web Gateway is a control point for outbound web and application traffic that enforces policy, blocks threats, and reduces data leakage. In modern environments, the key question is not only what leaves the network, but where the decision to allow or block is made and how much session context is visible.
- Endpoint enforcement: Endpoint enforcement is the use of device-layer controls such as MFA, encryption, policy restrictions, and remote access rules to shape how a device can connect and operate. It is a control layer, not a full identity governance model, because it does not on its own manage entitlements or revocation.
- Backhaul: Backhaul is the practice of routing traffic to a distant inspection or aggregation point before sending it onward to the final destination. It can simplify centralised control, but it often adds latency, routing variability, and avoidable exposure to congestion or regional failure.
- AI Session Visibility: AI session visibility is the ability to observe prompts, tool calls, and data interactions generated by an AI assistant or workflow. It matters because governance fails when teams can see only network packets but not the actions, inputs, and outputs that define the session’s real risk.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org