By NHI Mgmt Group Editorial TeamPublished 2026-05-09Domain: Agentic AI & NHIsSource: WitnessAI

TL;DR: AI security platforms differ sharply in what they can monitor and enforce across browser tools, native apps, SASE paths, and autonomous agent workflows, and no single architecture covers every hybrid scenario, according to WitnessAI. The central issue is coverage mismatch: deployment model, not feature count, determines where AI governance succeeds or fails.


At a glance

What this is: This is an analysis of six AI security platform deployment models, with the key finding that architecture determines where governance works and where it goes blind.

Why it matters: It matters because IAM, NHI, and AI governance teams need coverage that follows users, devices, and agents across managed and unmanaged environments.

By the numbers:

👉 Read WitnessAI's comparison of AI security platforms for hybrid workplaces


Context

AI security in hybrid work fails when teams assume the browser is the boundary. In practice, employees move between managed laptops, personal devices, native desktop apps, mobile assistants, and agent workflows, so any control that only sees one layer will miss part of the interaction path.

For identity and access teams, the question is not whether AI usage exists, but which identity surfaces it passes through and which controls can still enforce policy when the user leaves the corporate network. That makes deployment architecture an identity governance decision, not just a security tooling choice.

The article is typical of the current market: every platform claims coverage, but each one is constrained by where it sits in the stack. The governance gap is the mismatch between workforce reality and control-plane visibility.


Key questions

Q: How should security teams choose between browser-based and network-level AI governance?

A: Security teams should choose based on where AI activity actually happens. Browser-based controls fit managed, browser-first workforces. Network-level governance is better when users rely on native apps, unmanaged devices, or agent workflows that bypass the browser. The decision should follow traffic paths, not vendor feature lists.

Q: Why do hybrid workforces create blind spots for AI security controls?

A: Hybrid workforces move AI usage across managed laptops, personal devices, mobile apps, and off-network sessions. Each shift can bypass a different control layer, so the organisation loses visibility when identity, device, and network no longer align. That is why coverage gaps are architectural, not operational noise.

Q: What breaks when AI governance depends on email or OAuth discovery alone?

A: Email and OAuth discovery can find shadow AI, but they do not stop risky use in real time. They miss native apps, personal accounts, and traffic that never touches the corporate tenant. As a result, they are useful for inventory and nudges, but not for hard enforcement.

Q: How do organisations decide whether AI governance is strong enough for autonomous agents?

A: Organisations should ask whether their controls can observe API calls, tool use, and policy decisions outside the browser. If an agent can act without passing through the organisation’s visible control points, the governance model is incomplete. Autonomous workflows need explicit visibility into machine-to-machine execution paths.


Technical breakdown

Why browser extension coverage stops at the browser boundary

Browser extensions inspect prompts and content inside supported browsers, which makes them useful for managed-device oversight. But they do not see native desktop applications, mobile apps, or agent calls that bypass the browser entirely. That means any AI usage that moves into a local client, an embedded assistant, or an API-driven workflow can fall outside the extension’s control plane. In hybrid environments, users often shift between multiple interfaces in a single day, so browser-only coverage creates a fragmented enforcement model. The result is not just blind spots, but policy drift between what the organisation thinks it governs and what it can actually observe.

Practical implication: map every AI entry point by interface type before assuming browser controls are sufficient.

How email, OAuth, and SASE controls discover different parts of shadow AI

Email-based discovery sees sign-up confirmations and OAuth grants, which makes it strong for inventory and early governance nudges. SASE and SWG controls sit inline with web traffic, so they can enforce DLP and access policy when traffic stays on the routed path. Neither model fully covers personal accounts, unmanaged devices, or native apps that do not traverse the expected channel. The architectural lesson is that discovery and enforcement are not the same function. Teams often combine them, but each still depends on where the identity interaction is visible. That is why some AI adoption is found late, even when an organisation has mature networking controls.

Practical implication: separate discovery coverage from enforcement coverage when evaluating shadow AI controls.

Network-level AI governance for autonomous agents and native apps

Network-level interception moves the control point to traffic flow rather than browser or endpoint state. That gives it broader reach across browsers, desktop clients, and API-driven agent workflows, provided the traffic is routed through the platform’s infrastructure. This is especially relevant for autonomous agents, because their most important identity events are not human keystrokes but API calls, tool requests, and model interactions that may never touch a browser. The technical trade-off is deployment coordination and routing discipline, but the architectural benefit is that governance follows the interaction instead of the device form factor. For AI programmes with mixed interfaces, this is the most complete model in the article.

Practical implication: evaluate whether your AI traffic can be consistently routed before choosing a network-level governance model.


Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Architecture is the control plane for AI governance, not a deployment detail. The article shows that browser extensions, email discovery, SASE, ecosystem-native suites, and network-level interception each govern a different slice of AI behaviour. That means the security programme is really choosing a visibility model, not just a product. Practitioners should treat control placement as the first governance decision.

Hybrid work has turned AI access into a distributed identity problem. When users move between office, home, travel, and unmanaged devices, the identity path fragments across endpoints and networks. NHI governance cannot rely on a single assumed perimeter when prompts, OAuth grants, native apps, and agent calls all live in different control domains. The implication is that identity teams need coverage maps, not feature checklists.

Coverage gaps are the real risk, because every architecture leaves something behind. Browser-first models miss native apps, email-first models miss personal accounts, and ecosystem-native suites leave third-party AI outside the fence. That is not a product flaw so much as a structural limit on what can be governed from a given layer. Teams should decide which blind spot they can tolerate, then build around it.

Identity blast radius: the useful concept here is how far AI access extends beyond the original control boundary. A prompt entered on a managed laptop is one event; the same user on a personal device, native client, or agent workflow creates a wider governance surface. The broader the blast radius, the more likely policy enforcement has to follow the traffic rather than the endpoint. Practitioners should measure AI access by reachable surface, not by license count.

For agentic workflows, visibility into tool calls matters more than browser inspection. Autonomous agents do not rely on a single user session in the way a browser extension assumes. Their identity behaviour is distributed across API authentication, model calls, and downstream tool use. NHI governance therefore has to account for machine-to-machine execution paths that standard browser-centric controls were never designed to see.

From our research:

  • The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
  • 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to the same research.
  • For deeper governance context, see The 52 NHI Breaches Analysis for real-world failure patterns and root cause breakdowns.

What this signals

Identity coverage will become the differentiator in AI governance programmes. As organisations expand AI use across browsers, desktop clients, and agents, the deciding question is which control plane can still see the interaction when the user leaves the managed perimeter. Teams that cannot answer that question will keep finding policy gaps after adoption is already widespread.

Coverage maps will matter more than platform checklists. A platform may look comprehensive in demos and still miss personal devices, native apps, or non-browser agent flows. The practical next step for practitioners is to document which identities, devices, and traffic paths each governance layer can actually observe, then close the highest-risk blind spot first.

Hybrid AI access creates an identity blast radius that extends beyond endpoint ownership. When prompts, OAuth grants, and agent calls can originate from multiple devices and networks, governance has to follow the event path rather than assume control at the laptop. For a broader view of where these patterns fail in practice, compare your environment against the 52 NHI Breaches Analysis.


For practitioners

  • Map AI control coverage by interaction layer Inventory where prompts, approvals, OAuth grants, and API calls actually occur across browsers, native apps, mobile tools, and agent workflows. Then compare that map to the layers your current controls can see, so gaps are explicit instead of assumed.
  • Separate discovery from enforcement in your architecture review Use email and OAuth signals for shadow AI discovery, but do not confuse them with real-time blocking. If you need enforcement on native apps or autonomous agents, validate whether traffic reaches the control point before relying on policy outcomes.
  • Test unmanaged-device behaviour before rollout Run pilot scenarios on BYOD laptops, contractor endpoints, and travel networks to verify what happens when users leave managed browsers or corporate tunnels. Document which AI actions still receive policy enforcement and which ones fall outside monitoring entirely.
  • Treat agent workflows as a separate governance class Check whether your controls can see API calls, tool selection, and model interactions from autonomous agents, not just human browser sessions. If those flows are invisible, they should be governed as a distinct risk surface, not folded into standard endpoint policy.

Key takeaways

  • AI security platforms fail differently depending on where they sit in the stack, so architecture determines governance reach.
  • Hybrid work expands AI access beyond the browser, which makes blind spots inevitable unless teams map every interaction layer.
  • Practitioners should choose controls by traffic path and identity surface, not by feature count or deployment convenience.

Standards & Framework Alignment

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

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A2Agent workflows create visibility gaps when browser controls cannot see tool calls.
OWASP Non-Human Identity Top 10NHI-01AI apps and agents behave as non-human identities when they authenticate and call APIs.
NIST CSF 2.0PR.AC-4Access control must account for unmanaged devices and off-network sessions.

Map agent tool use and routing paths, then enforce policy at the interaction layer the agent actually uses.


Key terms

  • Shadow AI: Shadow AI is AI use that appears in an organisation without formal approval, inventory, or governance. It often surfaces through consumer accounts, unmanaged devices, or personal workflows, which makes it hard to monitor with traditional identity controls.
  • Control Plane: A control plane is the layer where policy is enforced and decisions are made about access, monitoring, or blocking. In AI governance, the control plane may sit in the browser, network, email tenant, or vendor ecosystem, and each location changes what can be seen.
  • Identity Blast Radius: Identity blast radius is the practical reach of an identity’s access across apps, devices, networks, and agents. The concept matters because AI use can spread through multiple channels, so a small policy gap can create a much larger governance exposure.
  • Agent Workflow: An agent workflow is a machine-driven sequence where an AI system can call tools, access data, and continue execution with limited human involvement. These workflows need governance that sees API activity and tool use, not just browser sessions or user clicks.

Deepen your knowledge

AI governance across browsers, native apps, and autonomous agents is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is confronting hybrid work and off-network AI access, it is worth exploring.

This post draws on content published by WitnessAI: AI security platforms for hybrid workplaces. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org