TL;DR: AI-accelerated development, automated attack execution, and supply chain abuse are converging into a capacity problem for AppSec teams, with the strongest signals coming from AI-generated code vulnerability rates, agent deployment gaps, and malware spreading through package ecosystems, according to Pixee. The practical takeaway is that review, testing, and runtime controls now have to scale with machine speed, not human pace.
At a glance
What this is: Pixee’s Q4 2025 retrospective says AI-driven development and automated attacks are creating a widening AppSec capacity gap across code review, validation, and response.
Why it matters: For security and identity practitioners, the issue is no longer only code quality but governance at machine speed, where review, testing, and access controls must keep pace with AI-enabled production workflows.
By the numbers:
- AI-assisted PRs had 2.74x more XSS vulnerabilities than human-only pull requests, according to CodeRabbit research cited by Pixee.
- Anthropic said Chinese state-sponsored threat actors used Claude to automate 90% of a cyberattack, according to Pixee.
- Nagomi Security’s 2025 CISO Pressure Index found that 44% of CISOs say burnout affects their ability to prepare for breaches, according to Pixee.
- EMA found that 98% of enterprises deploy AI agents while 79% of organisations without written policies deployed anyway, according to Pixee.
Context
AI-assisted software delivery changes the pace at which defects, insecure patterns, and exposed interfaces enter production. When the engineering side moves faster than review and validation, security teams inherit a capacity problem rather than a single control failure.
This is not just an AppSec issue. AI-driven code generation, AI agent deployment, and automated attacker tooling all stress identity, access, and governance assumptions because they increase the number of actions, permissions, and dependencies that need control.
The pattern in Q4 2025 is typical of fast-moving platform shifts: productivity gains arrive first, while governance, testing, and runtime controls lag behind.
Key questions
Q: How should security teams manage AppSec when AI is writing code faster than humans can review it?
A: Teams should shift from discovery-centric reporting to remediation-centric governance. That means measuring mean time to remediation, prioritising exploitable findings, and embedding automated validation into the SDLC so security can keep pace with development without lowering trust in the results.
Q: Why does using AI in repositories without code review increase application security risk?
A: AI generated code can accelerate delivery, but it also bypasses the human checkpoint that catches insecure logic, licensing issues, and malicious changes. When branch protection or code review is missing, risky code can move directly into production. The risk is highest in repositories handling sensitive data or business critical systems, where a single unchecked commit can have broad operational impact.
Q: What are the signs that AppSec controls are failing under AI code velocity?
A: Common signs include growing review backlogs, more vulnerabilities appearing in generated code, slower remediation than release cadence, and repeated fixes for the same classes of flaws. When those signals appear together, the problem is usually capacity, not a single missing control.
Q: How should teams govern package installation when dependency execution is part of the attack path?
A: Treat dependency installation as a privileged execution boundary. Disable or tightly restrict install-time scripts where possible, inspect build hooks, and assume upstream code can execute with broader rights than its source context suggests. The aim is to prevent trust inheritance from becoming propagation risk.
Technical breakdown
Why AI-generated code widens the vulnerability surface
AI-generated code can accelerate delivery while still encoding insecure patterns that human reviewers would normally catch. The problem is statistical, not anecdotal: more generated code means more chances to introduce cross-site scripting, insecure object references, weak password handling, and concurrency flaws. The security gap widens when validation remains manual because humans cannot inspect the same volume at the same pace as code synthesis. In practice, this shifts AppSec from a gate at merge time to a continuous validation problem across the full delivery pipeline.
Practical implication: move high-volume code streams into automated security testing and policy checks before merge and before release.
How attacker automation changes the defensive baseline
Attackers no longer need to outwork defenders manually when AI can automate reconnaissance, exploit crafting, and movement through environments. That changes the threat baseline from isolated malicious activity to scalable operations that can run at machine speed. In AppSec terms, the risk is not only faster exploitation of known flaws but also faster discovery of weak paths, exposed services, and supply-chain opportunities. Once automation becomes symmetric, response time and control coverage matter more than point-in-time review cycles.
Practical implication: assume adversaries can test many more paths in less time and harden detection, throttling, and runtime controls accordingly.
Why package ecosystems become propagation channels
Package registries and build hooks are efficient distribution mechanisms, which is why they become attractive targets when malicious code can blend into legitimate functionality. Lifecycle hooks and dependency install paths often execute with broad permissions, so a compromised package can spread quickly before traditional scanning spots it. The key architectural issue is trust inheritance: downstream consumers adopt code and execution rights from upstream packages without re-validating every execution path. That makes supply-chain security a control problem, not just a vulnerability-management problem.
Practical implication: restrict script execution, inspect build-time behaviour, and treat dependency installation as a high-risk trust boundary.
Threat narrative
Attacker objective: The attacker objective is to scale compromise faster than defenders can validate code, inspect dependencies, or contain execution.
- Entry begins when AI-generated code, compromised packages, or automated exploit discovery introduce malicious or insecure logic into the delivery chain.
- Credential or permission abuse follows when build hooks, agents, or automated tooling inherit broad execution rights without sufficient separation.
- Impact occurs when vulnerabilities, malware, or attack automation reach production faster than review and remediation can contain them.
NHI Mgmt Group analysis
AI velocity has become an AppSec governance problem, not just an engineering productivity story. The central risk is that code creation now outpaces the control points designed around human review cycles. That creates a larger gap between what enters the pipeline and what security teams can inspect. Practitioners should treat throughput as a governance variable, not a developer preference.
Machine-speed development exposes a blind spot in traditional review-based assurance. Review, testing, and runtime enforcement were built for bounded human output, but AI-assisted production changes the volume and cadence of change. That means security effectiveness now depends on automated validation, policy enforcement, and runtime protection working together. The practitioner conclusion is that AppSec control design must assume continuous scale, not periodic inspection.
Agentic execution amplifies the same capacity gap across identity and authorization. When AI agents act inside delivery and attack workflows, permissions must be governed as runtime behaviour rather than static role assignment. This is where AppSec, IAM, and NHI governance start to converge: the security question becomes who or what can act, for how long, and under what policy boundary. Practitioners should align code security with non-human identity controls.
Supply-chain trust is now an execution risk, not only a provenance risk. Package registries, install scripts, and build hooks can turn trusted distribution into rapid propagation. That means defenders should stop treating dependency trust as a binary allow or block decision and instead model the blast radius of execution rights. The practical conclusion is to reduce inherited trust wherever automation can amplify compromise.
What this signals
AI code velocity creates an assurance debt: every new generated commit increases the amount of security evidence teams must produce, but not every organisation is adding the automation to match it. That debt shows up as delayed fixes, inconsistent validation, and controls that fail only after release.
The practical shift for 2026 is from review-centric AppSec to policy-centric AppSec. Teams that continue to depend on humans as the primary control will keep losing ground to both developer automation and attacker automation.
For practitioners
- Automate pre-merge security validation for high-volume AI code Shift repetitive AppSec checks into CI so generated code is scanned for insecure object references, XSS, password handling, and concurrency flaws before merge.
- Treat AI agent permissions as runtime controls Define what agents can access, what actions they can take, and when privilege expires, especially in delivery pipelines and other automated workflows.
- Restrict execution paths in package install workflows Block or tightly control install-time scripts, preinstall hooks, and other dependency execution paths that can propagate malicious code across environments.
- Align detection thresholds to machine-speed attack patterns Tune alerting, runtime telemetry, and containment rules for rapid reconnaissance, exploit testing, and lateral movement that can happen far faster than manual response.
Key takeaways
- AI-assisted development is widening the distance between how fast software is produced and how fast security teams can validate it.
- The quarter’s strongest signal is not any single exploit, but the convergence of code-generation risk, automated attack execution, and supply-chain propagation.
- Defenders need more automation in validation, tighter execution boundaries in build pipelines, and runtime controls that assume machine-speed abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, OWASP ASVS and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article cites automated attack execution and movement through environments. |
| Recommendation — Map AI-enabled attack automation to TA0006 and TA0008, then prioritise detections that catch rapid credential abuse and movement. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The core problem is insecure code entering production faster than teams can validate it. |
| Recommendation — Apply CIS-16 to harden secure development checks and automate validation for code entering the pipeline. | ||
| OWASP ASVS | V1 — Encoding and Sanitization | The article highlights XSS and other code-level flaws that ASVS helps verify. |
| Recommendation — Use ASVS V1 to enforce input handling and encoding checks in generated and human-written code alike. | ||
| SLSA | L3 — Build provenance | The supply-chain section centres on trusted build and package execution paths. |
| Recommendation — Adopt SLSA L3 provenance controls to reduce the chance that compromised dependencies reach production unnoticed. | ||
Key terms
- AI-Generated Code Risk: AI-generated code risk is the possibility that model-produced output introduces insecure credential handling, hidden secrets, or repeated patterns that weaken control design. The risk is operational, because the output can be merged quickly and at scale before humans catch the problem.
- Capacity Gap: The mismatch between the pace of software or threat generation and the pace of human review, testing, and response. In security programmes, capacity gaps show up as backlogs, slower remediation, and controls that are technically present but operationally ineffective.
- Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
- Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It helps security teams connect identity controls to modern automation patterns across development and operations.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org