TL;DR: AI-assisted development is collapsing the SDLC’s old pause points, and Checkmarx argues that AppSec controls built for pull requests and release gates no longer keep pace with continuous code generation and refactoring. The practical shift is toward in-line, policy-driven security that operates inside the development loop rather than after it.
At a glance
What this is: This is an analysis of why the Agentic Development Lifecycle makes SDLC-era application security controls less effective, because code is now generated and refactored continuously rather than in clear phases.
Why it matters: IAM and security teams should care because the governance problem is no longer post-change review alone, but how to enforce policy when AI-assisted development compresses the time available for human checkpoints.
Context
Application security controls were designed for a software lifecycle with pauses, handoffs, and review windows. AI-assisted development changes that operating model by making code generation and refactoring continuous, which weakens stage-based security review even when the underlying policies have not changed.
The identity angle is indirect but real: the more code is produced by AI systems and accepted by developers in-line, the more security decisions shift from episodic human approval to policy enforcement inside the workflow. That creates a governance problem for development organisations that still depend on delayed review queues and separate AppSec checkpoints.
Key questions
Q: How should security teams govern AI coding assistants that can execute commands?
A: Treat them as delegated non-human identities with bounded execution authority. Require human approval for destructive commands, keep command scopes narrow, and log every tool action. The key control question is not whether the assistant is helpful, but whether it can be prevented from acting outside intended scope when prompts, context, or rules are manipulated.
Q: Why do pull request reviews and release gates become less effective in ADLC?
A: Because they assume code will wait long enough for a human checkpoint to matter. In ADLC, changes can be generated, modified, and replaced repeatedly before a traditional gate is reached, so the control loses timeliness. The risk is not only missed findings, but governance that arrives after the code has already moved on.
Q: What do security teams get wrong about AI-generated code risk?
A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.
Q: What happens when AppSec enforcement stays manual in a machine-paced development loop?
A: Security becomes an after-the-fact interruption that developers are likely to bypass or ignore. Manual review cannot keep up with continuously changing code, so feedback arrives too late to shape the decision that created the risk. The result is weaker governance and lower developer trust in security controls.
Technical breakdown
Why SDLC-era security gates lose coverage in ADLC
The Software Development Lifecycle assumed code moved through discrete phases, so security could be applied at natural pause points such as pull requests, builds, and release gates. The Agentic Development Lifecycle breaks that cadence because code is generated, rewritten, and improved continuously, often before any stable review point exists. That removes the time budget that stage-based AppSec tooling depends on. Once change becomes looped rather than linear, the control is no longer whether a gate exists, but whether the gate can act before the next change invalidates its view.
Practical implication: Shift security enforcement from checkpoint review to continuous, in-line evaluation of code as it changes.
How AI-generated code changes the AppSec threat model
AI-generated code often appears clean and idiomatic, which makes it harder for reviewers to spot insecure trust assumptions. The article’s core point is not that AI code is always broken, but that functional correctness and security can diverge. A generated module may pass tests while still embedding unsafe patterns, because the model optimises for plausibility and task completion, not policy alignment. That means AppSec has to inspect context, not just syntax or test outcomes, and it has to do so at the speed of development.
Practical implication: Treat AI-assisted code as untrusted until it has been checked against policy and context-sensitive security rules.
Why security guidance has to become agentic
In ADLC, the development loop is too fast for security teams to manually inspect every change, so the control plane has to become more automated. Agentic security systems are relevant here because they can reason about code changes, apply policy without waiting for a human reviewer, and persist alongside the workflow instead of reacting after the fact. This is not about replacing governance. It is about moving governance into the path where developers and AI systems actually operate, including the IDE and pre-commit stage.
Practical implication: Design security controls that can evaluate, explain, and enforce policy before code reaches a shared branch or pipeline.
NHI Mgmt Group analysis
ADLC creates governance debt for AppSec teams that still think in review windows. The old operating model assumed there would always be a stable moment to inspect code before it moved on. In continuous AI-assisted development, that assumption fails because the code may change again before a human ever sees it. The practical conclusion is that AppSec governance must be expressed as continuous control, not episodic approval.
Inline enforcement is now the only model that matches the speed of development. When code is produced inside the IDE and modified repeatedly before commit, delayed feedback becomes indistinguishable from no feedback. That makes continuous policy evaluation the relevant control pattern, especially where developers rely on AI suggestions that can look correct while still embedding insecure assumptions. Practitioners should move controls closer to the moment intent is expressed.
ADLC exposes a trust gap between functional output and secure output. The article’s BaxBench reference reinforces a broader field reality: code that works is not necessarily code that is safe. That gap matters because modern development teams increasingly accept machine-generated output as a productivity layer, not a security decision point. Security programmes should treat this as a context and governance problem, not just a code quality problem.
Developer experience and security now have to be designed together. The article shows that AI engineering, platform engineering, and AppSec are converging around the same workflow. If security guidance interrupts the flow, it will be bypassed. If it is embedded where developers already work, it can shape decisions at scale. The lesson is that the control must be usable at machine pace, or it will not be used at all.
From our research library:
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: Agentic AI Identity Maturity Model
What this signals
ADLC turns AppSec into a continuous governance problem. The key shift is not simply more code, but less stable code state to review. If security teams still depend on batch-style checkpoints, they will keep discovering issues after the decision is already baked into the next iteration.
Machine-paced development demands policy at the point of creation. That is where security can still influence intent without slowing the whole loop down. For practitioners, the design question is no longer whether to add more review, but how to make review operational inside the tools developers already use.
For practitioners
- Embed security checks inside the IDE Move policy evaluation into the environment where developers and AI systems create code, so risky patterns are flagged before commit or handoff.
- Replace gate-based review with continuous enforcement Rework AppSec controls so they evaluate every change as it is produced, instead of relying on pull requests, release gates, or centralized queues.
- Add policy context to AI-generated code review Require security tooling to understand surrounding code and intended behaviour, not just isolated snippets or scan results.
- Align AppSec with platform engineering workflows Define shared control points with platform and AI engineering teams so security decisions happen in the same loop as development.
Key takeaways
- AI-assisted development is eroding the old pause points that SDLC-era application security depended on, so review after the fact is losing practical value.
- The core governance problem is now continuous change at machine pace, which means security controls must operate inside the development loop rather than around it.
- AppSec teams need to move policy enforcement closer to code creation, or they risk building controls that are technically present but operationally outpaced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST AI RMF, OWASP SAMM, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI-assisted development shifts control into agentic workflows where privilege and policy decisions matter. |
| Recommendation — Apply ASI03 controls to keep AI-assisted development actions within approved identity and privilege boundaries. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is about governance over AI-assisted development, not just code quality. |
| Recommendation — Use GOVERN to define accountability for AI-assisted coding controls and decision rights. | ||
| OWASP SAMM | Security Requirements — Security Requirements | The post focuses on embedding security into the SDLC and adjacent AI-assisted workflows. |
| Recommendation — Build security requirements into development practices so controls operate during code creation, not after release. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | AI-generated code still needs secure coding scrutiny even when it appears syntactically correct. |
| Recommendation — Use V15 to verify that generated code follows secure architecture and coding expectations before merge. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | The article argues for security evaluation earlier and more continuously in development. |
| Recommendation — Apply SA-11 to test and evaluate code throughout development rather than only at release checkpoints. | ||
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.
- In-line security enforcement: Security control that evaluates and applies policy at the moment code is written, reviewed, or accepted inside the development workflow. It replaces delayed, batch-style review with decisions that can still influence the change before it spreads further into the system.
- Continuous policy evaluation: A control pattern where policy is checked repeatedly as code or configuration changes, rather than only at fixed lifecycle gates. In AI-assisted development, this is the practical response to fast-moving output that can become obsolete before a manual review completes.
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. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org