Why do proxy based SASE architectures struggle with modern encryption and agentic AI use cases?

Why This Matters for Security Teams

Proxy based SASE was built for a traffic model where content inspection at a central chokepoint could still reveal useful security signals. That assumption weakens when encryption is pervasive and protocols are designed to reduce intermediaries’ visibility. TLS 1.3, QUIC, HTTP/2, and HTTP/3 all narrow what a proxy can reliably decrypt, normalize, or classify. For security teams, the issue is not only blind spots, but also the operational pressure to add exceptions, weaken inspection, or create brittle policy overlays.

The challenge becomes sharper with agentic ai because a model-backed workflow may issue tool calls, API requests, or chained actions that look legitimate at the transport layer but are risky at the task layer. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the need for governance, observability, and validation beyond packet inspection. In practice, proxy based SASE often looks effective in slide decks but fails once encrypted applications, embedded assistants, and autonomous workflows become the normal operating environment.

In practice, many security teams encounter the visibility gap only after encryption exceptions and agentic workflows have already been granted to keep business processes moving.

How It Works in Practice

Proxy based SASE typically depends on TLS interception, application identification, and policy enforcement at a centralized inspection point. That approach can still work for conventional web browsing, but modern traffic patterns reduce its fidelity. QUIC encrypts more of the transport path, HTTP/2 multiplexes streams in ways that complicate session reconstruction, and TLS 1.3 reduces the number of useful handshake details available for classification. As a result, the proxy may know that encrypted traffic exists, but not enough about the content, intent, or downstream action to make a strong decision.

Agentic AI creates a separate problem. A tool-using agent may call APIs, search internal documents, trigger automations, or invoke SaaS services in ways that are operationally valid yet security relevant. Those actions can be authenticated and encrypted, but still represent prompt injection, data exfiltration, or unauthorized task execution. That is why AI security guidance increasingly emphasizes behavior, provenance, and policy controls, not just transport inspection. The MITRE ATLAS adversarial AI threat matrix is useful here because it frames AI abuse as an attack surface with distinct tactics, not as a generic network issue.

• Inspect where possible, but assume some encrypted sessions will remain partially opaque.
• Classify applications by business risk and AI function, not only by destination or port.
• Validate tool permissions, API scopes, and workload identity before allowing agent actions.
• Log prompts, tool calls, and outputs at the application layer so security teams can correlate intent with activity.
• Use content controls, data loss prevention, and identity policy together instead of relying on a single proxy decision.

This is why many architectures shift from trying to fully decrypt everything toward layered controls across identity, application governance, and telemetry. The CSA MAESTRO agentic AI threat modeling framework reinforces that agent behavior should be modeled as a system of identities, tools, and permissions. These controls tend to break down when the environment mixes unmanaged devices, zero trust bypasses, and high-volume machine-to-machine API traffic because the proxy cannot reliably distinguish benign automation from malicious orchestration.

Common Variations and Edge Cases

Tighter proxy inspection often increases latency, operational friction, and privacy concerns, requiring organisations to balance visibility against application compatibility and user trust. That tradeoff becomes especially pronounced in regulated environments, developer platforms, and AI-heavy workflows where encrypted service-to-service calls are normal.

There is no universal standard for handling every agentic AI session through a proxy, and current guidance suggests that security teams should treat the proxy as one control layer rather than the control layer. For chat-based interfaces, limited inspection may still help with web risk filtering. For autonomous agents, the higher-value control is often identity-bound authorization: restricting tool scopes, binding actions to workload identity, and validating outputs before execution. The NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026 both support this layered view.

Another edge case is security monitoring for AI-assisted attacks. The Anthropic report on the first AI-orchestrated cyber espionage campaign is a reminder that autonomous tooling can compress attack steps and reduce obvious network signatures. That means proxy based SASE may still be useful for coarse policy, but it is no longer sufficient for high-confidence detection or prevention in encrypted, agentic environments.

Related resources from NHI Mgmt Group

• Why do role-based controls struggle with agentic AI?
• Why does agentic AI create a greater governance gap than earlier AI use cases in financial services?
• Why do regulated organisations struggle to use cloud-based AI security testing?
• What NHI types do Agentic AI systems typically use?