AI is outpacing pentesting in fast-release software delivery

At a glance

What this is: This report argues that AI is accelerating pentesting pressure, with release velocity now outstripping scheduled validation in many organisations.

Why it matters: For IAM and security teams, the core issue is governance drift: access, code, and deployment changes can move faster than the testing and approval cycles meant to control them.

By the numbers:

• Only 21% validate security on every release, despite 76% deploying significant changes weekly or faster.
• 48% say pentest findings are already outdated when they arrive.
• 79% are concerned about missing vulnerabilities introduced between scheduled tests.
• 69% would validate security on every release or at least quarterly if cost and resources weren't a constraint.

👉 Read Aikido's 2026 State of AI in Pentesting report

Context

AI-assisted delivery is compressing the time between code change and production exposure, which makes periodic testing a weaker control than it used to be. In practice, the governance gap is not whether organisations test, but whether they can test quickly enough to keep findings relevant before the next release.

For identity and access programmes, this is part of a broader control-timing problem. When software delivery moves faster than validation, the surrounding permissions, secrets, and deployment entitlements also become harder to govern in step with risk. That pattern is now typical in fast-moving engineering environments rather than an edge case.

Key questions

Q: How should security teams validate fast-moving software releases without relying on quarterly pentests?

A: Security teams should link validation to release events, not to fixed calendar intervals. That means automated checks in CI/CD, targeted human review for high-risk changes, and re-testing after remediation. The goal is to make assurance part of delivery governance, so findings remain relevant when the software actually reaches production.

Q: Why do scheduled pentests miss issues in AI-assisted development pipelines?

A: Because the environment can change multiple times between test windows. AI-assisted development increases code volume, dependency churn, and configuration drift, so a report produced after the test may no longer reflect the deployed system. The gap is operational timing, not just test quality.

Q: What do security teams get wrong about continuous validation?

A: They often treat it as a tooling upgrade instead of a governance model. Continuous validation only works when testing frequency, scope, and release risk are aligned. If teams automate checks but keep the same approval bottlenecks and low-risk assumptions, they simply move the delay elsewhere.

Q: How do teams decide which applications need release-linked security testing?

A: Prioritise systems with frequent deployments, internet exposure, customer data, or heavy identity and automation dependencies. Those environments create the highest probability that a vulnerability will be introduced and exploited before the next scheduled test. Low-change systems can use lighter validation, but not no validation.

Technical breakdown

Why scheduled pentests go stale in fast-release environments

Traditional penetration testing samples a point in time. That works when release cadence is measured in months, but not when deployment happens weekly or continuously. AI-assisted engineering increases the number of code paths, configuration changes, and dependency updates that can land between tests. Findings then describe a past state, while attackers target the current one. The problem is not that pentesting is useless, but that a single scheduled engagement cannot represent an environment whose attack surface is changing faster than the report cycle.

Practical implication: move from point-in-time assurance to release-linked validation, especially for systems with frequent code and identity changes.

Continuous validation and release gating in modern software delivery

Continuous validation means security checks are embedded into the delivery pipeline rather than attached to a separate calendar event. In mature programmes, this includes automated tests, policy checks, dependency scanning, and targeted human review for high-risk changes. The objective is to catch exploitable issues before production exposure, not after the next audit cycle. For identity-dependent systems, this also means verifying access controls, service credentials, and deployment permissions as part of the change process, because those are often the real enablers of exploitation.

Practical implication: tie security gates to deployment events and high-risk identity changes, not to quarterly testing windows.

What AI changes in the pentesting model

AI changes both attacker and defender pace. On the attacker side, it lowers the cost of discovery, code analysis, and exploit adaptation. On the defender side, it can help prioritise findings and accelerate triage, but it does not solve the underlying timing gap on its own. The real shift is operational: security teams need a control model where testing is frequency-based, context-aware, and connected to release risk. That is a governance change, not just a tooling upgrade.

Practical implication: use AI to accelerate analysis, but redesign assurance around change velocity and risk tiering.

Threat narrative

Attacker objective: The attacker aims to exploit newly introduced weaknesses before security teams can detect and remediate them.

1. Entry occurs through vulnerabilities introduced between scheduled tests, when code or configuration changes are deployed faster than validation can follow.
2. Escalation happens when outdated findings leave exploitable weaknesses unaddressed across releases, allowing attackers to target the current production state.
3. Impact is unauthorised access, compromise of exposed services, or exploitation of defects that should have been detected before deployment.

NHI Mgmt Group analysis

AI creates a release-velocity security gap: the central governance problem is no longer whether organisations test, but whether the test cycle matches the pace of delivery. When 76% of teams ship significant changes weekly or faster, scheduled pentests increasingly describe yesterday's environment. That makes security validation a change-management issue, not just an assurance activity.

Continuous validation is becoming the control plane for modern assurance: organisations need security checks that move with the pipeline, not around it. This aligns with NIST CSF 2.0 and control families that emphasise continuous monitoring, but the practical insight is simpler. If a finding cannot influence the next release, it has limited value to the current risk state.

Identity and deployment governance now intersect more tightly than many programmes assume: AI-accelerated delivery depends on service accounts, tokens, build permissions, and release automation that often sit outside classic pentest scope. That creates a governance blind spot where the code is tested but the credentials enabling the code path are not. The named concept here is validation lag debt, and teams should treat it as a measurable security backlog.

Pentesting is shifting from event-based assurance to risk-based verification: the report reflects a broader market movement toward continuous testing, but the most important change is operational prioritisation. High-change applications, customer-facing systems, and identity-rich workflows need different validation frequency than low-change environments. The practical conclusion is that one testing model no longer fits the whole estate.

AI does not remove the need for human judgment in security testing: it increases the volume and speed of work, which makes triage and scope selection more important. Automated checks can catch repeatable issues, but they cannot fully replace contextual review of exploitability, business impact, and release timing. Practitioners should use AI to scale verification, not to justify weaker governance.

What this signals

AI-assisted delivery does not just compress release cycles. It also compresses the time available to detect misuse of credentials, review entitlements, and prove that security controls still hold after change. For programmes that manage secrets and deployment access, the relevant question is whether governance can keep pace with engineering throughput, not whether a pentest exists on paper.

Validation lag debt: when findings outlive the release they were meant to secure, organisations accumulate an assurance backlog that looks healthy in reports but stale in practice. That backlog is most visible where release pipelines depend on service accounts, API keys, and other non-human identities, because those controls often move fastest and are reviewed least often.

Teams should expect more pressure to prove continuous verification across development, deployment, and identity layers. The most resilient programmes will treat release risk, access governance, and vulnerability testing as one control problem, then use external standards like the NIST Cybersecurity Framework 2.0 to structure the operating model.

For practitioners

• Map validation frequency to release risk Classify applications by deployment cadence, exposure level, and identity dependency, then set testing and review frequency to match the highest-risk change class rather than using one calendar for everything. Use release-triggered checks for systems that ship weekly or faster.
• Embed security gates into CI/CD change events Tie policy checks, dependency analysis, and targeted manual review to merge, build, and deploy stages so that high-risk changes cannot bypass verification simply because the scheduled pentest has not happened yet.
• Include service credentials in release assurance Review build tokens, deployment accounts, and API credentials as part of the validation scope, because many exploitation paths begin with over-permissioned automation rather than the application code itself.
• Track validation lag as a governance metric Measure how long it takes for findings to be tested, remediated, and re-validated after a release. If the lag is longer than the deployment interval, your assurance model is behind the change rate.
• Use AI to prioritise, not to substitute assurance Apply AI-assisted triage to focus human testers on the highest-impact changes, but keep deterministic control checks for authentication, access control, and deployment integrity.

Key takeaways

• AI-assisted delivery is widening the gap between software change and security validation, making scheduled pentests less reliable as a sole assurance model.
• The report's numbers show a clear timing problem: most teams ship weekly or faster, yet only a minority validate every release and nearly half say findings arrive too late.
• Practitioners should move toward release-linked security gates, continuous validation, and tighter governance of the identities and credentials that power delivery pipelines.

Key terms

• Continuous validation: Continuous validation is the practice of re-checking user, device, or session risk after login instead of trusting access indefinitely. It recognizes that identity assurance can drift during a session, especially when endpoint state or user context changes after authentication.
• Validation lag debt: Validation lag debt is the accumulation of security risk created when findings, retests, or approvals happen after the environment has already changed again. It is a governance problem because the organisation appears to be controlling risk, but the control signal is already stale.
• Release-linked security testing: Release-linked security testing ties security checks to merge, build, deploy, or promotion events. The point is to make validation follow the change, especially in software delivery environments where weekly or daily releases make calendar-based testing too slow to be useful.

What's in the full report

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

• Breakdowns of how 400 CISOs, CTOs, and senior engineering leaders answered questions about AI and pentesting.
• The underlying survey context behind the 21% every-release validation figure and the 48% stale-findings result.
• Perspective from contributors across OWASP, IDC, Frost & Sullivan, and the UK Cabinet Office on how testing models are changing.
• Additional detail on what teams want from the next generation of pentesting, beyond the headline metrics.

👉 Aikido's full report covers the survey findings, contributor perspectives, and modern pentesting expectations 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 secrets management. It is relevant for practitioners who need to connect identity control to broader security assurance and delivery governance.