AI velocity is widening AppSec’s vulnerability gap in Q4 2025

At a glance

What this is: This retrospective argues that Q4 2025 exposed a widening mismatch between AI-driven code and attack velocity and the security capacity available to control it.

Why it matters: For IAM, NHI, and broader security programmes, the same speed gap is now visible in AI agents, code pipelines, and trusted automation paths that can outpace human governance.

By the numbers:

• AI-assisted pull requests had 2.74x more XSS vulnerabilities than human-only code in CodeRabbit’s analysis of 470 pull requests.
• Anthropic reported that nation-state actors automated 90% of a cyberattack using Claude AI, including reconnaissance and lateral movement.
• EMA found that 98% of enterprises deploy AI agents, while 79% of organisations without written policies deployed them anyway.
• CrowdStrike’s survey found that 76% of organisations are struggling to keep pace with the volume of code AI tools generate.

👉 Read Pixee’s Q4 2025 AppSec retrospective on AI velocity, agent risk, and security capacity

Context

AI-assisted development changes the security problem by increasing the amount of code, the speed of delivery, and the amount of review work arriving at once. In AppSec, that creates a governance gap: controls built around human-paced change no longer match the rate at which vulnerabilities and misconfigurations appear, and the same pressure is increasingly visible in AI agent and NHI oversight.

This retrospective is best read as a capacity story rather than a single-vendor story. It ties together code quality, AI-enabled attack automation, agent governance, supply chain risk, and remediation bottlenecks, which is exactly where identity and access controls start to matter for software agents, service accounts, and other non-human identities.

The pattern is no longer atypical. Across AppSec, AI governance, and machine identity management, the organisations under pressure are the ones still assuming that manual review can contain machine-scale change.

Key questions

Q: What breaks when AI-generated code is reviewed without security gates?

A: What breaks is the assumption that a clean-looking diff is a safe diff. AI-generated code can hide unsafe defaults, dependency issues, and weak validation that basic review misses. Without CI-enforced tests and security checks, the merge process becomes a distribution channel for defects rather than a control point.

Q: Why do AI agents create new risk in non-human identity management?

A: AI agents create risk because they operate as software identities with delegated authority, but many organisations do not track them with the same discipline applied to users or service accounts. They can connect quickly, persist across teams, and accumulate permissions that are hard to review. That combination increases the chance of unnoticed access drift and credential exposure.

Q: How do you know if AI agent remediation is actually working?

A: The original attack chain must fail after the fix, and close variants should fail too. If the same goal can still be reached with different wording or a different tool sequence, remediation is partial. The strongest signal is a repeatable post-fix verification log that shows the harmful outcome no longer occurs.

Q: Who should be accountable when an AI agent causes a security incident?

A: Accountability should sit with the human owner, platform team, or business function that granted and operated the agent. The identity may act independently, but governance cannot detach responsibility from the delegation chain. Programs should define ownership, escalation, and remediation paths before deployment so responsibility is clear when the agent's behaviour changes.

Technical breakdown

Why AI-generated code changes the AppSec control model

AI-assisted coding increases throughput, but it also changes the distribution of defects. The problem is not only more code. It is more code produced with weaker contextual understanding, which increases the likelihood of insecure object references, password handling errors, and concurrency bugs. Traditional review processes assume a manageable queue of human-authored changes. AI output breaks that assumption by scaling faster than review, testing, and remediation can absorb. In governance terms, security controls become latency-bound, not policy-bound.

Practical implication: teams need automated validation gates that scale with code generation volume, not periodic manual spot checks.

How AI agent deployment creates an identity governance problem

An AI agent is not just software that calls tools. It is a runtime entity that can act within delegated permissions, often without human supervision at each step. That makes it operationally closer to a non-human identity than to a normal application feature. The governance challenge is that many IAM models still assume a person or service account with a stable lifecycle, while agents can be created, modified, and retired quickly across workflows. Once agent permissions are excessive, the attack surface becomes both authentication and delegation logic.

Practical implication: treat AI agent identities as governed runtime principals with explicit ownership, scope, and offboarding controls.

Why supply chain abuse now reaches agent and package layers

Package ecosystems and model-connected tooling create a trust chain that attackers can exploit without breaking the underlying platform. A malicious package, compromised dependency, or abused protocol can deliver credential theft, data exfiltration, or unauthorized tool use while still appearing functional. MCP adds another layer because it connects agents to external tools and data sources, making each connector part of the security boundary. The result is a supply chain problem that includes identity, privilege, and runtime trust as much as code integrity.

Practical implication: security reviews must extend to packages, connectors, and delegated tool permissions, not just source code.

Threat narrative

Attacker objective: The attacker objective is to exploit speed, trust, and delegated access to reach systems, steal credentials, or force defenders into a delayed response posture.

1. Entry began with AI-assisted or supply-chain-enabled development and attack workflows that accelerated the initial creation or delivery of risky code and tooling.
2. Escalation followed when attackers or over-permissioned agents used trusted execution paths, exposed credentials, or delegated tooling to amplify access and reach.
3. Impact emerged as vulnerabilities, credential theft, lateral movement, and remediation overload outpaced security teams’ ability to contain the blast radius.

NHI Mgmt Group analysis

AI velocity is now an access-control problem, not just a code-quality problem. When code generation accelerates faster than review and validation capacity, the governing question shifts from defect detection to blast-radius control. That is why frameworks such as NIST AI Risk Management Framework and OWASP Agentic AI Top 10 matter alongside AppSec tooling. The practitioners who will cope best are the ones who treat throughput as a security design variable, not a productivity KPI.

Agent sprawl creates a verification trust gap. The article’s 98% deployment figure and 79% policy gap point to a familiar pattern: adoption happens before governance, then controls try to catch up after permissions have already spread. In identity terms, software agents need lifecycle ownership, scope limits, and revocation paths that are as explicit as those used for human access. That is where non-human identity governance becomes operational, not theoretical.

Named concept: detection-response latency. This retrospective shows that the real constraint is the time between a risky state appearing and security being able to act on it. In AppSec, that means a vulnerability exists before a reviewer sees it. In AI governance, it means an agent can act before policy catches up. The discipline now needs controls that shorten exposure windows, not just better dashboards.

Supply chain trust is becoming runtime trust. Package ecosystems, agent connectors, and workflow hooks are no longer just software distribution problems. They are access channels, because they can carry credentials, invoke tools, and move data. That widens the scope of governance to include permissions, secrets, and delegated execution. Practitioners should assume that every trusted dependency can become a privilege path.

The market is moving from point controls to coordinated control planes. Security teams can no longer rely on separate solutions for code scanning, credential hygiene, and agent oversight. The operational pattern now demands joined-up policy, telemetry, and response across software supply chains and non-human identities. The teams that recognise that shift early will reduce both remediation backlog and privilege exposure.

What this signals

Detection-response latency: AppSec and identity teams should now measure how long risky code, leaked secrets, and over-permissioned agents remain active before containment. That metric is more useful than raw alert volume because it shows whether governance is reducing exposure or merely documenting it. For teams aligning to broader control language, NIST AI Risk Management Framework provides the right lens for agentic workflows.

The presence of AI agents in enterprise workflows means access reviews must expand beyond human accounts and service accounts. Lifecycle ownership, scope, and revocation need to be explicit for software principals, otherwise policy becomes aspirational and enforcement stays partial. The operational signal is whether your programme can account for every non-human principal with the same precision used for privileged human access.

For practitioners

• Set security gates to match AI code throughput Use automated SAST, secret scanning, policy checks, and test enforcement on every AI-generated change set so review capacity is not the bottleneck.
• Inventory AI agents as governed identities Assign explicit owners, permissions, expiry conditions, and offboarding paths to every agent that can call tools, read data, or trigger workflows.
• Reduce standing privilege in tool-connected pipelines Limit the scope of service accounts, API keys, and connector tokens used by build systems and AI workflows so compromise cannot spread laterally.
• Instrument remediation latency as a control metric Track the time from defect introduction to detection and from detection to revocation, then set escalation thresholds for high-risk code paths.
• Review package and connector trust boundaries together Assess npm hooks, MCP connectors, and workflow automation as one access surface so dependency reviews include execution and privilege implications.

Key takeaways

• Q4 2025 showed that AI is expanding both the volume of insecure code and the speed of attacker activity.
• The biggest governance gap is no longer visibility alone, but the delay between risky state creation and effective containment.
• Identity teams should treat AI agents, package hooks, and connector tokens as governed principals with ownership, scope, and revocation.

Key terms

• Detection-Response Latency: The elapsed time between identifying a security issue and executing a bounded, auditable fix. In data security programmes, long latency means exposure persists after discovery, which undermines the value of detection and weakens compliance evidence.
• 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.
• AI code velocity: The rate at which AI-assisted tooling produces code changes that reach review and testing. Higher velocity is not a security outcome by itself, but it changes the burden on validation, making automation and policy enforcement essential for keeping defect exposure within acceptable bounds.
• Supply chain trust relationship: A supply chain trust relationship is any external connection in which a third party can influence, read, or act within an organisation’s operational environment. In identity terms, it should be governed like privileged access because the trust path can expand faster than the organisation’s ability to monitor it.

What's in the full article

Pixee's full retrospective covers the operational detail this post intentionally leaves for the source:

• Week-by-week AppSec briefing context that shows how the Q4 signals evolved across the quarter
• The underlying source articles and the full evidence trail behind each of the 10 stats
• Per-stat interpretations on why the trends matter for developers, AppSec, and AI governance teams
• The weekly remediation and tooling themes that explain where security capacity is breaking down

👉 Pixee’s full retrospective covers the weekly evidence trail, source articles, and remediation themes behind the quarter’s AppSec signal.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the control foundation needed for human and non-human identity programmes that now overlap.