Shadow AI governance depends on visibility, not permission

At a glance

What this is: This is a blog post arguing that shadow AI is already widespread inside organisations and that the core control gap is visibility, governance, and scoped identity for AI agents.

Why it matters: It matters because IAM, PAM, NHI, and AI governance teams now need to control unsanctioned agent use without blocking productive work or losing auditability.

By the numbers:

• 69% of organizations either suspected or had evidence that employees were using prohibited generative-AI tools.
• 78% of AI users bring their own AI tools to work.
• Only 37% of organizations have an AI governance policy in place.
• 1.27 million AI-related secret exposures in public GitHub were counted by GitGuardian, up 81% year on year.

Context

Shadow AI is a governance problem, not just a tooling problem: employees are already using AI assistants and AI agents outside approved review paths, which means the organisation has less visibility than it assumes. In practice, that leaves security teams trying to govern an expanding non-human footprint without a complete inventory or a reliable audit trail.

The central issue is that AI use now spans discovery, access, and action, but most controls still start too late. When teams can run prompts, use connected tools, and make changes without a governed identity, the identity programme loses the ability to answer who did what, with which permissions, and under whose authority.

For shadow AI discovery and governance to work, teams first need to accept that the unmanaged use is already inside the environment and that blocking alone will not remove it.

Key questions

Q: What should security teams do first when shadow AI tools appear in a client environment?

A: The first step is to identify where unauthorized tools are actually being used. Regular IT audits and application discovery help teams locate unsanctioned AI services, assess what data is being shared, and decide whether to block, replace, or formally approve each application. Without visibility, policy enforcement becomes guesswork and the client cannot control data flow.

Q: Why do agent tool calls create more risk than chat-only AI use?

A: Agent tool calls create more risk because they convert language into action. Once an agent can reach APIs, MCP servers, or business systems, a manipulated instruction can produce a downstream change before a person sees the outcome. That is why privilege scope and pre-execution controls matter as much as content filtering.

Q: How do teams know if AI access is too broad?

A: AI access is too broad when a tool can read, write, and export data beyond the immediate task or when the credential remains valid after the use case changes. Teams should look for persistent tokens, shared access paths, and permissions that survive the original business need. Those are the signs of unmanaged standing access.

Q: What is the difference between blocking Shadow AI and governing it through a centralized gateway?

A: Blocking tries to suppress use, but it usually pushes employees to personal devices and other harder-to-monitor channels. Governing through a centralized gateway keeps adoption visible, enables chargeback, enforces data redaction or policy checks, and preserves developer speed. The practical difference is whether security becomes a barrier or a control plane for innovation.

Technical breakdown

Why shadow AI becomes an identity problem

Shadow AI becomes an identity problem when AI tools and agents are allowed to act without a governed principal behind them. In that state, the organisation cannot reliably bind actions to a known identity, define a stable access boundary, or reconstruct what the system touched after the fact. That is why discovery, identity assignment, and scoped authorisation matter together. The issue is not only that an AI tool exists, but that it is operating outside the same lifecycle controls used for employees, service accounts, and other non-human identities. See the Agentic AI Identity Guide.

Practical implication: Treat unmanaged AI as an identity inventory problem first, because you cannot govern what you cannot attribute.

Why least privilege changes the risk profile for AI agents

AI agents are not just chat interfaces when they can read data, call tools, and make changes. That combination creates a non-human actor with the ability to cross from analysis into action, which makes over-scoping especially dangerous. Least privilege for agents means task-scoped permissions, not broad access inherited by convenience. If an agent is confused, compromised, or misused, the size of the blast radius depends on how much authority it was granted before execution began. See the AI Agent Authorisation Guide.

Practical implication: Scope agent permissions to the exact task and tool path, not to the broad job role of the human who requested it.

How discovery works when the activity is already spreading

Shadow AI discovery depends on joining together the traces users and agents already leave in existing systems. OAuth and SSO grants, endpoint telemetry, browser signals, network traffic, repository scanning, and user reporting each reveal a different slice of the picture. None is sufficient alone because AI usage moves across browser, code, endpoint, and cloud surfaces. The technical lesson is that discovery must be continuous and multi-source, or organisations will only see the subset that happens to pass through one control point.

Practical implication: Use multiple discovery channels at once so local usage, cloud usage, and developer-facing usage are all visible.

Threat narrative

Attacker objective: The practical objective is to reach data or execute changes through unmanaged AI activity without triggering normal governance controls.

1. Entry occurs when employees adopt AI tools and agents outside approved review processes, often through personal accounts, browser sessions, or local developer workflows.
2. Credential or access exposure follows when those tools connect through OAuth grants, embedded keys, or other permissions that were never fully governed.
3. Impact appears when the unmanaged AI system reads data, calls tools, or changes systems without a complete record of what it touched or who approved the action.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

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

Shadow AI is now an identity governance problem, not a policy problem. The article correctly frames the issue as visibility and control, because banning tools does not change the underlying behaviour. What changes the governance model is that AI systems increasingly act like non-human identities with their own access paths and operational footprint. Practitioners should treat unmanaged AI as part of the identity estate, not as a side channel.

Access review cadences were built for stable identities and fail when AI is introduced ad hoc. The governance assumption that an identity exists long enough to be reviewed is already under pressure in AI-heavy environments. When usage starts in browser sessions, local tools, and ephemeral agent workflows, the review process often arrives after the action has already occurred. That means governance must shift upstream to discovery and authorisation, not just recertification.

Identity without scoped authority is the missing control plane for shadow AI. The article's strongest operational point is that AI agents need a real identity, a limited permission set, and a traceable action trail. That is the difference between allowing innovation and normalising blind execution. The practitioner takeaway is to govern AI as a population of non-human identities with defined lifecycle and access boundaries.

Shadow AI discovery should be treated as a cross-surface control, not a single product decision. OAuth logs, endpoint telemetry, browser controls, network inspection, and repository scanning each capture different parts of the same problem. The governance challenge is integration, not just detection volume. Teams should build a discovery stack that produces a usable inventory of AI usage before they decide how much of it to approve.

From our research library:

• One in five organisations reported a breach due to shadow AI, and 97% of those breached through an AI model or application lacked proper AI access controls, according to IBM's 2025 Cost of a Data Breach Report.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Shadow AI discovery will increasingly sit alongside IAM and PAM operations because the control problem is no longer just whether a user is authenticated, but whether an AI system is authorised to act at all. Teams that wait for policy perfection will keep losing ground to the speed of adoption, while teams that instrument usage across identity, endpoint, and cloud layers will have the visibility needed to govern rather than prohibit.

Identity-first AI governance: the next operating model will treat every agent as a governed actor with a principal, scope, and audit trail. That shift matters because access review cycles alone cannot keep up with agent-led activity that appears, acts, and disappears faster than traditional recertification windows.

IBM's 2025 Cost of a Data Breach Report shows only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that the visibility gap is already familiar in non-human identity programmes. Shadow AI expands the same problem into a faster-moving layer, so the programme response has to combine discovery, least privilege, and traceable execution.

For practitioners

• Run a multi-source discovery pass Correlate OAuth grants, SSO logs, endpoint signals, browser usage, network egress, and repository scans to build the first usable inventory of shadow AI.
• Assign each AI agent a governed identity Tie active agents back to a known principal so actions, approvals, and changes can be attributed and reviewed later. See the Agentic AI Identity Guide.
• Scope permissions to the task, not the role Limit each agent to the data and tools required for the immediate job, and remove broad standing access where possible. See the AI Agent Authorisation Guide.
• Establish an approval path for unsanctioned use Give teams a safe route to declare and govern AI use so security review does not depend on shadow adoption becoming a finding.
• Log actions at the point of execution Capture which agent touched which system, what it changed, and under whose authority it acted so incident reconstruction is possible.

Key takeaways

• Shadow AI is already operating inside many organisations, so the governance question is how to see and control it rather than whether to permit it.
• AI agents become materially riskier when they can read data, call tools, and make changes without scoped identity and traceable authority.
• The practical control stack is discovery first, then identity assignment, then task-scoped permissions and auditable execution.

Related NHI Mgmt Group resources: Shadow AI and AI Agent Discovery Guide · AI Agent Authorisation Guide · Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• AI Agents: AI agents are autonomous software entities that act within organisational environments and make runtime decisions within assigned boundaries. They can hold identities, authenticate to systems, and exercise permissions, which makes them comparable to other non-human identities that require inventory, governance, and continuous activity monitoring.
• Effective Permissions: Effective permissions are the access an identity can actually use after role inheritance, scope, and policy are applied. In Azure AI environments, they often matter more than the assigned role name because inherited rights can widen access to data, logs, and secret stores.
• Governed Identity State: An identity posture that is continuously evaluated against policy, ownership, and current context instead of being assumed correct after a one-time provisioning action. It gives IAM and IGA teams a control point for change, exception handling, and timely access correction.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.