Browser-level access control and SSE rework for AI-driven enterprise

At a glance

What this is: Seraphic describes a browser-level SSE model integrated with Akamai ZTNA and EAA that shifts enforcement into the browser while extending access control across apps and AI tools.

Why it matters: This matters because IAM and security teams now have to govern session context, data handling, and AI-tool behaviour at the browser layer, not rely only on perimeter or proxy controls.

Context

The security gap here is not a lack of policy, but a mismatch between where work now happens and where legacy controls still operate. Browsers have become the practical control plane for SaaS, private applications, and AI tools, yet many SSE stacks still assume network-centric enforcement and heavyweight inspection paths.

That mismatch creates governance blind spots for identity and access teams because the browser session increasingly determines what data is exposed, what tools are reachable, and how prompts or uploads behave. In that sense, browser-level control is not just a UX change; it is a shift in where access decisions and data handling decisions are made.

Key questions

Q: How should teams govern browser-level access when ZTNA and SSE are combined?

A: Treat the browser as a policy enforcement point rather than a passive client. Define which decisions belong to identity, which belong to application reachability, and which must be enforced at session time so policy is not split across competing layers.

Q: Why does browser-based AI use increase third-party risk?

A: Because the browser is where users authenticate, consent, and connect services, so unmanaged AI adoption creates access paths before governance can review them. The result is not just more tools, but more untracked tenant access, token scope, and data sharing.

Q: What breaks when SSE relies too heavily on proxy inspection?

A: Visibility becomes slower, more complex, and less aligned to the actual user session. That can leave unmanaged browsers, AI interactions, and hybrid access flows outside the control plane even when the network edge looks covered.

Q: When should organisations re-evaluate their browser security architecture?

A: Re-evaluate it when users work across SaaS, private apps, and AI tools from many devices, because that is when browser context becomes central to both access control and data protection. If the browser is where work happens, the policy model must follow.

Technical breakdown

Why browser-level enforcement changes the control plane

A browser-level control model moves enforcement closer to the user session, where authentication context, application reachability, and content handling converge. Instead of relying primarily on proxies, TLS interception, or endpoint agents, policy can be applied at the point where web requests, file transfers, and prompt interactions originate. That matters in environments where employees use unmanaged browsers, shadow IT paths, or AI tools outside traditional inspection layers. The architectural implication is that the browser becomes a policy enforcement point, not just a rendering client.

Practical implication: treat the browser session as part of the access architecture and define what must be enforced there versus in network controls.

How ZTNA and SSE fit together in hybrid access

ZTNA governs access to private applications by continuously verifying identity and context, while SSE historically concentrated on web security, DLP, and cloud access controls. The combination described here is aimed at reducing overlap between those layers by using one policy model across browsing, SaaS, and application access. For IAM teams, the important distinction is that ZTNA answers who can reach the app, but browser-level SSE can also shape what happens after the session starts. That includes finer-grained control over content, destinations, and risky interactions.

Practical implication: align identity policy, application reachability, and browser controls so they do not drift into separate governance silos.

AI tool access introduces a new governance surface

AI tools create a distinct access problem because the risky action is often not login itself but what the user enters, uploads, or delegates once inside the tool. Prompt injection, accidental disclosure, and malicious tool use are session behaviours, not just authentication events. Traditional SSE designs often struggle here because they see the network path but not enough browser context to judge intent or unsafe sharing. Browser-aware control can therefore support policy decisions about prompts, content movement, and interaction with third-party AI services.

Practical implication: extend access policy to AI session behaviour, especially prompt handling, uploads, and third-party data exposure.

Threat narrative

Attacker objective: The objective is to exploit browser-visible gaps so sensitive data or unsafe actions can be triggered through legitimate sessions.

1. Entry occurs through unmanaged browsers, cloud apps, or AI tools that sit outside traditional proxy-heavy inspection paths.
2. Credentialed access is then used inside the browser session to reach private applications and third-party services with limited contextual visibility.
3. Escalation happens when prompt injection, data leakage, or malicious tool use turns ordinary browser interaction into unauthorized disclosure or unsafe actions.
4. Impact is loss of sensitive data, weaker policy enforcement, and a larger attack surface across SaaS and AI workflows.

Breaches seen in the wild

• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser governance is becoming the practical control boundary for modern enterprise access. When employees reach private apps, SaaS platforms, and AI tools from many devices, the browser holds the most actionable session context. Network-only models miss too much of the decision surface, so the control point has to move closer to where data is entered, moved, and disclosed. Practitioners should treat browser-level policy as a governance layer, not a tactical add-on.

AI-aware SSE is really identity-aware session governance. The new risk is not just access to an application, but what a user does once inside an AI tool. Prompt injection, accidental disclosure, and malicious tool use all depend on session behaviour that traditional access controls do not fully observe. The field should stop framing this as browser security alone and recognise it as a convergence of IAM, DLP, and session control.

Proxy-heavy inspection is becoming a control debt problem. Complex stacks can preserve visibility in theory while degrading user experience, operational clarity, and policy consistency in practice. Browser-level enforcement reduces that debt by placing policy where the interaction occurs. The practitioner takeaway is to evaluate whether existing SSE architecture can actually govern the browser session, or merely observe it after the fact.

Session context is now the missing identity primitive. Zero trust assumes continuous evaluation, but that assumption breaks down when the browser session is the only place where intent, content movement, and AI-tool behaviour can be seen together. Browser-aware controls restore some of that lost context. Teams should make session context part of their identity governance model.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
• Read next: Zero Trust Identity Guide

What this signals

Browser-level policy creates a more realistic zero-trust enforcement point for hybrid work. When applications and AI tools are consumed through the browser, access governance has to look at the session as the unit of control rather than the perimeter. That changes how teams think about identity context, data handling, and acceptable use in one move.

Unmanaged browsers are the control gap that most SSE programmes still under-estimate. If users can reach SaaS or AI tools outside governed browser paths, the policy model is already fragmented. Teams should map where browser-level enforcement is missing before they assume ZTNA coverage is complete.

Browser session context is now a named governance concept for IAM teams. It captures the idea that the user’s active browser state, not just the authenticated identity, determines what policy can actually enforce. That makes browser context a practical design input for zero trust, DLP, and AI governance.

For practitioners

• Map browser-level policy to the access lifecycle Define which decisions must be enforced in the browser, which belong in ZTNA, and which remain in downstream DLP or app controls.
• Inventory unmanaged browser paths Identify users, devices, and workflows that bypass proxy-heavy inspection so policy gaps are visible before migration decisions are made.
• Extend governance to AI-tool interactions Set controls for prompts, uploads, and third-party data sharing so AI use is covered by the same policy framework as SaaS access.
• Rationalise overlapping SSE components Review proxy, TLS interception, endpoint agent, and URL rewriting dependencies to determine where browser enforcement can safely replace them.

Key takeaways

• Browser-level SSE shifts enforcement closer to the session, which is where modern access and data-handling decisions are actually made.
• The main governance gap is not authentication alone, but the lack of context around prompts, uploads, and browser behaviour inside AI tools.
• Teams should re-evaluate whether proxy-heavy SSE architectures can still govern unmanaged browsers and mixed SaaS, private app, and AI workflows.

Key terms

• Browser-Based Access Control Bypass: Browser-based access control bypass occurs when a web page reaches a local or internal service by abusing assumptions in origin checks or host validation. Techniques such as DNS rebinding can defeat protections that rely only on browser same-origin logic. The risk is highest when unauthenticated services are reachable from the host network.
• Session context: The surrounding authentication and access conditions attached to a login, such as MFA status, device trust, IP reputation, and prior behaviour. It matters because identity risk is rarely decided by one event alone; context shows whether the event fits the account’s normal pattern.
• Zero Trust Network: A Zero Trust Network is a network security approach that does not trust users, devices, or traffic by default. Every connection is continuously verified using identity, device posture, context, and policy before access is granted. It assumes breach, limits lateral movement, and treats network access as conditional rather than implicit.
• Secure Enterprise Browser: A secure enterprise browser is a browser control model that applies security policy, monitoring, and enforcement inside the browser experience. It aims to observe and govern session behaviour directly, which makes it relevant for phishing resistance, data loss prevention, and AI use oversight.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for teams that need to connect identity governance to browser-mediated access and AI-era control design.