TL;DR: AI coding assistants are driving 3 to 4 times more commits and more than 10 times as many OSS and SAST findings in Fortune 20 environments, according to Apiiro's analysis, while traditional review and scanning workflows struggle to absorb the volume. The governance problem is no longer code generation alone, but how to enforce runtime-aware, policy-based decisions before risky changes reach production.
At a glance
What this is: AI-assisted coding is increasing developer throughput faster than AppSec review and scanning can handle, creating a backlog of findings and risk decisions.
Why it matters: AppSec, IAM, and platform teams need controls that evaluate code changes with runtime and policy context, because volume alone no longer separates low-risk change from business risk.
By the numbers:
- Developers using AI assistants produced 3-4× more commits in Apiiro's Fortune 20 analysis.
- Security findings spiked over 10× in Apiiro's Fortune 20 analysis, especially as AI-assisted changes consolidated into larger pull requests.
Context
AI-assisted development changes the security problem from a slow stream of human-written code to a much faster flow of changes that still has to be reviewed, governed, and traced to risk decisions. In AppSec terms, the challenge is not only more code, but more code created with weaker provenance, larger pull requests, and more pressure on existing review gates.
That matters to identity and access programmes because the same development pipelines now depend on service identities, secrets, policy enforcement, and runtime controls to decide what can safely reach production. When the governance layer cannot keep pace, teams lose the ability to distinguish a harmless change from one that expands exposure, weakens controls, or introduces unvetted dependencies.
Key questions
Q: What breaks when AI-assisted coding outpaces AppSec review cycles?
A: Manual triage and blanket scanning lose effectiveness when code volume rises faster than security capacity. Findings arrive after the most useful decision point, so teams need controls that influence code generation and prioritisation earlier in the workflow.
Q: Why do AI-generated code changes increase application security risk?
A: AI-generated code can increase risk because it accelerates output faster than review, testing, and secret hygiene can keep up. The issue is not only flawed logic. It is also the possibility that tokens, credentials, unsafe dependencies, or insecure defaults are reproduced at scale across the delivery pipeline.
Q: How can AppSec teams tell whether their controls are keeping pace with AI delivery?
A: Look for signals such as shrinking triage backlog, faster validation cycles, and a complete inventory of AI-enabled features, endpoints, and data flows. If the team can explain the security impact of a new release before it reaches production, the control plane is keeping pace. If not, the programme is already behind.
Q: Should security leaders rely on scanners or runtime-aware guardrails first?
A: Runtime-aware guardrails should come first when AI is increasing the pace of change, because scanners alone cannot decide what matters in the live architecture. Scanning remains useful, but it works best after policy and runtime context have already narrowed the problem set.
Technical breakdown
Why AI-assisted code changes break review-scale assumptions
AI coding assistants change the scale and shape of delivery. A team does not just receive more commits, it receives larger and more complex pull requests, which reduces the usefulness of manual review as a primary control. Static scanners still matter, but they were never designed to absorb a sudden jump in code volume while also separating noisy findings from issues that are actually exploitable in the current runtime. The result is control friction, not just tool overload.
Practical implication: Shift from human-only review gates to policy-driven triage that prioritises exploitable change over raw finding count.
How provenance and runtime context change the risk decision
Code provenance tells you where a snippet came from, but not whether it is safe in your architecture. AI-generated or AI-suggested code can duplicate existing functionality, introduce a risky dependency, or create a control gap that only appears once the code runs behind specific gateways, IAM controls, or compensating safeguards. That is why context matters more than isolated code analysis. Security decisions need to factor in exposure, existing controls, code ownership, and accepted risk, not just whether a rule fired.
Practical implication: Tie code review to runtime context and policy so teams can suppress irrelevant findings and escalate only material risk.
Why IDE-level guardrails are becoming the new control point
If AI is accelerating change at the point where developers write code, then security has to move earlier as well. IDE-level guardrails let policy checks, autofix suggestions, and risk acceptance logic happen before risky code spreads across branches, scanners, and approval queues. That does not eliminate downstream review, but it does reduce the load that reaches it. In practice, the control shifts from detecting problems after they are committed to shaping the change before it becomes expensive to govern.
Practical implication: Embed policy checks and safe remediation guidance in the developer workflow so security decisions happen before merge, not after release.
Threat narrative
Attacker objective: The practical attacker objective is to get risky code, unsafe dependencies, or exposed secrets into production faster than review and governance controls can stop them.
- Entry occurs through AI-assisted code generation or suggestion inside normal developer workflows, where the change is treated as ordinary engineering output rather than a governance event.
- Credential, dependency, or design risk is introduced when the generated code brings in unvetted libraries, exposes secrets, or weakens controls that static review does not fully contextualise.
- Escalation happens when larger pull requests and higher commit volume overwhelm manual review and scanner triage, allowing material issues to move forward with insufficient scrutiny.
- Impact is a faster accumulation of exploitable code-level risk, longer remediation queues, and weaker confidence that accepted changes align with runtime policy and business exposure.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
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 has turned AppSec into a scale problem before it is a code-quality problem. The article's strongest signal is not that AI creates new categories of bugs, but that it multiplies change faster than existing review and scanning models can absorb. When output volume rises 3 to 4 times and findings spike more than 10 times, the governance issue becomes throughput control, not just vulnerability management.
Provenance is now part of the security decision, not a nice-to-have audit trail. Once code is generated or transformed by AI, the security team can no longer rely on authorship alone to judge intent or quality. The real question is whether the change can be trusted in the context of the application's runtime, compensating controls, and policy posture.
Runtime-aware policy is the only way to separate noise from risk at AI speed. Generic scanners and checklists still identify defects, but they do not decide which findings matter in a specific environment. That creates a new governance burden for application security, because policy must be evaluated against blast radius, exposure, and accepted risk before remediation queues fill up.
Contextual AppSec debt: the growing gap between code creation speed and the organisation's ability to assign, assess, and act on security findings with runtime context. This is the durable concept the article surfaces, and it will define whether AppSec becomes a delivery enabler or a bottleneck. Teams that cannot evaluate risk in context will accumulate debt faster than they can burn it down.
For IAM and PAM teams, the intersection is real even when the article is not about identity itself. AI-assisted development depends on service identities, secrets, approvals, and runtime access paths to move code into production. If those identity controls are not reflected in the policy engine, AppSec decisions stay blind to the permissions that actually make a change dangerous.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Agentic AI Security Guide
What this signals
Contextual AppSec debt: AI-assisted development creates a widening gap between the speed of change and the organisation's ability to evaluate that change with the right runtime context. That gap is now a governance issue, not just a tooling issue, because findings only matter when they can be tied to exposure, policy, and accepted risk.
AppSec leaders should expect the control plane to move closer to the developer workflow. The practical test is no longer whether a scanner found something, but whether the organisation can make a fast and defensible decision before the change is merged and multiplied across the SDLC.
For practitioners
- Embed policy checks in the IDE Move security guidance to the point of change so risky code is flagged before it enters pull request queues and review backlogs.
- Prioritise findings by runtime context Rank issues using exposure, compensating controls, ownership, and blast radius so teams spend time on exploitability rather than raw scanner volume.
- Measure developer trust in autofix Track acceptance rates for suggested fixes in the IDE and pull request flow to see whether automated guidance is accurate enough to use.
- Tie security review to accepted risk Make risk acceptance explicit when a finding is real but not business critical, so governance records match the decision that was actually made.
Key takeaways
- AI-assisted development is increasing code throughput faster than traditional AppSec gates can review it, which turns security into a scale and prioritisation problem.
- The risk is not only more findings, but more findings without enough runtime context to distinguish harmless noise from exploitable change.
- Security teams need policy enforcement, provenance awareness, and runtime-aware triage at the point of change if they want to stay ahead of the backlog.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP SAMM, NIST CSF 2.0, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP SAMM | Threat Assessment — Threat Assessment | The article centres on adapting software security governance to faster AI-assisted code delivery. |
| Recommendation — Assess software security practices against AI-driven change velocity and update SDLC controls where review no longer scales. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | AI-assisted changes depend on the access and policy context that determines whether a change is safe to deploy. |
| Recommendation — Apply PR.AA-05 to ensure code changes and deployment paths reflect least-privilege access and enforced authorization. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article focuses on secure code change governance and architecture-aware remediation. |
| Recommendation — Use V15 to verify that code changes align with architecture and secure design before they reach production. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article addresses software security controls that need to keep up with developer productivity and AI assistance. |
| Recommendation — Strengthen application software security controls to catch risky changes earlier in the development lifecycle. | ||
Key terms
- Runtime-aware policy: Runtime-aware policy evaluates code changes against the environment where they will actually run, rather than judging them in isolation. It combines architectural context, exposure, compensating controls, and risk acceptance so teams can make decisions that reflect business impact, not only static code findings.
- Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
- Autofix: An automated remediation workflow in which a machine reviewer not only identifies an issue but also applies a code change. In practice, this shifts the tool from advisory review into delegated execution, which requires clear permission boundaries, auditability, and rollback controls.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect access, privilege, and governance decisions across modern security programmes.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org