TL;DR: Nearly 90% of organisations now use AI in at least one business function, while only 22% rely exclusively on employer-provided tools and nearly two-thirds lack the policies needed to detect or manage shadow AI, according to Zero Networks. The governance gap is now broader than visibility alone: unsanctioned AI creates access paths, lateral movement risk, and compliance exposure that conventional controls were not built to cover.
At a glance
What this is: Shadow AI is the unsanctioned use of AI tools and agents without formal security oversight, and the article argues that visibility and enforcement must move together.
Why it matters: IAM, NHI, and security teams need to treat AI tools and AI agents as governed identities because unmanaged access paths, tool chaining, and policy drift can undermine least privilege across human and machine workflows.
By the numbers:
- Nearly 90% of organizations use AI in at least one business function as the number of employees that regularly use AI on their corporate devices has increased 3x year over year.
- Just 22% of individuals rely exclusively on tools provided by their employers.
👉 Read Zero Networks' analysis of shadow AI detection and governance
Context
Shadow AI is the use of AI tools, agents, or integrations without formal IT and security oversight. In practice, that means employee access, developer-deployed agents, and embedded AI features can create ungoverned identity and access paths even when the rest of the environment appears controlled.
The IAM problem is not just discovery. It is that conventional controls were built for sanctioned applications and visible human workflows, while AI usage now crosses APIs, cloud workloads, and third-party software in ways that break declared inventories and policy assumptions.
For identity programmes, this turns AI from an application risk into an access governance problem. Organisations that already struggle with service account sprawl and privilege drift will find the same failure modes reappearing in AI tools unless identity, network, and lifecycle controls are linked.
Key questions
Q: How should security teams govern shadow AI without losing visibility into legitimate business use?
A: Start by classifying approved AI services, then measure actual traffic, API calls, and embedded integrations against that baseline. Anything outside the approved set should be treated as an ungoverned identity path until it is reviewed, scoped, and either sanctioned or blocked. Governance fails when visibility depends on self-reporting alone.
Q: Why do shadow AI tools create more risk than ordinary software sprawl?
A: Shadow AI can authenticate, chain actions, and reach data through APIs and workloads in ways ordinary software inventory tools do not model well. That means the risk is not just unknown software, but unknown identity behaviour. When access paths are invisible, least privilege, review, and audit all lose precision at the same time.
Q: What do security teams get wrong about AI agent least privilege?
A: They often assign permissions based on the agent’s intended job rather than its observed runtime behaviour. That works only if task scope stays stable, which is not how many agents behave once they start chaining tools or expanding context. Least privilege should be tested against real connectivity, not design assumptions.
Q: Who is accountable when shadow AI causes a compliance failure?
A: Accountability sits with the organisation that allowed the access path to exist without oversight, classification, and control evidence. For regulated environments, that includes the teams responsible for identity governance, security operations, and audit readiness. If a tool cannot be inventoried and assigned controls, compliance claims are weak from the start.
Technical breakdown
Why shadow AI defeats traditional network controls
Shadow AI often looks like ordinary outbound traffic, which is why proxy-based controls and application allowlists miss it. The deeper issue is that identity-driven AI access is not confined to a browser session or a sanctioned SaaS pattern. AI tools can connect through APIs, chain services, and persist across workloads, creating access paths that are not obvious from endpoint telemetry alone. Once a tool or agent is able to authenticate, the attack surface is no longer the model itself but the identities and permissions surrounding it.
Practical implication: security teams need observability into AI-authenticated connections, not just web traffic.
How AI agent least privilege breaks under task expansion
AI agents are often deployed for a narrow purpose, then accumulate reach through tool chaining, policy drift, and changing task scope. That creates a familiar but sharper version of privilege creep: access is no longer matched to a stable human role or a fixed workload function. In NHI terms, the agent becomes a live identity with expanding reach, but without the lifecycle discipline normally applied to service accounts or privileged automation. Least privilege becomes difficult to enforce when the real operating scope is constantly changing.
Practical implication: define and review AI agent permissions against observed runtime behaviour, not initial deployment intent.
Why compliance gaps appear before technical incidents
Shadow AI creates a documentation and accountability gap before it creates a breach. Frameworks such as NIS2, DORA, and CIS Benchmarks depend on knowing what systems exist, what they connect to, and which controls apply. If an AI service or agent is invisible, it cannot be assessed, classified, or proven compliant. That means audit failure can emerge even when no malicious activity has been detected, because governance evidence depends on visibility and policy enforcement together.
Practical implication: connect AI discovery to control evidence collection so compliance is not dependent on manual declarations.
Threat narrative
Attacker objective: The objective is to exploit unmanaged AI access paths to move laterally, reach sensitive systems, and increase breach impact without triggering established controls.
- Entry occurs when employees, developers, or third-party tools use unsanctioned AI services or embedded AI features without security approval, creating hidden authentication paths into corporate data and APIs.
- Escalation follows as AI agents chain tools, expand task scope, and inherit more permissions than the original use case required, which increases reachable systems and compounds lateral movement exposure.
- Impact is realised when over-permissioned AI interacts with internal systems or external services in ways that widen breach blast radius, delay containment, and create compliance failure across the environment.
Breaches seen in the wild
- Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
- Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shadow AI is the governance gap between AI adoption and identity control. The article correctly shows that usage is rising faster than oversight, but the deeper issue is that AI access is now being created outside approved identity processes. Once that happens, policy enforcement, recertification, and access review all start from incomplete evidence. The practitioner conclusion is simple: AI visibility must be treated as identity governance, not just application discovery.
AI agent least privilege is becoming a moving target, not a provisioning task. Traditional IAM assumes the scope of access can be set at issuance and then reviewed later. That assumption weakens when agents chain tools and expand task scope dynamically. The implication is that static permission models no longer describe real behaviour closely enough for governance or audit.
Runtime visibility is the named concept that separates detection from control. Security teams cannot govern shadow AI from declared inventories alone because the decisive evidence is observed connectivity, not intent. This is a network and identity problem at the same time, which is why identity blast radius now depends on runtime path visibility. Practitioners should align discovery, policy, and enforcement around what AI actually touches.
Zero Trust Architecture fails when AI is treated as a normal sanctioned workload. NIST SP 800-207 assumes continuous verification across access paths, but shadow AI creates unclassified paths that bypass the verification model entirely. That means the control model is not merely incomplete, it is blind to the actor. The practitioner conclusion is that Zero Trust for AI requires identity-aware enforcement at the connection layer, not post-hoc review.
NHI governance is now the bridge between human adoption and machine execution. The article shows employees, developers, and embedded AI features all contributing to the same exposure pattern. That matters because the same lifecycle failures seen in service account sprawl now reappear in AI agents and embedded integrations. The field should treat AI governance as part of the broader non-human identity discipline, with the practitioner conclusion that lifecycle, privilege, and visibility controls must operate across both human and machine entry points.
From our research:
- The average cost of a data breach is $670,000 higher for organizations with high levels of shadow AI, according to The State of Secrets in AppSec.
- Another finding from the same research shows that 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
- That same body of research is useful when building the case for NHI Lifecycle Management Guide because shadow AI often becomes a lifecycle and offboarding problem as much as a discovery problem.
What this signals
Runtime visibility is likely to become the first meaningful control boundary for shadow AI programmes because declared inventories will continue to lag actual usage. Once AI tools are embedded in sanctioned platforms, identity teams will need continuous evidence of what is connecting, what is authenticating, and what is being reached, rather than relying on approved-software lists alone.
The programme implication is that AI governance will sit between NHI, IAM, and network security rather than inside any one of them. That shift aligns well with NIST Cybersecurity Framework 2.0 because identify, protect, and detect now have to operate on AI-related identities as well as human users.
Shadow AI also sharpens the need for lifecycle discipline. If 6 distinct secrets manager instances already fragment control in one part of the environment, similar fragmentation will emerge around AI tools unless joiner, mover, leaver processes and access reviews are extended to non-human actors.
For practitioners
- Inventory AI access paths continuously Map every AI-related destination, API connection, and embedded integration from observed traffic rather than from declared tooling lists. Treat unknown AI endpoints as governance exceptions until they are classified and approved.
- Block unsanctioned AI destinations by default Use allowlists for approved AI services and enforce them at the network layer so users, devices, and workloads cannot bypass policy through alternate clients or embedded features.
- Scope AI agents to observed operational need Review each agent against what it actually authenticates to and what it can reach, then remove inherited permissions that are broader than the runtime task requires.
- Tie AI discovery to compliance evidence Record who or what accessed AI services, what data paths were involved, and which policy controls were applied so audit readiness does not depend on manual declarations.
- Treat shadow AI as an identity lifecycle issue Fold AI tools and agents into joiner, mover, leaver processes so new AI access is approved, changed access is recertified, and unused access is removed.
Key takeaways
- Shadow AI turns AI adoption into an identity governance problem because access paths can exist outside approved oversight and still reach corporate systems.
- The article’s evidence shows the gap is material: broad AI usage, weak exclusive use of employer tools, and missing policies all combine to increase breach cost and audit risk.
- Security teams need runtime visibility, default blocking of unsanctioned destinations, and lifecycle control for AI agents before the governance gap becomes a persistent control failure.
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 Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | The article covers unsanctioned AI tools and agent behaviour that escape governance. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Shadow AI is fundamentally a non-human identity visibility problem. |
| NIST Zero Trust (SP 800-207) | Section 3.3 | The article’s control model depends on continuous verification and least privilege. |
| NIST CSF 2.0 | PR.AC-4 | AI access must be managed and limited to support least privilege. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is central to governing AI agent permissions. |
Apply continuous verification to AI-authenticated connections and remove implicit trust between services.
Key terms
- Shadow AI: Shadow AI is the use of AI tools, agents, or embedded AI functions without formal security and IT oversight. In identity terms, it creates unknown authentication paths, unknown data reach, and governance gaps that existing inventories and approvals cannot reliably cover.
- AI Agent: An AI agent is a software entity that can decide and act at runtime by selecting tools, data sources, and execution timing within its permitted environment. For governance, the key issue is not branding but whether the system’s behaviour creates a live identity with expanding access needs.
- Runtime Visibility: Runtime visibility is the ability to observe what an identity or tool is actually doing while it is operating. For shadow AI, it matters because declared inventories often miss the real access path, and only observed connections reveal whether control, review, and policy are truly aligned.
- Least Privilege: Least privilege means granting only the access needed for the current task or role. For AI tools and agents, that access must be judged against observed runtime behaviour, because task scope can expand faster than static permissions or periodic review cycles can react.
What's in the full article
Zero Networks' full article covers the operational detail this post intentionally leaves for the source:
- How the article maps shadow AI discovery to live network visibility and enforcement points.
- The four-step control approach for inventorying AI, blocking unsanctioned destinations, and governing agents with least privilege.
- The product-specific segmentation and control examples for SaaS AI, AI agents, and LLM infrastructure.
- The operational distinction between deterministic enforcement and human-on-the-loop policy management.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a stronger identity security strategy or maturing governance across human and non-human actors, it is worth exploring.
Published by the NHIMG editorial team on 2026-06-12.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org