Because much of the risk happens inside legitimate sessions rather than at a blocked domain. Users can paste data into browser-based AI tools, enable features in approved apps, or grant access through OAuth and SSO, none of which depends on a single network destination. That makes visibility into identity and data movement more important than egress filtering alone.
Why network controls miss the riskiest Shadow AI paths
Network controls are still useful, but they are blind to the places where shadow ai risk most often shows up: inside approved sessions, within sanctioned SaaS, and through delegated access that looks normal at the network layer. When a user pastes sensitive material into a browser-based AI tool or grants an app access via OAuth, the traffic may never resemble a classic blocked destination event.
That is why the practical question is not only where the traffic goes, but how Shadow AI and AI agent discovery works across identity grants, application permissions, and data movement. Controls that only watch egress cannot see whether a user has approved a risky integration, whether an AI feature is enabled in a trusted app, or whether a sanctioned session is now carrying sensitive content into an external model.
Why identity and data movement matter more than blocked domains
The riskiest Shadow AI use is often not “unauthorised internet access” in the traditional sense. It is the misuse of legitimate access. That includes users connecting browser AI tools to work accounts, giving third-party apps broad consent, or reusing a trusted session to move data into an AI service. The control problem is therefore closer to authorisation, consent, and information handling than to simple destination filtering.
This is also why inventory matters. If an organisation cannot see which AI services are connected to business identities, it cannot distinguish harmless experimentation from material exposure. The Vercel Context.ai OAuth supply chain breach shows how a trusted integration path can become the exposure path when third-party access is granted without enough scrutiny.
Data movement is the other half of the problem. Once information leaves a controlled endpoint and is pasted into a model, stored in chat history, or shared through an integration, network controls may still show only ordinary HTTPS traffic. That is why effective Shadow AI governance needs visibility into sessions, consents, and the sensitivity of what users are sending, not just the domains they visit.
What to control when the network view is incomplete
The strongest practical response is to combine network telemetry with identity, SaaS, and endpoint evidence. A blocked-domain approach may help reduce casual misuse, but it will not catch feature-level AI adoption inside approved products, nor will it reliably surface overbroad OAuth grants or embedded AI assistants in business tools.
For that reason, the most useful control points are the ones that tell you who connected what, what they were allowed to do, and what data they moved. The Samsung ChatGPT leak 2023 is a clear example of why usage policy alone is not enough when staff can place sensitive material into a legitimate AI session. The issue is not simply the destination, but the combination of trust, convenience, and data exposure.
Shadow AI governance therefore benefits from three practical layers: discovery of connected apps and AI features, review of granted access, and controls that reduce the chance of sensitive data being entered in the first place. A network block can be one layer of defence, but it is rarely the decisive one when the highest-risk activity occurs through approved identity paths.
Risk and Threat Considerations
Shadow AI becomes risky when users can move sensitive information through authorised sessions that appear routine to the network. The main exposure is data leakage through trusted identities, sanctioned SaaS features, and third-party integrations that operate outside traditional web filtering assumptions.
Failure mechanism: Users can grant OAuth access, enable AI features in approved applications, or paste confidential material into browser-based tools without tripping a blocked-domain control, because the activity looks like ordinary authenticated traffic.
Impact: Organisations can lose visibility into where sensitive data went, who authorised it, and whether an AI service or integration retained it, which increases breach, compliance, and insider-risk exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Shadow AI exposure often enters through third-party integrations and delegated access. |
| NHI-02 — Secret Leakage | Shadow AI can expose secrets when users paste credentials or tokens into AI tools. | |
| NHI-05 — Overprivileged NHI | AI-enabled apps and integrations may receive broader access than the business need requires. | |
| Recommendation — Review third-party AI integrations and revoke trust where delegated access is excessive. Block sensitive secret submission paths and rotate any exposed credentials immediately. Enforce least privilege on AI-connected accounts and scoped API permissions. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Shadow AI governance depends on knowing which accounts and app grants can access AI services. |
| AC-6 — Least Privilege | The core risk is overbroad access through trusted identities and integrations. | |
| AU-6 — Audit Review, Analysis, and Reporting | Detecting Shadow AI requires correlating sessions, consents, and unusual data movement. | |
| Recommendation — Maintain current inventory and lifecycle control for accounts that can reach AI tools. Restrict AI-connected permissions to the minimum required for the task. Correlate identity, SaaS, and endpoint logs for anomalous AI access patterns. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shadow AI risk is fundamentally about who can connect apps, features, and data paths. |
| A.8.5 — Secure authentication | OAuth, SSO, and session trust determine whether AI access is legitimate and bounded. | |
| Recommendation — Apply access rules to AI-enabled services, integrations, and data-sharing permissions. Require strong authentication for AI-connected accounts and privileged approvals. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Shadow AI visibility depends on governing who can use and connect AI services. |
| Recommendation — Review and remove unnecessary access to AI tools, integrations, and data sources. | ||
Practitioner Guidance
What to prioritise: Start with identity-linked discovery, not perimeter filtering. If you cannot enumerate AI-enabled apps, OAuth grants, and AI features inside approved platforms, you do not have enough visibility to judge Shadow AI risk accurately.
What to verify: Check whether your monitoring can tie AI usage to the user, app consent, data type, and session context. If the answer is only “we know the domain,” the control set is too shallow for the risk you are trying to manage.
Decision rule: Treat any AI integration that can read mail, files, chats, or tickets as a data-access decision, not just a productivity feature. The question is not whether the tool is allowed to connect, but whether its permissions and data paths are proportionate to the business need.
Practitioner takeaway: The riskiest Shadow AI behaviour is usually authorised, embedded, and data-driven, so the winning control strategy is to govern identities, consents, and sensitive data flows first, then use network controls as supporting telemetry.