AppSec is evolving, not dying, in the age of coding agents

At a glance

What this is: Boost Security says AI-assisted code review can improve vulnerability discovery, but AppSec remains necessary because software risk extends beyond first-party code into dependencies, pipelines, endpoints, and runtime systems.

Why it matters: For IAM and security teams, this matters because code-scanning gains do not remove the need to govern identities, permissions, and controls across the software factory where agents, developers, and pipelines all create access risk.

Context

AppSec now has a broader problem than code review alone. The security gap is that many organisations still treat first-party code scanning as the centre of software security, even though risk also comes from dependency changes, pipeline configuration, developer endpoints, and runtime exposure. In environments where coding agents assist with generation and remediation, the control problem shifts from only finding defects late to governing the full path from authoring to deployment.

The identity angle is real but indirect: developers, service accounts, CI jobs, coding agents, and tool integrations all rely on credentials and permissions to move code through the software factory. That means software security and identity governance now overlap at the points where access is issued, inherited, or abused. The article's core point is typical of mature AppSec programmes, which increasingly need inventory, prioritisation, and incident response rather than a single scanning layer.

Key questions

Q: What breaks when organisations keep treating code review as the primary security control for AI assisted development?

A: Code review breaks down as a gate because it is too slow for the volume and speed of AI generated output. Reviewers miss architectural flaws, repeated bugs, and environment specific failures when they are forced to inspect too much code too late. Security then becomes reactive, with defects already embedded in production systems.

Q: Why do coding agents increase the need for software security governance?

A: Coding agents can speed up secure coding, but they also increase the number of identities and automations that can change code, trigger builds, or deploy artifacts. That expands the trust boundary. Teams need governance over permissions, review, and enforcement so speed gains do not turn into faster propagation of mistakes or abuse.

Q: What are the signs that AppSec is too dependent on first-party code scanning?

A: Common signs include repeated surprises from dependency updates, weak visibility into CI/CD changes, poor coverage of developer endpoints, and security teams that cannot answer what is internet-facing or PII-touching. Those signals show the programme is measuring code defects while leaving adjacent delivery risks outside governance.

Q: Should teams prioritise AI-assisted scanning or pipeline control first?

A: Pipeline control usually comes first when build systems, release workflows, or developer credentials can be abused, because those paths can turn any code issue into a supply chain incident. AI scanning still matters, but it is most effective after teams have bounded who and what can move code through the software factory.

Technical breakdown

Why AI-assisted code review does not cover the whole software factory

AI code analysis can reason over source code, identify non-obvious defects, and reduce triage noise, but it only sees one layer of the software lifecycle. Modern software security includes dependency integrity, pipeline configuration, workstation tooling, infrastructure-as-code, and runtime context. A model that reviews code on commit cannot detect a vulnerable package introduced later, a poisoned build step, or a misconfigured GitHub Actions workflow that turns a safe pull request into an exploit path. The technical mistake is assuming vulnerability discovery at generation time is equivalent to lifecycle control across build and deploy.

Practical implication: Treat AI review as one input into software security, not as a replacement for dependency, pipeline, and runtime controls.

How coding agents change detection, prioritisation, and remediation

Coding agents shift some security work left by making it practical to analyse more code, more quickly, and to propose fixes inline. That improves speed, but it also introduces a new operational question: which findings should be trusted, prioritised, and enforced at enterprise scale? The answer is not purely probabilistic. Enterprises still need deterministic policy, asset inventory, and severity context to decide whether a defect is exploitable, internet-facing, or blocked by compensating controls. Without that structure, AI can increase output without improving governance.

Practical implication: Use AI to accelerate analysis and remediation, but keep policy and prioritisation under controlled enterprise workflows.

Why identity and access control still matter in AI-augmented AppSec

The identity layer matters because secure software pipelines depend on who or what can change code, trigger builds, approve merges, and deploy artifacts. Coding agents, CI jobs, IDE extensions, and service accounts all become governed actors in the delivery chain. If those identities are overprivileged or poorly inventoried, an AI-assisted workflow can speed up both secure delivery and compromise. This is why AppSec is converging with IAM, PAM, and NHI governance at the pipeline boundary, even when the article is not explicitly about identity.

Practical implication: Map build and delivery identities, reduce standing privilege, and review agent and pipeline access as part of software security governance.

Threat narrative

Attacker objective: The attacker objective is to turn trusted software delivery paths into a scalable way to introduce code, steal secrets, or compromise deployed applications.

1. Entry occurs when a developer, coding agent, dependency update, or pipeline change introduces code or configuration into the software factory.
2. Credential or pipeline abuse follows when overprivileged CI jobs, developer accounts, or malicious packages can influence build and deployment steps.
3. Escalation happens when the flaw reaches internet-facing services, runtime clusters, or downstream consumers through the delivery chain.
4. Impact is compromise of application integrity, exposed data, or expanded attack surface across repositories, pipelines, and deployed services.

Breaches seen in the wild

• 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 AppSec expands detection, but it does not collapse software risk into code review. The central governance error in the current debate is treating defect discovery as equivalent to software security. Code review, even when powered by LLMs, does not govern transitive dependencies, build systems, developer endpoints, or runtime boundaries. The right conclusion is that AI becomes a stronger detector inside a broader control plane, not a substitute for that control plane.

Software factory inventory is now a security control, not a reporting exercise. The article correctly points to the need to know which repositories, pipelines, images, models, and coding agents exist and which matter most. That is not just hygiene. It is the mechanism that lets teams prioritise internet-facing code, PII-touching systems, and high-risk delivery paths before triage noise overwhelms response capacity. Practitioners should treat discovery and classification as active risk reduction.

Agentic delivery trust gap: coding agents and pipeline automations create security value only when their permissions are bounded. Once an agent can open files, suggest fixes, trigger builds, or influence deployment, its identity becomes part of the attack surface. The article's strongest implication for the field is that AppSec, IAM, and NHI governance are converging around software delivery identities. Practitioners should govern those identities with the same seriousness they apply to human privileged access.

Determinism still matters alongside AI. LLMs are useful for reasoning, but enterprises cannot run on probabilistic security alone. Policy enforcement, reproducible controls, and incident response are what turn findings into durable protection. The field is moving toward mixed control stacks because no single detector can cover code, dependencies, endpoints, and runtime conditions at enterprise scale. Practitioners should design for layered assurance, not tool replacement.

From our research library:

• Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to the State of Secrets in AppSec.
• 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

AppSec is becoming a control-plane problem. The programme question is no longer whether an LLM can find a defect, but whether the organisation can govern code, identities, build systems, and runtime dependencies as one delivery chain. That is where inventory and access control become more valuable than another isolated scanning layer.

Agentic code workflows create a new trust boundary. When coding agents can edit, propose, and sometimes trigger actions, their permissions must be treated like other privileged delivery identities. This is where IAM and NHI governance meet software security in practice, especially for teams using multiple IDEs, CI systems, and automation paths.

Security teams should expect the mix of deterministic and AI-driven controls to grow. LLMs will keep improving vulnerability discovery, but the durable advantage comes from combining them with policy gates, dependency visibility, and incident response discipline. Practitioners who align those layers will be better positioned to absorb the next wave of AI-assisted development.

For practitioners

• Inventory the full software factory Map repositories, CI jobs, build identities, developer endpoints, package sources, container images, and deployed services so security decisions reflect the real attack surface.
• Separate AI findings from enforcement decisions Use coding agents to accelerate discovery and remediation, but require deterministic policy gates for merge, build, and release decisions.
• Review pipeline and agent privileges Audit service accounts, token scopes, and workflow permissions so coding agents and CI systems cannot modify more than their task requires.
• Add dependency and runtime controls Track third-party packages, base images, and runtime clusters alongside first-party code so newly introduced risk is not missed after code generation.
• Prepare incident response for software supply chain events Predefine how teams will assess exposure when a package, pipeline, or developer tool is compromised, including scoping, containment, and rebuild steps.

Key takeaways

• AI-assisted code review improves defect discovery, but it does not govern the broader software factory where dependencies, pipelines, endpoints, and runtime systems also create risk.
• The article's core lesson is that AppSec programmes need inventory, prioritisation, and policy enforcement to make AI findings operationally useful at enterprise scale.
• Coding agents raise the importance of access control because the identities that move code through build and release pipelines become part of the attack surface.

Key terms

• Software Factory: The end-to-end delivery environment that turns source code into released software, including repositories, CI/CD systems, build runners, signing services, and deployment automation. In security terms, it is a high-trust identity zone that needs strong lifecycle and privilege boundaries.
• Coding Agent: A coding agent is a software system that can plan, generate, and modify code with limited human prompting. In governance terms, it is not just a tool but an actor whose permissions, tool access, and rollback path must be managed as part of the delivery process.
• Pipeline Security Hygiene: Pipeline security hygiene is the baseline set of controls that protects the software delivery pipeline from introducing or amplifying risk. It includes security checks embedded into development workflows, which helps teams catch vulnerabilities early and maintain consistent security standards as code moves toward release.
• AppSec Program: An AppSec program is the set of people, processes, and technical controls used to secure software throughout its lifecycle. It typically includes testing, triage, remediation, reporting, and governance so security is built into development rather than added only at the end of a release cycle.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to govern access across modern delivery pipelines. It helps security teams connect identity controls to the software and automation systems that now shape application risk.