Topic starter
19/08/2026 3:54 pm
TL;DR: AI-assisted developers produced 3 to 4 times more commits, generated 10 times more security findings, and exposed cloud credentials nearly twice as often as non-AI peers in Apiiro’s analysis of Fortune 50 codebases, indicating that productivity gains are being matched by a much larger security burden. The governance problem is not code generation itself, but the breakdown of review, design, and secret-handling controls as AI expands change volume and blast radius.
Editorial analysis by NHI Mgmt Group, based on content published by Apiiro: “4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks”.
By the numbers:
- Apiiro found 10 times more security findings in AI-assisted code.
- By June 2025, AI-generated code was introducing over 10,000 new security findings per month across the study repositories.
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.
Q: Why do AI coding tools increase the risk of credential exposure on laptops?
A: They create more local artefacts where access material can persist, including context caches, configs, and workflow by-products that are easy to overlook.
Q: What signs show AI-assisted development is outpacing security review?
A: The clearest signs are rising pull request size, fewer but denser merges, more findings per change, and an increase in privilege or secret-related defects.
Practitioner guidance
- Implement risk-tiered review for AI-assisted pull requests Require elevated approval, design review, or automated policy checks when AI-generated changes touch authentication, authorization, secrets, or cloud configuration.
- Block machine credentials in generated code Scan repositories and CI output for service principals, API keys, access tokens, and storage keys before merge, then revoke exposed NHI credentials immediately.
- Add design-aware controls to AppSec gates Use context-aware analysis for large multi-file changes so reviewers can see when an AI-generated edit alters trust boundaries, privilege paths, or service-to-service assumptions.
Bottom line: AI coding assistants are shifting security work from small syntax review to higher-risk change governance across authentication, secrets, and service boundaries.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:31 pm
AI coding is now an identity and governance problem, not just a developer productivity problem. When code assistants can introduce secrets, service principals, and auth logic faster than review can reason about them, the security issue shifts from code generation to control placement. That makes the boundary between application security and NHI governance much thinner than many teams assume. Practitioners should treat AI-assisted change as a lifecycle control problem, not a tooling preference.
A few things that frame the scale:
- According to PwC, 79% of organizations have already adopted AI agents to some degree.
A question worth separating out:
Q: How should organisations govern AI coding agents in the SDLC?
A: Treat them as privileged non-human identities with named owners, narrow task scope, and explicit offboarding. Governance should align access to the exact development activity, not to a broad team role or permanent environment trust. That is the difference between using the agent safely and leaving it as an unowned execution path.
👉 Read our full editorial: AI coding adoption is scaling appsec risk faster than review