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 analysis says AI coding assistants increase engineering throughput but also widen API and open-source attack surface through faster dependency growth, more endpoints, and more duplicate packages.
Why it matters: For IAM and security teams, the point is that AI-assisted delivery changes the control problem from static review to continuous inventory, entitlement-like governance over libraries and endpoints, and faster remediation of net-new exposure.
By the numbers:
- Copilot-active repositories have 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.
- Apiiro’s analysis covered 26.5K repositories, 14K developers, 4.7M OSS package records, and nearly 80,000 APIs in code.
Context
AI coding assistants reduce the cost of producing code, but they also reduce the friction that usually slows dependency growth, endpoint creation, and variation across teams. In practice, that means more surface area is created before security teams can inventory it, classify it, or decide whether it belongs in the approved architecture.
The identity angle is real even though the article is primarily about software sprawl. Every new API endpoint, library, and build-time dependency expands the control problem around access, authorization, and software supply chain governance, which is why this belongs in broader NHI and application security conversations.
The starting position described here is not unusual. Many organisations still rely on point-in-time scanning and developer discretion while AI-assisted coding increases the pace of change beyond what those controls were designed to handle.
Key questions
Q: How should security teams govern AI-assisted code that keeps adding new packages and APIs?
A: Treat AI-assisted code as governed change, not just developer output. Set a live inventory for APIs and dependencies, enforce approved-library policies in the IDE and pipeline, and require justification for net-new packages or routes. The goal is to stop sprawl before merge, because post-release review is too late to contain the growth in exposure.
Q: Why does AI-driven coding increase application security risk even when it improves productivity?
A: Because productivity gains increase change volume faster than teams can classify and review the resulting software. The risk is not merely more code, but more unknown code paths, dependencies, and data flows reaching production before ownership and exposure are clear.
Q: What are the signs that AI-generated code is creating unmanaged sprawl?
A: Look for rising dependency counts, multiple libraries doing the same job, new APIs that are not in the service catalog, and a growing gap between code changes and security review capacity. If teams are shipping faster while inventory confidence drops, the assistant is amplifying change faster than governance can absorb it.
Q: When should teams prioritise policy-as-code over manual approval handling?
A: Teams should prioritise policy-as-code when the same access request can be judged differently by different reviewers or at different times. If consistency, auditability, and repeatability matter, code-based policy becomes the more reliable control plane because it reduces drift and makes exceptions visible.
Technical breakdown
Why AI-assisted coding expands API and OSS surface area
AI coding assistants optimise for speed and local completeness, not architectural reuse or security policy. That means they often suggest new packages, alternate libraries, or fresh endpoints even when an approved internal option already exists. In software terms, the assistant is not merely drafting code, it is shaping the graph of dependencies and interfaces that defenders must secure. The result is more attack surface per unit of developer output, especially when teams do not have a strong internal service catalog or approved dependency list.
Practical implication: treat assistant output as a change to governed architecture, not just a developer productivity aid.
How dependency duplication turns into security and remediation debt
Duplicate packages create multiple implementation paths for the same function, such as HTTP clients, serialisation libraries, or cryptography utilities. That increases the number of libraries to patch, the number of transitive dependencies to inspect, and the likelihood that one variant will remain vulnerable or unmaintained. It also complicates testing, because remediation can break one code path while leaving another intact. The article’s main signal is that sprawl itself becomes a risk multiplier long before a specific CVE is exploited.
Practical implication: consolidate package choices early and make package variance a controlled exception, not a developer preference.
Why inventory-first control matters for shadow APIs and net-new dependencies
When code generation accelerates, security cannot depend on periodic scans alone. Continuous discovery is needed to identify undocumented APIs, newly introduced packages, and libraries that never went through standard review. This is especially important where application security posture management, build gates, and policy-as-code can block unsafe changes before merge. The technical issue is not just detection, but timing: if exposure is discovered after deployment, the organisation has already absorbed the cost of review, rollback, and remediation.
Practical implication: move visibility and policy enforcement into the IDE, pull request, and build stages.
Threat narrative
Attacker objective: The attacker’s objective is to exploit the enlarged software attack surface created by AI-assisted development to reach application compromise, dependency abuse, or data exposure.
- Entry occurs when AI coding assistants introduce new packages or endpoints directly into developer workflows, often before human review or architectural approval.
- Credential or trust abuse follows when duplicated libraries, undocumented APIs, or vulnerable dependencies become part of the shipped code path and inherit application trust.
- Escalation happens as the organisation accumulates more attack vectors, more transitive dependencies, and more remediation paths than the security team can manually manage.
- Impact is a larger and more brittle application surface, with higher patch burden, more reachable vulnerability exposure, and slower containment when defects are found.
Breaches seen in the wild
- Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
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
AI-assisted development is becoming an attack-surface generation problem, not just a productivity problem. The article shows that assistants are accelerating code, dependency, and endpoint creation faster than security teams can govern. That shifts the core question from whether teams should use AI to whether they can still control what AI causes to be built. Practitioners should treat AI-assisted code as governed supply chain change, not just faster authoring.
API sprawl and OSS sprawl are now the same governance problem viewed from two angles. New endpoints increase exposure, while new packages expand the dependency graph that must be patched, scanned, and justified. The important named concept here is assistant-amplified attack surface sprawl: a state where code generation velocity outpaces inventory, approval, and remediation. Security teams should assume the gap will widen wherever code review remains manual and inconsistent.
Identity and access governance still matter here, even though this is not an IAM-only story. Every dependency choice, build-time permission, and API route creates an access boundary that needs policy, ownership, and lifecycle control. In practice, AI coding assistants expose a familiar identity lesson: if the organisation cannot tell what exists, who approved it, and what it can reach, the control plane is already behind the change. Practitioners should align software supply chain governance with identity-style inventory discipline.
Security leaders should stop treating AI coding risk as a binary adoption decision. The article’s real implication is that controlled adoption can be safer than unmanaged resistance, but only if guardrails are embedded where code is proposed and merged. That means policy enforcement, approved libraries, and automated remediation must move closer to the developer moment. Teams that do this can absorb productivity gains without accepting unconstrained sprawl.
Manual triage is becoming structurally insufficient for AI-amplified code bases. When output rises faster than review capacity, the bottleneck is not detection, it is decision throughput. This is where programme design should shift toward automated justification, reachability analysis, and enforced standards for dependencies and APIs. Practitioners should redesign the operating model around scale, not hope for slower change.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: AI Security Platform Buyer's Guide
What this signals
Assistant-amplified attack surface sprawl: organisations need to treat AI coding output as a change-management and identity-governance issue, not only a developer productivity issue. When assistant-driven code introduces new packages and endpoints by default, the control point moves upstream to inventory, approval, and policy enforcement.
The strongest programmes will use continuous discovery, approved-library controls, and build-time policy to keep pace with code generation. That is where identity-style governance becomes useful in software security, because the organisation must know what exists, who approved it, and what it can reach.
For practitioners
- Implement inventory-first governance for code output Maintain a live system of record for APIs, libraries, and build-time dependencies so AI-generated changes are visible before they ship.
- Enforce approved-library policies in the IDE and pipeline Block net-new packages unless they match an approved list or pass an explicit justification workflow in pull request and build checks.
- Use automated reachability analysis for dependency findings Prioritise vulnerabilities that are actually reachable in the application path instead of opening manual triage tickets for every scan result.
- Detect and govern shadow APIs continuously Compare code-level endpoint discovery with gateway and WAF inventories so undocumented interfaces are flagged before release.
- Shift remediation to policy-as-code and fix generation Use build-time controls and automated fix PRs to handle redundant libraries, unsafe defaults, and non-compliant AI-generated code at scale.
Key takeaways
- AI coding assistants can improve throughput while still increasing software risk, because faster code generation tends to expand dependencies and endpoints faster than teams can govern them.
- The article’s evidence shows a clear sprawl pattern, including 43% more OSS packages per commit in Copilot-active repositories and rapid growth in API surface.
- The practical response is to move governance earlier, using live inventories, approved-library policies, and automated remediation instead of relying on manual review alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | AI-assisted code creation increases the chance of exposed secrets and risky dependency paths. |
| NHI-05 — Overprivileged NHI | New APIs and service paths can expand access scope beyond what teams intended. | |
| Recommendation — Scan assistant-generated changes for leaked credentials and block merges when secrets appear in code or configs. Review new service interfaces for excess access scope and restrict privileges to the minimum required. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Dependency abuse and exposed code paths are common routes to credential theft and data loss. |
| Recommendation — Map sprawl indicators to credential-access and exfiltration techniques in detection and threat-hunting workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about controlling what code and services are allowed to do. |
| Recommendation — Apply PR.AA-05 to govern API and dependency permissions as part of continuous change control. | ||
| CIS Controls v8 | CIS-2 — Software Inventory | Inventory is central because teams cannot govern what they do not track. |
| Recommendation — Maintain an authoritative software inventory for packages, APIs, and build outputs. | ||
Key terms
- API Surface Sprawl: The growth of live, exposed, and often under-inventoried APIs across applications, services, and integrations. It becomes a governance problem when security and ownership records cannot keep up with the rate at which new endpoints are created or changed.
- Approved Library List: A governed set of software packages that developers are expected to use unless a justified exception is approved. It reduces dependency duplication, limits unvetted libraries, and creates a consistent control point for patching, auditing, and policy enforcement.
- 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.
- Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that helps security teams connect identity control to broader software risk. It is a strong fit for practitioners who need to align governance across code, credentials, and access boundaries.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org