TL;DR: AI coding assistants can materially increase productivity while expanding code, dependency, and API sprawl, according to Apiiro’s analysis of thousands of repositories, with Copilot-active repositories showing 43% more OSS packages per commit and a 40% rise in API surface over six months. The governance problem is no longer adoption itself, but whether security teams can inventory, gate, and remediate AI-amplified change fast enough.
At a glance
What this is: Apiiro’s research argues that AI-assisted coding can accelerate delivery while widening OSS and API attack surface faster than security review can keep up.
Why it matters: For IAM, PAM, and adjacent security programmes, the lesson is that faster code generation changes the pace of dependency governance, authorization enforcement, and control validation across development pipelines.
By the numbers:
- Copilot-active repositories show 43% more OSS packages per commit than repositories without Copilot usage.
- Between June and October 2025, API surface records grew from 54,627 to 79,630, representing roughly a 40% increase in attack surface in under six months.
- Apiiro reports that AI-assisted teams shipped 10x more security findings in code than non-assisted teams.
👉 Read Apiiro’s analysis of AI coding assistants, OSS sprawl, and API attack surface growth
Context
AI-assisted development is changing the security problem from a static code review challenge into a living governance problem. The primary issue is not whether copilots make developers faster, but whether that speed creates more endpoints, dependencies, and authorization paths than security teams can inventory and control. In this article, the primary identity angle is indirect but real: every new service, API, and dependency expands the places where human and non-human identities, tokens, and authorization checks must be enforced.
The article’s core claim is that productivity gains do not automatically translate into lower risk. Instead, AI assistance can amplify software sprawl, especially where teams lack a governed approved-library model, runtime inventory, and policy enforcement in the development workflow. That is a familiar pattern in identity governance: when change velocity outruns control visibility, access and entitlement drift become structural rather than exceptional.
Key questions
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.
Q: Why do AI coding assistants increase AppSec governance risk?
A: They increase risk because they optimise for speed and plausible output, not for context-aware security validation. In practice, that means developers can accept more code with less scrutiny, which raises the chance of vulnerable functions, exposed secrets, and compliance failures entering the repository and CI/CD pipeline.
Q: What breaks when organisations do not maintain a complete API inventory?
A: Unknown and stale endpoints stay reachable, which means security controls, logging, and retirement processes miss part of the attack surface. Teams lose sight of which versions still accept credentials, which test interfaces remain exposed, and which business flows have never been formally reviewed.
Q: How do organisations reduce the impact of AI-driven dependency sprawl?
A: Contain it early with approved-path catalogues, commit-time policy checks, and automated remediation for repetitive violations. In parallel, use reachability analysis so the highest-risk issues rise first. That combination reduces noise while preserving developer speed and improving governance accuracy.
Technical breakdown
Why AI coding assistants increase API and OSS sprawl
AI coding assistants optimise for the fastest plausible code path, not the most governable one. In practice, that means they often suggest new libraries, duplicate functions already present in the organisation, or create fresh endpoints instead of reusing approved patterns. Each new dependency adds a subtree of transitive packages, and each new endpoint adds another access surface that must be authenticated, authorised, monitored, and tested. The result is not just more code, but more control points that security teams must understand before they can secure them.
Practical implication: build an inventory-first workflow that detects net-new packages and endpoints before code reaches review.
What shadow APIs and duplicate libraries change in governance
Shadow APIs are endpoints that exist in code but are not fully documented, routed, or protected through standard controls. Duplicate libraries create a different form of governance debt because teams end up maintaining multiple implementations of the same function, which spreads patching work and increases the chance of inconsistent security behaviour. From a control perspective, this is a visibility problem first and a vulnerability problem second. If the inventory is incomplete, policy enforcement and remediation will always lag behind development output.
Practical implication: enforce a golden-path catalogue for approved APIs and dependencies, then block or flag deviations automatically.
How prompt-level guardrails reduce downstream remediation load
The article points to a shift left in security feedback, but the important detail is where the feedback lands. Controls at the prompt, IDE, and pull request stages can stop risky dependency choices before they become remediation work. This is especially important because AI-generated code tends to scale errors quickly across teams. Once the same unapproved library or pattern is repeated across many repositories, the cost of correction becomes architectural rather than local.
Practical implication: add policy-as-code checks and justification gates at commit time, not after merge.
NHI Mgmt Group analysis
AI-assisted code sprawl is becoming an access-governance problem, not just a software hygiene problem. Every new API endpoint and dependency creates new places where authentication, authorisation, secrets, and service identities must be governed. That means the blast radius of poor development choices now extends into IAM and NHI controls, especially where applications rely on tokens, service accounts, and automated delivery chains. Practitioners should treat code sprawl as an entitlement sprawl precursor.
Inventory-first security is the named control gap this article exposes. The central failure mode is not a lack of scanning tools, but the absence of a continuously current system of record for APIs and OSS packages. Without that inventory, security teams cannot know what to gate, what to monitor, or what to retire. The article’s evidence supports a broader conclusion: governance breaks when discovery is manual and change is automated. Practitioners should make discovery continuous, not periodic.
Prompt-time enforcement will matter more as AI-generated code becomes routine. Waiting until post-merge review means the organisation has already accepted the risk of sprawl. The better operating model is to constrain the developer moment with approved alternatives, dependency justifications, and policy-as-code. That approach aligns with NIST-CSF and control families that depend on timely, enforceable configuration discipline. Practitioners should move enforcement upstream into the tools developers already use.
Code acceleration changes the economics of remediation faster than most teams expect. If AI assistants can drive higher commit volume and more dependencies per commit, then manual triage becomes a structural bottleneck. Security teams must assume that review capacity will not scale linearly with development velocity. That shifts the programme toward automation, reachability analysis, and refactoring support. Practitioners should prioritise controls that reduce remediation volume rather than only increasing detection volume.
What this signals
AI-assisted development is pushing security teams toward continuous control validation rather than periodic review. The organisations that adapt fastest will be those that treat inventory, policy, and remediation as pipeline functions, not downstream assurance tasks.
Inventory drift: when code generation outpaces discovery, the organisation loses the ability to distinguish approved architecture from accidental sprawl. That creates governance debt that compounds across application security, secrets management, and identity enforcement.
For practitioners, the immediate planning question is not whether to allow AI coding assistants, but how to absorb their output without multiplying unmanaged dependencies. That means integrating policy checks, approved standards, and automation into the developer path itself.
For practitioners
- Implement continuous inventory for APIs and OSS packages Create a live system of record for endpoints, dependencies, and service relationships so new code cannot outpace visibility. Tie the inventory to build pipelines and require it to update before merge.
- Enforce approved-library paths in the developer workflow Publish a golden-path catalogue for common functions such as HTTP clients, logging, and serialization, then flag or block alternative packages when AI suggestions diverge from approved standards.
- Add dependency justification gates to CI/CD Require a human explanation when a pull request introduces net-new packages, duplicate implementations, or high-blast-radius libraries. Use the gate to slow unnecessary duplication before it becomes permanent sprawl.
- Move vulnerability triage toward reachability analysis Prioritise vulnerabilities that are actually reachable in the application execution path rather than treating every package alert equally. This reduces noise when package counts rise faster than remediation bandwidth.
- Automate remediation for repetitive dependency drift Use security automation to generate fix pull requests for duplicate libraries and obvious policy violations so teams spend less time manually cleaning up AI-generated variance.
Key takeaways
- AI coding assistants can improve delivery speed while still increasing security workload by expanding dependencies, endpoints, and review burden.
- The most important control gap in the article is inventory drift, because teams cannot govern what they cannot continuously see.
- Security programmes need to move enforcement upstream into the developer workflow, where AI-generated variance can be blocked or remediated earlier.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Expanded code paths create more access-control points that need governance. |
| CIS Controls v8 | CIS-07 , Continuous Vulnerability Management | Sprawl increases the volume and priority of vulnerabilities to manage. |
| NIST SP 800-53 Rev 5 | CM-8 | Configuration management depends on knowing every component in the environment. |
| MITRE ATT&CK | TA0007 , Discovery; TA0009 , Collection | Discovery and collection are relevant to understanding how exposed code paths increase attack surface. |
Map exposed code paths and dependency sprawl to discovery and collection risks during threat modelling.
Key terms
- API Authentication Surface: The API authentication surface is the set of login, token, and session endpoints that establish identity for an application. It is where identity governance becomes operational, because attackers can abuse the same endpoints that legitimate users and services rely on for access.
- OSS Sprawl: Uncontrolled growth in open source dependencies, often including multiple packages that solve the same problem. It increases patching burden, creates inconsistent security behaviour across teams, and makes it harder to understand which libraries are actually in use.
- Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
What's in the full report
Apiiro’s full research covers the operational detail this post intentionally leaves for the source:
- Repository-level methodology across 26.5K repositories, 14K developers, and 4.7M OSS package records
- The Copilot-versus-non-Copilot comparison tables for commits, developers, packages, and packages per commit
- Detailed examples of package duplication patterns across HTTP, serialization, cryptography, and logging libraries
- Implementation guidance for inventory-first security, prompt-level guardrails, and automated remediation
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle controls. It helps security and identity practitioners translate governance principles into operational controls across modern development and runtime environments.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
