Browser controls answer a different problem from network controls. Network tools can block destinations, but browser-layer controls can inspect prompt content, user context, and submission behaviour at the moment risk is created. For shadow AI, that makes browser enforcement the more precise control, while network controls remain a useful backstop.
Why Browser Controls Fit the Shadow AI Problem Better
shadow ai is usually created at the point of use, when a user types sensitive text into an unsanctioned web app, browser extension, or embedded AI feature. That is why browser-layer controls are better aligned to the risk: they can inspect the page, the prompt, the user session, and the submission event before data leaves the browser.
This makes the control decision more precise than a destination-only block. A network filter can stop known endpoints, but it cannot reliably judge whether the content being submitted is source code, customer data, credentials, or harmless text.
Browser enforcement also handles cases where the destination is not obviously risky on the network layer, such as sanctioned SaaS products that quietly expose AI features or third-party integrations. The practical question is not just “where is traffic going?”, but “what is the user about to disclose?”
What Network Controls Still Do Well
Network controls still matter because they provide broad containment, especially when organisations need a fast backstop against known shadow AI destinations or high-risk categories. They are useful for coarse policy enforcement, egress reduction, and blocking obvious unsanctioned tools at scale.
But network tools are inherently later and less contextual. They see traffic after the browser has already created the request, which means they often miss the business meaning of the submission and cannot distinguish risky AI use from normal web access with the same precision.
In practice, the best operating model is layered. Browser controls reduce the chance of unsafe submission, while network controls reduce residual exposure from unmanaged apps, alternate clients, and traffic that bypasses the browser path.
How to Choose the Right Control Boundary
The right boundary depends on the decision you need to make. If the question is whether to prevent a user from reaching a known unsanctioned AI site, network controls may be enough. If the question is whether to stop a user from pasting source code, regulated data, or internal strategy into an AI prompt, browser controls are the stronger fit.
That distinction matters because shadow AI is often an interaction problem, not just a transport problem. The control should be placed where the organisation can still evaluate content, user context, and intent with the least delay and the least ambiguity.
Browser controls also tend to support policy exceptions more cleanly. Teams can allow some AI use while still enforcing rules on sensitive content, risky account states, unmanaged devices, or unsanctioned browser contexts. That gives security teams a more usable control surface than a simple deny list.
Risk and Threat Considerations
Shadow AI creates two different failure modes: accidental disclosure by users and deliberate abuse by insiders or attackers operating through normal browser sessions. The main risk is not only that an AI destination exists, but that the browser session becomes a live data-exfiltration path before network controls can intervene.
Failure mechanism: Network-only control assumes destination reputation is enough, but shadow AI risk is often created by prompt content, page context, and the act of submission. That means sensitive material can be exposed to sanctioned or unsanctioned services that are not easily distinguished at the egress layer.
Impact: Organisations can leak source code, credentials, customer records, and strategic material into AI tools, then lose visibility into where that data was retained, reused, or redistributed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-3 — Data Protection | Shadow AI risk centers on preventing data leakage from user submissions. |
| Recommendation — Apply data protection safeguards to restrict sensitive content from leaving the browser. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Browser policy can enforce what content users may submit to AI services. |
| AU-6 — Audit Review, Analysis, and Reporting | Browser controls create higher-fidelity events for prompt submission monitoring. | |
| Recommendation — Enforce content-aware access limits at the point of submission. Review prompt and submission telemetry for unsafe AI use. | ||
| ISO/IEC 27001:2022 | A.8.12 — Data leakage prevention | Shadow AI is fundamentally a data leakage problem at the user interface. |
| Recommendation — Deploy DLP controls that inspect and block sensitive prompt content. | ||
Practitioner Guidance
What to prioritise: Put browser-layer policy on the paths where users actually compose and submit prompts, then use network controls as a secondary containment layer. That sequence gives you the best chance to stop disclosure before it happens, not just block it afterwards.
What to verify: Confirm that the browser control can see the user context you care about, including page category, prompt text, copy-and-paste events, extension activity, and the difference between sanctioned and unsanctioned AI use. If it cannot inspect the moment of submission, it will behave more like a coarse filter than a true prevention control.
Common mistake: Treating “we block AI sites” as equivalent to shadow AI governance. That approach misses embedded AI features, allowed SaaS apps with hidden AI functions, and content exposure through browser sessions that were already authenticated.
Practitioner takeaway: Use browser controls for precision and prevention, then keep network controls for broad backstop coverage, because shadow AI is primarily created at the point of disclosure rather than at the point of destination.
Related resources from NHI Mgmt Group
- Should organisations use both network and identity controls for AI agents?
- Should organisations use browser telemetry to investigate shadow AI and shadow SaaS usage?
- How can organisations reduce data loss when employees use AI apps and shadow SaaS in the browser?
- How should organisations govern shadow AI without blocking legitimate use?