AI-generated code is widening secure SDLC gaps across every phase

At a glance

What this is: Arnica argues that AI-generated code is widening secure SDLC gaps because security controls still arrive too late for planning, design and code generation stages.

Why it matters: For AppSec and IAM practitioners, the key implication is that security now has to govern AI coding agents, code owners and review workflows before a pull request exists.

By the numbers:

• AI coding agents showed a 25.7% vulnerability rate across tested samples, according to Arnica.
• Fixing a bug in production can cost up to 100x more than catching it at design, according to Arnica.
• Arnica says 82% of findings point to developers who have already left, which complicates routing remediation to the right owner.

Context

AI-generated code changes the secure SDLC problem because controls designed for human-written code often assume a person will review, correct and own the output before release. When an agent produces a near-complete draft in one pass, the governance question shifts from catching defects at merge time to controlling what the agent can generate in the first place.

That matters most for application security, because the same lifecycle controls now have to cover requirements, design, coding, testing, deployment and maintenance. Where code generation is delegated to AI, AppSec teams also need to know which agent identity produced the change, which rules it followed, and whether the security owner is still current when findings are routed for remediation.

Key questions

Q: What breaks when AI agents are not governed at runtime?

A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.

Q: Why do AI-generated pull requests need different security handling than human-written code?

A: AI-generated changes are often broader, faster and less obviously traceable than human-written edits, so the security model has to account for agent identity, generation rules and automatic reproduction of insecure patterns. Human review alone does not reliably catch those issues early enough. The safer model is to govern the agent, then scan the output, then route findings to the current owner.

Q: How do teams know if SDLC security tooling is actually working?

A: It is working when findings are reduced to the issues that matter most, remediation happens without breaking releases, and secrets are blocked before they land in shared history. Useful signals include lower alert noise, faster safe fixes, and fewer privileged credentials embedded in code or pipeline configuration.

Q: What is the difference between AI-powered secure SDLC and traditional secure SDLC?

A: AI-powered secure SDLC adds automation and contextual analysis to standard secure development practices. Traditional secure SDLC relies more on manual review, fixed rules, and periodic checks. AI can scan code continuously, prioritise findings by context, and provide remediation guidance earlier in the workflow, which helps teams keep pace with modern release velocity and larger codebases.

Technical breakdown

Why AI coding agents move the control point earlier

Traditional SSDLC tooling assumes the main risk appears after code is written, so SAST, SCA and review gates can still intercept it. AI coding agents change that assumption by producing larger, more complete code drafts before a human opens a pull request. That means the control point shifts upstream to generation time, where security rules, prompt constraints and agent configuration files shape the output before code enters the repository. In practice, the issue is not just insecure code patterns. It is that the generation system itself becomes part of the software supply chain and must be governed as such.

Practical implication: Treat generation-layer policy as a security control, not a developer convenience feature.

How agent identity changes SDLC governance

Agent identity matters because a code change produced by an AI system is not the same as a change written directly by a developer. The organisation needs to know which agent generated the code, which workspace or bot identity committed it, and whether that identity has the right scope for the repository or environment. This is especially important when a cloud-based agent operates under a shared or opaque bot account, because ownership, accountability and exception routing all become less reliable. Identity governance now extends into the development toolchain, not just production access.

Practical implication: Separate agent identity from developer identity and bind each generated change to a traceable source identity.

Why traditional scans miss agentic application risks

Classic SAST and secrets scanning still matter, but they are not enough for agentic development. Many AI-specific failures are behavioural or architectural rather than purely syntactic, so they do not appear as simple code-pattern defects. Risks such as agent goal hijack, tool misuse, identity abuse, inter-agent communication failure and rogue agent behaviour are better understood as control-plane problems that must be addressed in design, configuration and runtime governance. The security model has to cover what the agent is allowed to do, not only what the code it emits looks like.

Practical implication: Add design-time and runtime controls for agent behaviour instead of relying on code scans alone.

Threat narrative

Attacker objective: The objective is to inject vulnerable or secrets-exposing code into the software supply chain while evading late-stage review controls.

1. Entry occurs when an AI coding agent is allowed to generate code from insecure or poorly governed instructions, turning the development workflow itself into the attack surface.
2. Credential and secret exposure follow when the generated code, agent context or repository material reproduces credential-shaped data or unsafe access patterns.
3. Escalation happens when insecure generated code reaches review or deployment with insufficient phase-specific controls, letting risky logic persist into production pathways.
4. Impact is insecure software, leaked secrets and misrouted remediation ownership across the secure SDLC pipeline.

Breaches seen in the wild

• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
• 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.

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

Agentic SDLC governance is now a core application security problem, not an AI novelty. The article shows that code generation, review routing and security ownership are now interdependent control points. Once an agent can draft most of the change, the old assumption that security can wait for PR review no longer holds. Practitioners should treat the agent as part of the delivery pipeline and govern it accordingly.

Secure SDLC checklists must move from phase coverage to phase enforcement. Arnica's checklist is valuable because it frames security by lifecycle stage, not by a single scanning event. That is the right model for AI-generated code, where requirements, design, coding and deployment each introduce distinct failure modes. The practitioner conclusion is that phase-specific controls need to be measurable, attributable and enforced before merge.

Identity sprawl now includes the software delivery toolchain. AI coding agents behave like non-human participants that can create code, open changes and inherit enough context to influence outcomes. That creates an identity governance issue alongside an AppSec issue, because access, attribution and ownership all depend on knowing which agent acted. Security teams should extend NHI thinking into development workflows where bot identities and agent permissions already shape production risk.

Generation-layer policy is the named control gap this article exposes. Security teams have spent years optimising post-generation scanning, but AI coding agents can bypass that timing model by emitting vulnerable logic before the PR exists. The gap is not just detection latency. It is the absence of enforceable rules at the moment code is generated. Practitioners should move policy into the agent configuration layer and make generation a governed event.

Application security programmes now need remediation routing that survives organisational churn. The article's point about stale code owners shows that control failure is not limited to finding vulnerabilities. The bigger operational risk is sending findings to the wrong human or leaving them with no accountable owner. Teams should align AppSec triage with current ownership and active code stewardship, not historical repository metadata.

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 Coding Agents Security Guide

What this signals

Generation-layer policy is becoming the new AppSec control plane. Security teams that continue to focus only on scan results will miss the point of AI-assisted development. The relevant control boundary is shifting into the agent configuration layer, where code is shaped before it is even eligible for review.

AI coding agents create a governance problem as much as a coding problem. Once a non-human actor can generate production-bound code, the programme has to answer who owns the output, who approved the rules and who receives the finding when the original owner is no longer active. That is an identity and lifecycle issue as much as an application security issue.

For practitioners

• Define security controls by SDLC phase Map requirements, design, coding, testing, deployment and maintenance to explicit security gates so each phase has a named control owner and acceptance criterion.
• Enforce rules inside agent configuration files Write security policy into the agent settings or instruction files that AI coding tools read before generating code, and review those files as governed artefacts.
• Track agent identity separately from developer identity Record which AI agent or bot identity produced a change, then route findings against the active owner rather than the original committer when remediation is required.
• Scan AI-generated code before merge Run SAST, SCA and secrets checks on AI-generated pull requests at creation time so insecure output is challenged before reviewers treat it as finished work.
• Review code ownership for stale routing Check whether findings still map to current engineers or teams, because ownership drift can leave security issues unresolved even when scans are working.

Key takeaways

• AI-generated code widens secure SDLC gaps because late-stage scanning cannot compensate for insecure output produced earlier in the pipeline.
• The strongest control shift is toward generation-time governance, where agent rules, identity and phase-specific gates can still shape the change before review.
• AppSec teams now need to track current ownership and AI agent activity together, because remediation fails when findings route to stale code owners.

Key terms

• Agentic Development Lifecycle: The Agentic Development Lifecycle is the control pattern for building, approving, deploying, and reviewing AI agents before they reach production. It extends software change discipline into identity governance by requiring traceability for creation, access grants, business purpose, and ongoing oversight.
• Generation-Layer Governance: Generation-layer governance is the set of controls applied before code reaches a pull request or review queue. It constrains what an AI agent can produce, which rules it must follow and how its output is attributed, making the creation step itself a security control point.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Secure SDLC: A Secure SDLC is a software development process that embeds security into each lifecycle phase instead of treating it as a final check. It requires requirements, design, code, testing, deployment, and maintenance to all include controls that reduce vulnerabilities, supply chain exposure, and release-path abuse.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and workload identity for teams extending identity controls into development workflows. It gives security and engineering leaders a common model for governing non-human actors across modern delivery pipelines.