Shadow AI in code is outpacing enterprise governance controls

At a glance

What this is: Shadow AI in development environments is creating a governance blind spot because security tools cannot fully see browser AI usage, code-level API calls, desktop plugins or autonomous agents.

Why it matters: IAM, NHI and AI security teams need a unified control model because invisible AI usage can touch customer data, production systems and authorisation decisions outside existing review processes.

By the numbers:

• By 2027, 40% of enterprises will face AI tool costs exceeding twice their budgets, according to Gartner research cited by ArmorCode.
• By 2028, vibe coding tools will increase software defects by 2500%, according to Gartner research cited by ArmorCode.

Context

Shadow AI is the use of AI tools, embedded assistants and autonomous agents inside delivery workflows without central governance, inventory or approval. The control problem is not just whether AI is allowed, but whether security teams can see which tools are active, what data they touch, and what production actions they can trigger.

This article sits at the intersection of AI governance, software delivery and identity control. When AI tools can call APIs, touch customer records, or act on behalf of employees, the question becomes one of authorisation, oversight and lifecycle management, not just software usage policy.

Key questions

Q: What breaks when shadow AI is used before governance review?

A: The control that breaks first is inventory, followed quickly by ownership, data-scoping, and auditability. If an AI model or integration is operating before review, security teams lose the ability to prove what data it touched, who approved it, or whether its outputs were constrained. At that point, governance becomes forensic rather than preventive.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Should organisations treat AI agents and service accounts differently in SaaS governance?

A: They should govern them with the same relationship-aware discipline but not the same assumptions. Service accounts usually have more stable ownership and scope, while AI agents can chain access across workflows and integrations in ways that change during execution. That means both need inventory, lifecycle control, and blast-radius analysis, but agent behaviour deserves closer runtime scrutiny.

Technical breakdown

Why code-visible AI still leaves a governance blind spot

AI usage fragments across channels that conventional tooling observes unevenly. Browser sessions may be visible to network controls, but embedded libraries in repositories, IDE plugins on laptops and agent workflows in SaaS environments all bypass a single detection plane. That creates a discovery problem: organisations may know AI is present in general, but not which tools, which users, which data sources or which execution contexts are in play. Once AI moves from chat to code and agents, the real issue becomes control-plane visibility across the software lifecycle, not endpoint monitoring alone.

Practical implication: build an inventory that correlates browser, endpoint, code and SaaS telemetry before you try to govern AI usage.

How autonomous agents change the identity and authorisation model

An AI agent is not just an assistant with a prompt. It can make runtime decisions, invoke tools, sequence actions and operate without a human approving each step. That shifts governance from user behaviour to delegated machine behaviour, because the agent becomes a non-human actor with access scope, decision rights and potential production impact. In identity terms, the core issue is whether the agent is authenticated, authorised and constrained as its own runtime identity rather than hidden inside a human account or app token. Without that distinction, access reviews miss the real actor.

Practical implication: treat agents as governed identities with explicit scope, ownership and revocation paths, not as informal extensions of the developer.

Why traditional AppSec and TPRM controls fall short

Application security scanners focus on code artefacts, while third-party risk processes move too slowly for AI adoption that can happen in hours. Neither approach fully answers who approved the AI tool, what data it can access, or whether its output is allowed to trigger transactions or deployments. That is why shadow AI creates governance debt: organisations accumulate unreviewed tool usage faster than they can classify, approve or retire it. The underlying failure is lifecycle control, not simply weak policy wording.

Practical implication: tie AI approval to continuous inventory and access review so governance keeps pace with deployment speed.

Threat narrative

Attacker objective: The practical objective is not always a traditional attacker, but the resulting risk is uncontrolled AI-mediated access to code, data and production actions.

1. Entry occurs when developers adopt browser-based AI tools, IDE plugins or embedded libraries without central approval, creating hidden access paths into code and workflows.
2. Credential and access exposure follows when those tools reach customer data, production systems or external APIs through accounts and tokens that were never designed for AI use.
3. Impact emerges when autonomous agents or vibe coding workflows make consequential changes, introduce defects or process sensitive data without an accountable human decision point.

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 a governance problem, not a tool-approval problem. The article describes a world where AI enters through browsers, IDEs, code repositories and autonomous agents faster than central review can keep up. That means the decisive control is no longer a blanket policy on AI use, but a live inventory of where AI is already embedded and what it can touch. For practitioners, the shift is from prohibition thinking to governed discovery and authorisation.

AI agents introduce a new non-human identity boundary. Once a system can act independently, initiate calls and affect production outcomes, it should be treated as a runtime identity with a defined owner and access envelope. That is where NHI governance becomes relevant: agents can inherit the same lifecycle risks as service accounts, but with faster behaviour and weaker human oversight. The practitioner lesson is to govern agent identity explicitly rather than letting it hide inside human workflows.

Complete visibility is the named concept this article exposes. Shadow AI succeeds because organisations lack complete visibility across code, endpoints and production access, not because AI itself is inherently ungovernable. Security teams that separate browser monitoring from code review and agent oversight will continue to miss the full attack and misuse surface. The practical conclusion is that governance must follow the execution path, not the procurement record.

Vibe coding creates governance debt faster than traditional review can absorb. The article’s deeper signal is that low-skill, AI-assisted development can produce deployable software long before security teams can assess architecture, data access or operational risk. That compresses the time available for approval and pushes control left into the point of creation. Practitioners should assume review-only models will fail when generation outruns governance.

AI governance now sits in the middle of identity, application and data security. The article makes clear that AI tools can touch credentials, customer data and production logic at once. That means no single control family is sufficient, because the risk spans identity, authorisation, software change and sensitive data handling. The right response is cross-functional governance with explicit ownership for the AI runtime, not just the model or the application.

From our research library:

• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Complete visibility is the control variable that shadow AI removes. Security teams should assume AI usage will spread through browser sessions, embedded code and autonomous agents before policy catches up, so discovery has to become continuous rather than periodic. The governance outcome is simple: if you cannot inventory AI touchpoints, you cannot govern their access paths or data exposure.

Identity control must extend to agent runtime behaviour. Once AI tools can call APIs or act on customer data, the practical question is not whether they are allowed in general, but what scope and decision rights they hold in production. That is where NHI-style thinking becomes useful: ownership, revocation and least privilege must follow the agent, not just the human who installed it.

Shadow AI will keep outpacing review-only governance. 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey. Teams should expect governance debt to accumulate unless approval, monitoring and decommissioning are tied to the same control plane.

For practitioners

• Inventory all shadow AI entry points Correlate browser usage, IDE plugins, embedded libraries, desktop tools and agent platforms so you can see where AI is actually operating in delivery workflows.
• Assign each agent a governed identity Define ownership, scope, approval path and revocation for every autonomous agent or AI tool that can act on systems, data or transactions.
• Restrict production and data access by AI tool class Separate read-only experimentation from tools that can access customer records, invoke APIs or trigger deployment actions, and require explicit approval for the latter.
• Add AI usage to security review workflows Include AI tools and agents in architecture review, third-party intake and periodic access recertification so governance follows deployment speed.
• Monitor for unmanaged agent behaviour Look for agents making repeated API calls, reaching new data sources or acting outside expected task boundaries, then investigate the associated identity and privilege path.

Key takeaways

• Shadow AI is creating an operational blind spot because AI can enter through browsers, code, plugins and agents faster than security teams can inventory it.
• The problem is not only adoption volume but control fragmentation, which leaves discovery, authorisation and oversight disconnected across delivery workflows.
• Practitioners need continuous AI inventory, explicit agent identity governance and approval workflows that keep pace with development speed.

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.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Governance Debt: The accumulation of unresolved identity control weaknesses created when teams prioritise speed over lifecycle design. In NHI environments, it shows up as accounts with unclear ownership, undocumented purpose, stale credentials, and no reliable retirement path, all of which make later security work harder.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps security and identity practitioners build the control thinking needed for autonomous systems, service accounts and other non-human actors.