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.
At a glance
What this is: Apiiro’s analysis shows AI coding assistants are increasing software delivery speed while amplifying security findings, exposed credentials, and review complexity.
Why it matters: IAM, PAM, NHI, and application security teams need to treat AI-generated code as a control problem, because faster code output can also spread secrets, privilege mistakes, and authentication failures more quickly.
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.
Context
AI coding assistants change the economics of software delivery by increasing the volume and scope of change that reaches review. When those changes include authentication logic, authorization headers, secrets, and cloud configuration, the security problem is no longer just code quality. It becomes a governance problem spanning application security, identity control, and operational review.
The article’s central point is that review models built for human-paced change do not scale cleanly to AI-assisted output. Larger pull requests, more frequent commits, and more multi-file edits widen the chance that insecure patterns, leaked credentials, and design flaws move forward together.
For identity teams, the most important intersection is credential handling inside AI-generated changes. If developers can introduce service principals, storage keys, or authorization failures faster than review can reliably inspect them, then NHI governance has to move earlier in the software lifecycle.
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 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. Those artefacts can hold reusable secrets outside the normal repository scanning path, so the workstation becomes a practical extension of the credential estate.
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. If review queues are growing while the number of touches per merge also increases, the process is losing inspection quality. That usually means the team is measuring throughput, not control effectiveness.
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.
Technical breakdown
Why AI-generated code overwhelms review controls
AI coding assistants change the structure of change, not just the speed. They tend to produce more commits but package them into fewer, larger pull requests that touch more files and services at once. That matters because review is a sampling control, not a guarantee of full semantic understanding. When a change spans authentication logic, infrastructure code, and application behavior, the chance of a missed dependency rises sharply. The result is not only more defects, but more defects that are coupled together inside the same merge, making them harder to isolate after release.
Practical implication: Treat large AI-assisted pull requests as higher-risk review events and apply stricter merge gates when authentication or secrets change.
How AI code turns small errors into architectural flaws
The article draws a clear distinction between shallow defects and systemic ones. AI tools can reduce syntax mistakes and some logic bugs, but they can also introduce architecture-level weaknesses such as privilege escalation paths and broken auth flows. These are harder to catch because they often look syntactically correct and may pass basic automated checks. In practice, that means static scanning alone is insufficient when the defect lives in the interaction between services, policy enforcement, and identity context. The control gap is not just code correctness, but design correctness under automation.
Practical implication: Add design-level security review for AI-generated changes that affect trust boundaries, privilege paths, or service-to-service authentication.
Why secret leakage becomes a faster-moving NHI problem
AI-assisted code can propagate cloud credentials across more files, configs, and services before anyone notices. A leaked service principal or storage key is not merely a coding mistake; it is a live non-human identity with immediate access potential. That creates a broader NHI governance issue because the exposure window begins at authoring time, not after deployment. Once a secret is copied into multiple generated artifacts, revocation becomes harder and blast radius increases. The underlying pattern is credential spread at machine speed, which is exactly where conventional manual review is weakest.
Practical implication: Scan AI-generated changes for NHI secrets before merge and couple detection with immediate revocation and rotation workflows.
Threat narrative
Attacker objective: The attacker objective is to convert AI-assisted development mistakes into usable access paths, credential exposure, and production compromise.
- Entry occurs through AI-generated code changes that introduce new secrets, auth logic, or infrastructure configuration into the repository.
- Credential exposure follows when service principals, storage keys, or other machine credentials are embedded or propagated across multiple files and services.
- Escalation happens when weak authorization or design flaws create privilege paths that reviewers and scanners miss before deployment.
- Impact is production exposure, where leaked credentials and broken auth controls can enable unauthorized access or broader cloud compromise.
Breaches seen in the wild
- 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.
- 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).
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 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.
Large AI-assisted pull requests create a review illusion. Human reviewers often assume that more automation means more safety, but the article shows the opposite can happen when change volume rises faster than human comprehension. Bigger PRs concentrate multiple flaws into a single merge event, which increases the odds of silent failure in authorization, dependency handling, and secret propagation. The practical conclusion is that review quality must be measured by change complexity, not commit count alone.
Credential leakage inside AI-generated code is a machine-identity failure mode. Service principals and storage keys are not incidental secrets once they appear in generated code, because they become operational access paths. This is where NHI controls need to move left into development workflows, with detection, revocation, and scope checks tied to code generation. Teams that still treat secrets exposure as a post-merge hygiene issue are already behind.
AI AppSec has to be policy-aware or it will simply automate bad patterns faster. The article’s key lesson is that fixing syntax and scanning for known patterns is not enough when the real risk sits in architectural drift and cross-service trust. A practical programme needs context-aware enforcement that understands code, runtime, and policy together. That is the difference between faster delivery and safer delivery.
Named concept: AI review compression. This is the point at which AI-assisted output compresses many changes, many risks, and many trust decisions into fewer review moments. Once that compression happens, traditional merge review no longer reflects the true risk surface. Practitioners should redesign guardrails around the compressed change unit, not the individual line or commit.
From our research library:
- According to PwC, 79% of organizations have already adopted AI agents to some degree.
- Read next: Agentic AI Security Guide
What this signals
AI review compression: AI coding is compressing more logic, more trust decisions, and more exposure into fewer review moments. That changes the control problem from catching individual bugs to governing the complexity of each merged change, which is why code review, secrets scanning, and policy enforcement need to operate together.
The immediate programme implication is that appsec teams must stop treating AI-generated code as a normal throughput increase. The risk signal is not only more findings, but more high-impact findings tied to auth flows, cloud credentials, and privilege paths.
AI-assisted development is also widening the gap between adoption and preparedness. According to the 2026 Infrastructure Identity Survey, 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments.
For practitioners
- 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.
- Separate productivity metrics from security metrics Track commit volume, PR size, secret exposure, and privilege-related findings together so leadership can see whether AI adoption is shifting risk into the release pipeline.
Key takeaways
- AI coding assistants are shifting security work from small syntax review to higher-risk change governance across authentication, secrets, and service boundaries.
- The article shows that faster delivery can coincide with more security findings, more credential exposure, and larger blast radius per merge.
- Teams that mandate AI coding without parallel AI AppSec controls are likely to scale release risk faster than they scale developer productivity.
Key terms
- AI Review Compression: The concentration of many code changes, trust decisions, and security risks into fewer review moments because AI tools generate larger or denser pull requests. This reduces the practical effectiveness of human review and increases the chance that coupled defects reach production together.
- Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.
- Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
- Network-Aware AppSec: Network-aware AppSec is an application security approach that checks how software behaves in real environments, not just how it looks in source code. It combines code analysis with infrastructure and exposure validation to catch open ports, insecure listeners, and policy gaps before release.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It helps security and identity practitioners translate machine-identity risk into controls that fit real programmes.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org