AI-assisted coding outpaces security validation in appsec teams

At a glance

What this is: NHI Mgmt Group's analysis, drawing on ProjectDiscovery's research: AI-assisted coding is accelerating delivery faster than security teams can validate findings, creating a review bottleneck around secrets exposure, dependency risk and business logic flaws.

Why it matters: This matters because appsec, IAM and platform teams now have to govern higher code throughput with the same or smaller review capacity, which shifts value from raw detection volume to auditable validation, scoped access and faster prioritisation.

By the numbers:

• 100% of respondents said engineering delivery has gotten faster in the last twelve months.
• Only 38% of the security teams in the survey said they're comfortably keeping up with the resulting code volume.
• 66% of respondents said more than half of their working week goes to manually validating and reproducing findings before anything can be prioritised or routed.
• 78% of respondents ranked secrets exposure as one of the top challenges introduced or amplified by AI-assisted coding.

Context

AI-assisted coding changes the security workload before it changes the threat model. Code arrives faster, reviews get larger, and the first control to feel strain is usually the one that depends on human inspection and contextual judgement.

That strain is not limited to application security teams. Where AI-generated code increases the number of pull requests and the amount of context each review must absorb, identity, secrets governance and authorization checks all become harder to enforce consistently. The result is a governance problem as much as a tooling problem, especially when workflows depend on manual review to catch issues before merge.

Key questions

Q: How should security teams use AI-assisted code review safely?

A: Use it as a triage layer that accelerates first-pass detection, then require a separate validation step for findings that affect access control, authentication, secrets, or release gating. The safest pattern is hybrid review, where deterministic analysis and human judgement backstop the model’s reasoning.

Q: Why do AI coding tools increase secrets risk?

A: AI coding tools increase secrets risk because they can accelerate the reuse of insecure patterns across repositories, test fixtures, and automation scripts. The issue is not the model inventing credentials, but the way generated code can spread bad defaults faster than human review can catch them.

Q: How should security teams reduce repetitive false positives in SAST programs?

A: Start by encoding the context your scanner cannot infer reliably. Focus first on non-production code paths, then on framework protections such as authentication middleware, ORM query builders, and output encoding. Treat each memory as governed detection policy, not a one-off dismissal, so the same decision is applied consistently across future scans.

Q: What should security leaders measure when AI-assisted coding slows review?

A: Security leaders should measure review latency, defect escape rate, rule violations, and the amount of human rework needed to validate AI-generated code. Track how often reviewers must inspect insecure patterns such as hard-coded secrets, overbroad permissions, unsafe deserialisation, or missing input checks, and whether code scanning, policy gates, and protected branching still catch them before merge.

Technical breakdown

Why AI-generated code overwhelms manual appsec review

AI-assisted coding increases throughput, but it also changes the shape of review. Security teams are no longer assessing isolated changes one at a time. They are looking at larger diffs, more frequent commits, and code whose intent may not be obvious from static patterns alone. That means the review function has to understand application state, user context and business flow, not just syntax or known signatures. Where the workload scales faster than the reviewers, backlog becomes the control failure. Tools can assist, but they do not remove the need for contextual judgement. See the Application Security Guide.

Practical implication: Shift review capacity toward high-risk pull requests and require traceable triage criteria for what gets manual attention first.

Why secrets exposure and supply chain risk rise with AI-assisted coding

AI coding assistants tend to amplify mistakes that are easy to copy and hard to spot, especially embedded credentials, dependency choices and unsafe patterns repeated across files. Secrets leakage is particularly dangerous because a token or key is immediately actionable, while dependency risk often hides in transitive packages or generated snippets that look plausible. The combination creates a mixed problem of detection, provenance and lifecycle control. In practice, the issue is less about one bad line of code and more about whether the pipeline can detect and revoke what should never have entered source in the first place.

Practical implication: Treat secrets scanning, dependency vetting and revocation workflows as one control chain rather than separate queues.

How validation tax becomes a governance issue

When more than half of the working week goes to proving whether findings matter, the organisation is not just slow. It is using a governance model that assumes security can scale through alert volume and post-hoc review. That model breaks when developers need hard evidence before acting and security teams must reproduce findings before escalating them. The resulting queue becomes a policy problem: what should have been caught or trusted at issuance time is now being argued about after the fact. The control plane has moved from detection to validation.

Practical implication: Build evidence-rich triage paths, so findings can be accepted, rejected or escalated without consuming most of the security team's week.

Breaches seen in the wild

• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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 coding has turned security review into a throughput problem, not a pure detection problem. The practical limit is no longer whether teams can find issues in code, but whether they can validate enough of them fast enough to influence release decisions. That changes appsec from a scanning function into a governance function that must triage risk under time pressure. The practitioner conclusion is straightforward: review capacity is now a design constraint.

Secrets exposure is the clearest identity-security intersection in this shift. When AI-generated code introduces or repeats credentials, the risk is not just a code quality issue but a non-human identity lifecycle issue, because tokens and keys can be born, copied and exposed without any human owner noticing. That is why AI agent identity security matters here even when the immediate problem looks like application code. The practitioner conclusion is to govern secrets as runtime identities, not static strings.

Validation fatigue is creating a named control gap: the evidence bottleneck. Security teams are spending too much time proving exploitability, reproducing findings and persuading developers to act. This means the organisation lacks a trusted path from signal to decision, so even good findings lose operational value. The practitioner conclusion is that evidence packaging has become part of the control, not an afterthought.

AI security tooling will be judged less by detection claims and more by auditability. Practitioners in this survey are effectively asking for proof, scope and bounded execution before they trust AI to participate in testing or validation. That is a governance signal, not a feature preference. The practitioner conclusion is to evaluate tooling on traceability, not on raw automation claims.

Context-heavy flaws will keep outpacing pattern-matching defenses. Secrets exposure, business logic flaws and authorization mistakes all depend on application intent, user state and workflow context. That means generic signatures will keep missing the most expensive issues while still generating queue noise. The practitioner conclusion is to prioritise controls that understand the code's intended behaviour, not just its syntax.

From our research library:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
• Read next: Top 10 Vibe Coding Security Risks

What this signals

Validation debt: security programmes are accumulating a new form of operational drag when findings must be proven before they can be acted on. That debt grows fastest in teams that still depend on manual reproduction for high-volume AI-assisted code changes. The practical response is to move certainty earlier in the pipeline, so reviewers spend less time proving the same point twice.

The next stage of this problem is governance, not tooling. As AI-generated code becomes normal, programmes will need evidence trails that explain why a finding mattered, what was tested and who approved the decision, otherwise the security queue becomes the real release gate.

Secrets governance will increasingly sit inside appsec rather than beside it, because the credential itself is now part of the code supply chain. Teams that treat secrets as runtime identities, not just configuration strings, will have a better chance of controlling exposure before it reaches production.

For practitioners

• Separate validation from detection queues Create distinct triage lanes for low-confidence scanner output, reproducible findings and release-blocking issues so manual effort is reserved for decisions that change risk.
• Tighten secrets governance around AI-generated code Require automated secret detection, immediate revocation paths and ownership tracking for any credential surfaced in pull requests or generated files.
• Use evidence-based prioritisation for exploitability checks Standardise what proof is needed before a finding can be escalated, and capture that proof in a repeatable format developers and approvers can review quickly.
• Reduce dependency noise at the intake layer Filter SCA and dependency alerts before they reach reviewers, and route only the findings that affect reachable code, known exploit paths or approved packages.
• Give AI testing bounded, auditable scope Constrain any AI-assisted security testing to approved targets, logged actions and human-approved execution paths before it interacts with critical workflows or production-like environments.

Key takeaways

• AI-assisted coding is shifting appsec from a detection problem to a validation problem, because the security team must now decide faster which findings deserve human effort.
• The survey data points to a workload mismatch: all respondents saw faster engineering delivery, but only a minority said security was keeping up comfortably.
• Teams that want to cope with the new pace need stronger evidence paths, tighter secrets governance and less noise from dependency and static-analysis queues.

Related NHI Mgmt Group resources: Application Security Guide · AI Agent Identity Security Buyer's Guide · Top 10 Vibe Coding Security Risks

Key terms

• AI-assisted coding: The use of a language model or coding assistant to generate or modify software code with human guidance. It increases speed, but it also creates a trust problem because the output can look correct while hiding insecure logic, unsafe defaults, or poor handling of credentials and access paths.
• Secrets Exposure: Secrets exposure is the accidental or uncontrolled disclosure of credentials such as API keys, tokens, certificates, and service passwords. In NHI programs, it matters because a leaked secret often behaves like a live identity, creating immediate access risk until it is revoked or rotated.
• Business logic vulnerability: A business logic vulnerability is a flaw in how an application’s workflow or rules are enforced, allowing an attacker to misuse a process rather than break code directly. These issues often evade signature-based tools because the weakness lies in authorisation, sequence, or state handling.
• Software Composition Analysis: Software composition analysis is the inspection of dependencies and packages to identify known vulnerabilities in third-party or transitive code. It complements secret scanning by answering a different question: what exploitable software weaknesses are present in the container, regardless of whether credentials are embedded.

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 the course if your role spans IAM, NHI, or AI security governance.