Why do proxy-only SWG models struggle with modern identity-driven traffic?

Why This Matters for Security Teams

Proxy-only SWG models were built for a world where the network boundary could still observe enough context to make a reliable allow or block decision. That assumption breaks when the real control point is the identity of the user, workload, or agent, plus the action being attempted on the endpoint. Modern traffic is encrypted, brokered by desktop apps, and increasingly driven by tokens and delegated sessions rather than a simple browser request. NIST’s Cybersecurity Framework 2.0 pushes teams toward outcome-based risk management for exactly this reason.

For identity-heavy environments, the proxy often sees destination and metadata, but not the intent, local data handling, or whether a sensitive action was triggered by an NHI, a human, or an automated workflow. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which compounds the problem when network controls cannot distinguish normal from abusive use of those privileges. In practice, many security teams encounter the failure only after a token, desktop session, or API-backed app has already moved data in ways the proxy never fully saw.

How It Works in Practice

Proxy-only SWG designs tend to evaluate traffic after it has already been shaped by the client, which makes them weak against identity-driven flows. A better model combines network inspection with identity, device, and application context so authorization can happen at the moment of use. That is the practical direction reflected in 52 NHI Breaches Analysis and in standards-oriented guidance such as the NIST Cybersecurity Framework 2.0.

In modern deployments, the SWG still has value, but it should not be the only policy layer. Security teams typically need:

• Identity-aware policy that evaluates the user, workload, or service account before granting access.
• Device posture and application context, not just destination reputation.
• Short-lived credentials and session binding so stolen tokens have less reuse value.
• Telemetry from endpoints, EDR, and SaaS audit logs to detect actions hidden from the proxy.
• Policy enforcement that can distinguish browser downloads, sync clients, and agentic automation.

This matters because identity-driven traffic often uses encrypted channels, signed API calls, and delegated tokens that look harmless at the network layer but are highly privileged at the application layer. Proxy inspection alone cannot reliably tell whether a file transfer, clipboard action, or background sync was user-initiated, scripted, or triggered by an autonomous workflow. OWASP’s agentic and NHI guidance, along with CSA’s MAESTRO work, both point toward runtime authorization and workload identity as stronger primitives than static perimeter inspection. These controls tend to break down when desktop clients and embedded automation can move data outside the browser, because the proxy cannot fully observe the local action that actually matters.

Common Variations and Edge Cases

Tighter proxy enforcement often increases user friction and operational overhead, requiring organisations to balance inspection depth against latency, privacy, and application compatibility. That tradeoff is especially sharp in environments with SaaS desktop apps, developer tooling, and machine-to-machine integrations, where the network proxy may become a bottleneck without actually improving decision quality.

There is no universal standard for this yet, but current guidance suggests using proxy controls as one signal in a broader identity and workload control plane, not as the sole enforcement point. This is where NHI governance becomes operationally relevant: if credentials are long-lived, overprivileged, or embedded in tooling, the proxy will never have enough context to stop abuse in time. NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs both reinforce the practical point: identity and secret governance must move closer to the workload, while the network layer provides supporting visibility rather than final authority.

The biggest edge case is non-browser traffic that still looks like ordinary HTTPS. Sync tools, IDE plugins, agentic assistants, and service-to-service calls can all hide the true action behind an authenticated session. In those cases, proxy-only SWG models usually fail because they cannot evaluate the business intent or the local trust state at the time of request.

Related resources from NHI Mgmt Group

• Why do SASE and backhauling models struggle with modern identity governance?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents create new risk in non-human identity management?
• What is the difference between human identity governance and AI agent governance?