Shadow AI is reshaping code governance in development teams

At a glance

What this is: This report finds that developers are widely using AI tools through personal accounts and fragmented toolchains, creating shadow AI governance gaps in code production.

Why it matters: It matters because IAM, security, and engineering governance teams need controls that address code provenance, access provenance, and policy enforcement beyond sanctioned tool access.

By the numbers:

• 35% of AI tool usage in development happens through personal, ungoverned accounts rather than work-sanctioned channels.
• 52% of ChatGPT usage occurs via personal accounts.

👉 Read Sonar's full report on shadow AI and developer tool usage

Context

AI-assisted development creates a governance gap when the systems shaping code are not the same systems security teams can control. In this case, the core issue is shadow AI, where developers use personal accounts and multiple tools outside sanctioned channels, so policy at the tool layer does not reliably govern what reaches production code. The primary concern is code provenance, which is now part of the identity and access conversation because the account used to generate code can sit outside corporate controls.

The article’s findings show that developers are treating AI as a utility belt rather than a single platform, which makes centralized tool approval less effective as a control model. That pattern is typical of fast-moving engineering environments, not an edge case, so organisations need governance that follows the output into CI/CD rather than assuming sanctioned access alone will solve the problem.

Key questions

Q: How should security teams govern AI-assisted code when developers use personal accounts?

A: They should govern the output, not just the tool access. That means requiring code review, provenance logging, secrets scanning, and CI/CD policy checks on every change, even when the code was generated through unmanaged or personal AI accounts. If the workflow cannot be traced and validated, it should not be eligible for production.

Q: Why does BYOAI create a governance problem for engineering leaders?

A: BYOAI fragments control because developers can choose different tools, accounts, and contexts that sit outside central oversight. The result is inconsistent data handling, weak audit trails, and reduced visibility into what influenced the code. Governance becomes an output problem when the organisation cannot reliably control the path from prompt to production.

Q: What breaks when AI code generation is controlled only through sanctioned tools?

A: The main failure is that sanctioned access does not guarantee sanctioned behaviour. Developers can still use personal accounts, move between tools, or paste sensitive context into unmanaged sessions. That leaves security teams with policy on paper but incomplete visibility into the real development workflow.

Q: How can organisations reduce shadow AI risk without blocking adoption?

A: Start by discovering every AI tool and enriching it with owner, data access, and integration details. Then approve, restrict, or retire assets based on exposure rather than assumptions. This lets teams keep useful AI in production while removing the unmanaged paths that create avoidable risk.

Technical breakdown

Why personal accounts create a code provenance blind spot

When developers use personal accounts for AI coding tools, the organisation loses a clear link between user identity, session context, and generated output. That breaks the governance chain that usually supports auditability, acceptable-use enforcement, and incident investigation. In practice, the risk is not only unapproved tool use but untraceable code origin, which complicates review, attribution, and downstream accountability. The control problem sits at the boundary between identity governance and software delivery because account-level policy cannot fully govern content created outside managed channels.

Practical implication: enforce provenance checks and policy gates at commit and pipeline stages, not only at the AI tool access layer.

How tool fragmentation weakens centralized AI governance

A developer stack that includes multiple AI tools for different tasks creates inconsistent trust boundaries. One tool may be sanctioned in the IDE, another used in a browser session, and another for documentation or refactoring, each with different data handling and retention behaviour. That fragmentation undermines attempts to manage risk through a single approved platform because the actual workflow is distributed. Governance therefore needs to treat AI-assisted development as a set of contexts, not one monolithic application, and align controls to where prompts, code, and secrets can move.

Practical implication: map AI tool usage by task and environment so policy can follow the workflow rather than the vendor list.

What code-level assurance changes in CI/CD

Code-level assurance shifts the control point from who used which AI tool to whether the resulting code meets security and quality thresholds before merge or release. That matters because even fully sanctioned AI use can still produce insecure patterns, duplicated logic, or hidden dependency risk. A CI/CD control layer can inspect changes consistently, independent of whether the source was Copilot, ChatGPT, Claude, or a personal account. This is the architectural response to shadow AI: govern the artefact, not just the access path.

Practical implication: integrate automated code assurance into the pipeline so every AI-generated change is evaluated before it reaches production.

Threat narrative

Attacker objective: The practical objective is not classic intrusion but uncontrolled movement of sensitive code, patterns, or data into production through unmanaged AI-assisted workflows.

1. Entry occurs when developers access AI tools through personal accounts or unmanaged channels, bypassing corporate identity and policy controls.
2. Escalation follows when fragmented tool usage introduces inconsistent handling of prompts, code, and sensitive context across the development workflow.
3. Impact emerges when ungoverned AI-generated code enters production pipelines without consistent provenance, review, or security validation.

NHI Mgmt Group analysis

Shadow AI is becoming a governance problem before it becomes a tooling problem. The article shows that developers are not waiting for central approval to use AI in daily work, and that means governance based only on sanctioned tools will miss a large share of real usage. The decisive issue is not whether the organisation approved the platform, but whether it can govern the code and context produced through unmanaged accounts. Practitioners should treat shadow AI as a provenance and accountability gap, not a procurement gap.

Code provenance is now an identity control as much as a software control. When personal accounts generate production code, the organisation loses the clear line between authenticated user, approved workflow, and resulting artefact. That creates a control gap that belongs in the same conversation as IAM, secret handling, and CI/CD policy enforcement. The field needs to recognise that identity governance is extending into software creation, and code assurance becomes part of the identity perimeter.

AI tool fragmentation creates a new named risk: governance by exception drift. This is the pattern where each tool, task, and account is treated as a separate policy exception until no coherent control model remains. Developers using four tools on average is not just a usage statistic, it is a signal that governance assumptions built around one platform no longer hold. Organisations should move toward output-based controls that can survive multi-tool workflows.

Shadow AI will pressure security teams to redefine acceptable use around outcomes, not just access. The article makes clear that controlling access to a single approved AI service will not eliminate AI-assisted risk if developers can still route around it. That means security programmes need to focus on what leaves the workstation and enters the pipeline, including prompts, generated code, and embedded secrets. The category is moving toward evidence-based enforcement, which aligns with NIST CSF and secure SDLC thinking.

AI-assisted development is pushing IAM teams into adjacent governance territory. The identity question is no longer limited to human logins and SaaS access. It now extends to who can use which accounts, under what context, and with what traceability when code is generated outside managed channels. That makes identity policy, software delivery governance, and data handling inseparable in modern engineering environments.

What this signals

Shadow AI will push more security teams toward evidence-based governance inside delivery pipelines, because account approval alone cannot explain what code was generated, where sensitive context moved, or whether the output was reviewed before release. The practical challenge is to align AI use policy with software assurance controls so that productivity gains do not outpace traceability.

Code provenance drift: this is the condition where the organisation can no longer reliably tie generated code back to an authenticated, governed workflow. Once that happens, identity policy, data handling, and secure SDLC controls need to converge around the CI/CD boundary. Security leaders should expect more scrutiny on how AI-generated code is validated, not just which tools are allowed.

The most immediate programme signal is that developer experience and control design now have to coexist. Teams that block unmanaged AI entirely may simply drive usage underground, while teams that ignore it will lose visibility into data exposure and code risk. The better path is to pair sanctioned access with pipeline enforcement and clear data-use rules.

For practitioners

• Inventory AI tool usage by workflow Map which AI tools are used in IDEs, browsers, documentation, refactoring, and code review, then distinguish sanctioned from personal-account usage so policy matches actual behaviour.
• Enforce code-level assurance in CI/CD Add automated checks for security, quality, and provenance on every commit and merge, so AI-generated code is governed before release regardless of the source account.
• Tighten account provenance controls Require corporate identities for approved AI services where possible and log the account context used for code generation to preserve auditability and incident response evidence.
• Define policy for personal-account AI use Set clear rules for when personal AI accounts are prohibited, what data can never be shared, and how exceptions are approved and monitored in engineering teams.

Key takeaways

• Shadow AI is a code governance problem because developers are already using personal accounts and multiple AI tools outside central oversight.
• The evidence points to a governance gap at the output layer, where code provenance and review matter more than tool approval alone.
• Security teams should move enforcement into CI/CD, where provenance, quality, and sensitive-data checks can still shape what reaches production.

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.
• Code provenance: Code provenance is the verifiable history of where code came from and who or what created it. In security practice, it combines authorship, timestamps, signatures, and build lineage so teams can prove a change was trusted before it reached production.
• Bring Your Own AI: Bring Your Own AI describes employees using personal or self-selected AI tools for work rather than relying only on corporate offerings. The pattern matters because it fragments oversight, complicates data handling, and weakens the organisation’s ability to enforce consistent security and compliance controls.
• Code Assurance: Code assurance is the practice of validating that software changes meet security, quality, and policy requirements before release. In AI-assisted pipelines, it becomes a compensating control that evaluates the artefact itself, rather than assuming sanctioned tool access is enough to reduce risk.

What's in the full report

Sonar's full report covers the operational detail this post intentionally leaves for the source:

• The complete chapter data on developer AI tool preferences across GitHub Copilot, ChatGPT, Claude, Gemini, Cursor, and other assistants.
• The survey breakdown showing how personal-account usage varies by tool, team size, and developer seniority.
• The report’s discussion of how AI adoption affects technical debt, agentic workflows, and code verification bottlenecks.
• Chapter-level findings that help engineering leaders compare sanctioned deployment patterns with BYOAI behaviour.

👉 Sonar's full report covers the developer survey data, tool fragmentation patterns, and chapter findings on AI-assisted coding.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and identity lifecycle control. It helps security and identity practitioners build the governance discipline needed for modern engineering and AI-assisted workflows.