AI-generated code is widening AppSec risk faster than controls

At a glance

What this is: This is a 2026 research report on how AI is changing software security, with the key finding that AI-generated code is already introducing vulnerabilities and incidents at scale.

Why it matters: It matters because AppSec, IAM, and platform teams now have to govern human and machine-produced code paths together, while keeping accountability clear when AI-assisted development changes the attack surface.

By the numbers:

• 69% of organizations found vulnerabilities introduced by AI-generated code
• 1 in 5 experienced a serious security incident linked to it
• Only 21% believe AI will ever write secure code without human oversight

👉 Read Aikido's 2026 State of AI in Security & Development report

Context

AI-generated code is now part of mainstream software delivery, but the governance model around it still assumes human review can keep pace with machine-assisted output. That assumption fails when development velocity increases, security tooling multiplies, and teams inherit more code than they can inspect effectively. The primary issue here is AppSec governance, with a real identity and access angle where AI-assisted workflows, developer permissions, and review accountability intersect.

The report’s value is not that AI can create risk, which most practitioners already expect, but that the operational failure is showing up in measurable incidents and control fatigue. When teams add more tools without reducing noise, they often get slower remediation rather than better security. That pattern is typical in modern software organisations, not an edge case.

Key questions

Q: How should security teams govern AI-generated code in production environments?

A: Security teams should treat AI-generated code as normal production code with extra provenance risk. Require architectural review, test coverage, static analysis, and approval before merge. Then bind the agent and the build pipeline to least privilege, short-lived credentials, and complete audit logging so implementation speed does not outrun control.

Q: Why do more security tools sometimes increase incident risk?

A: Because more tools often create more queues, more false positives, and more handoffs. When engineers lose trust in alerts or have to wait across multiple systems, they bypass controls or ship before issues are fully resolved. The risk is not coverage alone, but delayed and fragmented decision-making.

Q: What breaks when developer experience is poor in AppSec?

A: Poor developer experience breaks compliance behaviour. If security checks are noisy, slow, or hard to understand, engineers work around them to keep delivery moving. That produces shadow fixes, inconsistent reviews, and weaker assurance than the programme thinks it has.

Q: Who should own policy for AI coding agents in production?

A: Policy ownership should sit with platform security, IAM, or a dedicated security engineering team, not with individual developers. The reason is accountability: the same team that governs privileged human access should also govern agent tool use, version policy, review audit logs, and approve exceptions. That keeps the authorization model consistent across identities.

Technical breakdown

Why AI-generated code introduces new AppSec failure modes

AI-generated code changes the security baseline because it can reproduce insecure patterns at machine speed and scale. The issue is not that the model is malicious, but that it can generate code paths that look plausible to developers while embedding weak input handling, unsafe defaults, or inconsistent validation. In practice, this creates a mismatch between code production and security review capacity. Security teams are then forced to inspect larger volumes of change with the same approval and scanning workflows they used for human-written code. That gap is why vulnerability introduction rises even when teams believe their guardrails are intact.

Practical implication: treat AI-assisted code as a distinct source of AppSec risk and add review and testing controls that assume higher change velocity.

How tool sprawl increases incidents and slows remediation

Tool sprawl usually means too many overlapping scanners, policy engines, ticketing steps, and dashboards operating without a shared decision model. Instead of reducing risk, this often fragments triage and increases false positives, so engineers learn to ignore alerts or bypass controls to keep delivery moving. That behaviour matters because response speed drops when no one trusts the signal. In a mature programme, the control problem is not just coverage, but orchestration and prioritisation. If every tool produces a separate queue, the organisation ends up with more friction and less effective remediation.

Practical implication: consolidate duplicated security workflows and measure whether each control actually shortens remediation, not just alert volume.

Why developer experience now shapes security outcomes

Developer experience has become a security control because security friction determines whether engineers follow the path designed by the platform team or work around it. High false positives, unclear ownership, and slow feedback loops encourage shadow remediation and inconsistent code review behaviour. That weakens both prevention and detection. The broader lesson is that AppSec governance cannot be separated from engineering workflow design. When developers are forced to choose between shipping and complying, compliance usually loses unless the secure path is the fastest path.

Practical implication: design controls around developer workflow friction, then verify that secure-by-default paths are actually the easiest route.

Threat narrative

Attacker objective: The attacker objective is to exploit weaknesses introduced into AI-generated software before the organisation can detect, triage, or patch them.

1. Entry begins when AI-generated code introduces insecure logic, weak validation, or unsafe dependencies into production pipelines.
2. Escalation occurs when fragmented tooling and noisy alerts delay review, allowing insecure code to move from pull request into deployed services.
3. Impact follows when the organisation absorbs vulnerabilities and incidents tied to code it cannot inspect or remediate fast enough.

NHI Mgmt Group analysis

AI-generated code has become an AppSec governance problem, not just a coding efficiency issue. The report shows that vulnerability introduction is now a measurable outcome of AI-assisted development, not a theoretical concern. That changes the unit of control from individual developer judgement to policy, review depth, and workflow assurance. Practitioners should treat AI-generated code as a governed input to the software supply chain, not as a neutral productivity aid.

Tool sprawl is creating a security latency problem. More scanners and dashboards do not automatically produce better control if they slow triage and increase alert fatigue. The finding that teams with more tools were more likely to suffer incidents suggests that fragmentation is eroding response quality. For AppSec leaders, the question is whether the control stack reduces decision time or simply adds administrative overhead.

Developer experience is now part of the control plane. When security checks are noisy or slow, engineers create workarounds, and those workarounds become governance failures. This is where IAM and AppSec intersect: permissions, approval paths, and deployment rights all influence whether security controls are actually followed. The practical conclusion is that secure workflows must be operationally faster than unsafe shortcuts.

Human oversight remains the operating assumption that AI has not eliminated. Only 21% of respondents believe AI will ever write secure code without human oversight, which signals broad practitioner scepticism about automation replacing review. That is not a rejection of AI in development; it is a recognition that code-producing systems still need accountability boundaries. Teams should therefore govern AI use as an augmentation layer with explicit review ownership.

What this signals

AI-assisted development is forcing security leaders to move from control counting to control effectiveness. The practical signal is whether your AppSec workflow shortens remediation, reduces false positives, and keeps developer friction low enough that people actually use the controls. Where those signals are missing, the programme is likely adding complexity faster than it is reducing risk.

Code governance drift: this is the pattern where the organisation believes it has review and scanning in place, but those controls no longer match how code is produced. That drift matters for IAM-adjacent teams too, because deployment rights, service account permissions, and pipeline access all affect whether insecure code can reach production. Mature programmes should link code governance with least privilege and workflow telemetry, then confirm that the secure path is the default path.

For practitioners

• Separate AI-assisted code paths from standard review workflows Tag AI-generated or AI-assisted commits so they receive targeted testing, higher-risk review, and stronger dependency checks before merge. This makes it easier to measure whether the secure path is actually being followed.
• Collapse duplicate security tooling into fewer decision points Inventory scanners, policy gates, and ticket queues that serve the same purpose, then remove overlaps that create delayed triage and repeated false positives. The goal is faster closure, not more alerts.
• Measure remediation time, not tool count Track how long it takes to move from finding to fix, then compare that with the number of controls in the path. If more tools correlate with slower remediation, the programme is optimising for coverage instead of effectiveness.
• Assign explicit accountability for AI-assisted changes Make one named owner responsible for accepting risk when AI tools generate code that reaches production. This prevents shared-accountability gaps where no one can explain why an insecure change was approved.

Key takeaways

• AI-generated code is already introducing vulnerabilities at a scale that makes AppSec governance a live operational issue.
• More security tooling can worsen outcomes when it adds friction, false positives, and slow handoffs instead of reducing remediation time.
• Teams need explicit ownership, workflow-aware controls, and measurable remediation outcomes if they want AI-assisted development to stay governable.

Key terms

• AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
• Tool Sprawl: Tool sprawl is the accumulation of overlapping systems that each solve part of the same identity or operations problem. In practice, it creates duplicate workflows, inconsistent policy enforcement, and more manual reconciliation, which weakens confidence in access decisions and slows down secure scaling.
• Developer experience: Developer experience is the practical ease of discovering, understanding, and safely using an API. In governance terms, it affects whether teams follow the approved path or create workarounds, which means usability directly influences access sprawl and control adherence.
• Remediation Period: A remediation period is the time after a gap analysis when an organisation fixes the deficiencies discovered during readiness work. It often consumes the most effort because it requires process changes, evidence generation, and validation that the control now operates consistently.

What's in the full report

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

• Breakdowns by role group across 450 security leaders, developers, and AppSec engineers so you can compare your own operating model.
• The report’s practitioner commentary on how AI-generated code, false positives, and incident response interact in real development teams.
• Examples of how security teams can reduce noise without slowing engineering delivery, which is more useful at implementation stage than high-level trend data.
• The report’s summary of what leading teams do differently when tool sprawl starts affecting incident rates.

👉 The full Aikido report covers the survey breakdown, practitioner commentary, and operational implications in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle thinking that complements broader security programmes. It is designed for practitioners who need to connect identity controls to real operational risk across modern environments.