AI adoption is outpacing product security visibility and governance

At a glance

What this is: Cycode's research argues that AI adoption is moving faster than product security governance, with visibility and centralised control lagging behind near-universal AI use.

Why it matters: For IAM, NHI, and security teams, the concern is not AI adoption alone but the unmanaged identity, access, and supply-chain paths created when AI tools, models, and assistants enter development without governance.

By the numbers:

• 97% of organizations are already using or piloting AI coding assistants.
• Only 19% have full visibility into where and how AI is used.
• 52% of organizations admit they lack a centralized framework to manage AI adoption.
• 65% say their overall security risk has increased since AI adoption.

👉 Read Cycode's State of Product Security in the AI Era report on AI visibility and governance

Context

AI in software development now creates a governance problem as much as a productivity gain. When teams adopt coding assistants, plugins, and AI-generated code faster than they can inventory or review them, security loses visibility into data flows, tool provenance, and the points where output becomes production code.

The identity angle is real even though this is broader product security content. AI tools, AI assistants, and MCP connections behave like governed entities inside the software supply chain, which means access, delegation, and lifecycle control matter in the same way they do for other non-human identities. Cycode's findings show that many organisations are still treating this as a tooling choice rather than a control-plane issue.

Key questions

Q: What breaks when AI adoption outpaces governance?

A: What breaks first is attribution. Teams lose visibility into which tools are in use, which data they can reach, and which actions were taken automatically versus manually. Once adoption is ahead of control design, security teams end up retrofitting policy around live workflows instead of governing them from the start.

Q: Why do AI coding assistants create new security review risks?

A: They can produce code that looks correct but still contains weak authentication, unsafe data flows, or hidden secret handling mistakes. Because the output is generated by pattern completion rather than system understanding, review teams must validate intent and trust boundaries. The risk rises fastest where code touches identities, credentials, and deployment automation.

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: How should security teams govern AI-generated code in production pipelines?

A: Security teams should treat AI-generated code as a controlled identity event, not just a development artifact. Require human approval, traceable authorship, scoped workload identities, and evidence of intent before production promotion. The goal is to preserve provenance and limit blast radius when generated logic behaves unexpectedly.

Technical breakdown

Shadow AI in the SDLC: where visibility breaks down

Shadow AI emerges when developers adopt unapproved models, plugins, or assistants outside formal review. In software delivery pipelines, that means the organisation may not know which AI systems touch source code, what prompts or data they receive, or how their output is promoted into build and deployment steps. The problem is not just unapproved tooling. It is the loss of a stable inventory, which is the prerequisite for access control, auditability, and change governance.

Practical implication: maintain a complete AI and assistant inventory across the SDLC before treating AI output as trusted production input.

AI-generated code and software supply chain risk

AI-generated code changes the threat model because code may be syntactically correct but operationally unreviewed, inconsistently attributed, or built from opaque training patterns. That creates a supply-chain governance issue, not merely a code quality issue. Where AI systems are connected through MCP-style integrations or automation hooks, each connection widens the trust boundary and increases the number of places where content, dependencies, and approvals can be manipulated.

Practical implication: treat AI-assisted code paths as supply-chain dependencies and subject them to the same review and provenance checks as third-party components.

Centralised AI governance as a control plane

A centralised framework is the difference between managing AI use and merely observing it after the fact. The control plane needs to decide which tools are approved, what data they may access, where outputs may be used, and when exceptions expire. In practice, this mirrors identity governance principles: inventory, entitlement, oversight, and lifecycle. Without those controls, AI adoption fragments across teams and becomes impossible to secure consistently.

Practical implication: align AI governance with identity and change-management processes so approvals, exceptions, and reviews happen in one accountable framework.

Threat narrative

Attacker objective: The objective is to exploit unmanaged AI adoption to gain persistence in the software delivery chain and increase the chance that unsafe or manipulated output reaches production.

1. Entry occurs when developers or teams introduce AI tools, plugins, or assistants into workflows outside formal security review.
2. Escalation follows when those tools gain access to source code, prompts, or connected data sources and become embedded in build and deployment paths.
3. Impact is the introduction of untracked dependencies, opaque output into production, and broader software supply-chain exposure that security teams cannot reliably govern.

NHI Mgmt Group analysis

Shadow AI is becoming a governance category, not just an adoption problem. Organisations are no longer dealing with isolated experimentation when AI tools, plugins, and code assistants spread across teams. The missing control is centralised policy over tool approval, data access, and output handling. Without that, security cannot answer the basic question of what AI is doing inside the SDLC, which makes the environment ungovernable rather than merely risky.

AI-generated code creates a non-human identity problem inside product security. The article points to a reality where machine-authored output enters build systems, repositories, and release pipelines. That means the system generating the content, the integration moving it, and the workflow accepting it all need identity and lifecycle controls. In practice, this is where IAM, NHI governance, and software supply-chain security intersect, and teams should treat AI outputs as governed producers, not anonymous artefacts.

Centralisation is becoming the operational answer to AI sprawl. The research shows that organisations are planning stack consolidation because fragmented controls cannot keep pace with weekly tool churn. This aligns with NIST CSF and NIST SP 800-53 thinking on coordinated governance, but the deeper lesson is that security teams need one accountable control plane for inventory, approval, review, and exception management. Practitioners should expect AI oversight to converge with identity governance and supply-chain controls.

Product security teams should view AI governance debt as a measurable risk. The longer organisations let AI tools proliferate without policy, the more exceptions, orphaned integrations, and undocumented data paths accumulate. That debt eventually surfaces as review backlog, inconsistent approvals, and blind spots in code provenance. The practical conclusion is simple: every week of delay increases the cost of bringing AI use back under control.

AI visibility is now a prerequisite for defensible release decisions. The finding that only 19% of organisations have full visibility means most teams cannot reliably attest to what AI influenced a release. That matters for audit, incident response, and accountability. Practitioners should treat AI visibility as a release gate, not a reporting metric.

What this signals

AI governance is starting to look less like a policy exercise and more like an identity problem wrapped inside software delivery. When machine-authored code, assistants, and MCP-linked tools are moving through the SDLC, teams need inventory, ownership, and lifecycle control in the same way they would for any other governed non-human system.

Governance debt: the accumulation of unapproved tools, undocumented data paths, and unreviewed outputs now functions as a measurable security liability. Organisations that wait for full standardisation before enforcing control will inherit a larger exception backlog and weaker release assurance.

For practitioners, the near-term priority is to connect AI inventory to change management and identity governance. The NIST SP 800-53 Rev 5 Security and Privacy Controls model is useful here because the challenge is not only detection, but accountable control over what enters production and who can approve it.

For practitioners

• Build a complete AI asset inventory Catalog approved and unapproved models, copilots, plugins, and MCP connections across development, testing, and release environments. Tie each entry to an owner, data access scope, and review date so the inventory supports governance rather than becoming a static register.
• Gate AI-generated code on provenance checks Require review, attribution, and traceability for code produced by AI systems before it enters build or deployment pipelines. Where possible, separate human-authored and machine-authored changes so exceptions are visible during code review and incident response.
• Consolidate AI approval into one control plane Move tool approval, data-access rules, exception handling, and periodic review into a single governance process. This reduces fragmented decisions across teams and makes it easier to retire unapproved tools when their risk outweighs their productivity value.
• Map AI tools to software supply-chain controls Treat assistants, plugins, and integrations as supply-chain dependencies and subject them to the same change control, provenance, and monitoring discipline as external packages. Use the NHI Lifecycle Management Guide for lifecycle governance where access, rotation, or offboarding is involved.

Key takeaways

• AI adoption is ahead of security visibility, which leaves product teams unable to account for how machine-authored code enters production.
• The core issue is governance, because Shadow AI, fragmented approval, and opaque integrations create blind spots that conventional review processes do not close.
• Security teams need a single control plane for AI inventory, provenance, and exception handling if they want AI speed without losing release assurance.

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 Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
• AI Asset Inventory: A living register of every AI-related asset in an organisation, including models, agents, datasets, notebooks, endpoints, and embedded AI services. It links technical detail to ownership, data exposure, lifecycle status, and controls so governance can operate on facts rather than assumptions.
• AI-Generated Code Provenance: AI-generated code provenance is the ability to trace where generated code came from, how it was transformed, and what validation it passed before release. It matters because teams need evidence that machine-assisted code met the same policy expectations as hand-written code.

What's in the full report

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

• The full survey methodology behind the 97% adoption and 19% visibility findings.
• Breakdowns of how security and product teams are structuring AI governance in practice.
• Detailed examples of Shadow AI detection and AI/ML inventory approaches across the SDLC.
• The report's broader benchmark data on consolidation, budgets, and response priorities.

👉 Cycode's full report covers the benchmark data, governance patterns, and adoption breakdowns behind these findings.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and the control disciplines that matter when machine-authored systems enter production. It helps practitioners connect identity governance to the broader security decisions their programmes depend on.