TL;DR: AI coding assistants can speed up scaffolding and boilerplate, but multiple studies cited by Cerbos show that experienced developers often slow down, review burden rises, and insecure output can increase privilege paths and secrets exposure. The real issue is not typing speed but whether production-ready code, credentials, and review gates can keep up.
At a glance
What this is: This analysis argues that AI coding assistants create a productivity illusion while widening security and compliance risk in development pipelines.
Why it matters: It matters because IAM, PAM, and secrets governance teams must now account for AI-assisted code paths that can accelerate both delivery and credential exposure.
By the numbers:
- In July 2025, the METR randomized trial found experienced open source developers using AI tools were on average 19% slower.
- Only 16.3% of developers said AI made them more productive to a great extent in the 2025 Stack Overflow Developer Survey.
- Faros AI found teams with high AI adoption interacted with 9% more tasks and 47% more pull requests per day.
👉 Read Cerbos' analysis of AI coding assistants, productivity, and security risk
Context
AI coding assistants are tools that generate code, suggest fixes, and answer implementation questions from prompts. In development teams, the governance issue is not whether they save keystrokes. It is whether they change the control assumptions around review, testing, secrets handling, and privileged access in ways existing IAM and SDLC processes were not designed to absorb.
For NHI and identity teams, the important shift is that these assistants sit inside the software delivery path and can interact with credentials, repositories, CI/CD, and cloud permissions. That creates a security and governance problem that crosses application delivery, secrets management, and machine identity. The question is no longer just developer productivity. It is how much trust the organisation is willing to extend to AI-assisted change.
Cerbos frames the issue around a productivity gap, but the deeper concern is operational: faster drafting does not equal safer software. Where AI output enters production workflows, the review burden moves from writing code to validating intent, permissions, and hidden side effects.
Key questions
Q: How should teams govern AI coding assistants in production software delivery?
A: Treat AI coding assistants as privileged workflow components, not neutral productivity aids. Define what they may read, generate, or trigger, and keep them out of paths that can reach secrets, build systems, or cloud control planes unless access is explicitly scoped and monitored. Governance should focus on the blast radius of the assistant, not only its output quality.
Q: When do AI coding assistants create more risk than they reduce?
A: They create more risk when the organisation assumes faster drafting equals safer delivery. If assistants can introduce secrets, privilege paths, or insecure defaults faster than review and remediation can keep up, they increase operational risk. The tipping point is when validation work exceeds the time saved on initial code generation.
Q: What do security teams get wrong about AI-generated code?
A: The common mistake is reviewing AI output only for obvious bugs and syntax errors. Security issues often appear in permission boundaries, secret handling, and dependency choices that look reasonable at first glance. Teams need to inspect whether the generated change alters trust assumptions, not just whether it compiles.
Q: How can organisations tell whether AI-assisted development is actually working?
A: Use downstream indicators such as escaped defects, rework after merge, security findings, and time spent validating generated code. If the assistant increases review load, secret exposure, or release friction, the apparent speed gain is likely being paid back later in the delivery lifecycle.
Technical breakdown
AI-assisted coding and the production gap
AI assistants are strongest at scaffolding, boilerplate, and quick retrieval of implementation patterns. They are much weaker at architecture fit, edge cases, and code paths that must survive scale, compliance review, and repeated deployment. That is why they can feel faster in short sessions while adding net work later. In mature delivery environments, the limiting factor is not code generation speed but the number of human checks needed before merge, release, and runtime exposure.
Practical implication: measure AI value at production-readiness stages, not at first draft generation.
Context rot, prompt drift, and code quality decay
Long AI sessions often degrade output quality because the model begins to overweight earlier prompts, irrelevant details, and stale assumptions. The result is code that looks plausible but subtly misses requirements, which is why developers describe it as almost right but not quite. In practice, this creates a new review problem: teams must inspect not just syntax and logic, but whether the assistant has drifted away from the original intent as context accumulates.
Practical implication: break AI-assisted work into smaller, bounded tasks with explicit acceptance criteria.
New attack surfaces in coding assistants and extensions
Coding assistants expand the trusted computing base by adding plugins, local runtimes, and cloud-connected extensions into the developer workflow. That widens the path for prompt injection, poisoned updates, credential exposure, and unintended command execution. The risk is not the model alone. It is the privileged placement of the assistant between developer intent, local code, and cloud infrastructure. Once those tools can touch repositories or infrastructure, they inherit the blast radius of the environment they are embedded in.
Practical implication: treat coding assistants and extensions as privileged software supply chain components.
Threat narrative
Attacker objective: The attacker aims to turn a trusted developer productivity tool into a path for code execution, secret theft, or infrastructure misuse.
- Entry occurs through AI coding assistants, plugins, or extensions that are granted access to local repositories, cloud tooling, or developer machines.
- Escalation follows when poisoned prompts, hidden instructions, or exposed secrets are acted on inside a trusted workflow with broad permissions.
- Impact is code execution, secret exposure, or unwanted infrastructure action, including destructive changes and privilege abuse across development environments.
Breaches seen in the wild
- Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
- CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI coding assistants are not just productivity tools. They are privileged participants in the software delivery trust chain. Once an assistant can read code, suggest changes, and interact with extensions or cloud-connected tooling, it becomes part of the control surface around identity, secrets, and release governance. That means the security question is no longer only whether developers like the tool. It is whether the organisation has defined what authority the tool should have in the first place. Practitioners need to treat these systems as governed participants, not neutral helpers.
Privilege escalation paths in AI-generated code show a governance problem, not just a code quality problem. The article cites research showing materially higher privilege escalation paths, more hard-coded secrets, and more reviewer comments on security issues. That combination tells us the failure is upstream of scan tools. The organisation has allowed rapid code creation without equivalent controls on entitlement design, secret handling, and review depth. Security teams should read this as a release governance signal, not a developer ergonomics debate.
Context rot is a named operational concept for AI-assisted development risk. As prompts accumulate, the model can drift from the original implementation goal and produce output that is almost correct but structurally misaligned. That matters because the final 30% of production readiness is where design intent, exception handling, and security constraints are enforced. The implication for practitioners is that AI-assisted delivery is not a linear speed gain. It creates a new validation burden that must be built into the lifecycle.
Coding assistants enlarge the machine identity problem inside the SDLC. The more these tools interact with repositories, CI/CD, and cloud permissions, the more they rely on service accounts, tokens, and tightly scoped machine access. That widens the importance of secrets governance, short-lived credentials, and explicit workload identity boundaries. The practical conclusion is that AI delivery workflows should be governed as identity-first systems, not just developer tooling.
What looks like acceleration in the boardroom often becomes rework in the control plane. Leadership tends to measure AI by the first draft, while engineering and security pay for the review, correction, and containment phases. That mismatch explains why the productivity story remains persuasive but operationally incomplete. Practitioners should align measurement with shipped, trusted code rather than prompt throughput.
From our research:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- From our research: The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- For a deeper governance lens, see Guide to the Secret Sprawl Challenge for how secret sprawl undermines control even when teams believe their posture is mature.
What this signals
Context rot is becoming an SDLC governance signal, not just a developer annoyance. When AI-generated output becomes harder to trust as context accumulates, teams need smaller task boundaries, stricter acceptance criteria, and explicit review gates for generated code. The practical signal is simple: if validation effort keeps rising, AI is shifting work rather than removing it.
With 32.4% of security budgets already going to secrets management and code security, the control problem is moving into the software factory itself. That budget share suggests the organisation is paying for risk after code has already been generated, reviewed, or exposed. For identity and platform teams, the signal is to connect assistant governance with secrets hygiene and workload identity. See the NIST Cybersecurity Framework 2.0 for the control lifecycle that should surround these workflows.
AI-assisted delivery needs identity-aware guardrails across human, machine, and workflow access. The same programme that governs service accounts and secrets should also determine what an assistant can touch, what it can propose, and what must never be delegated to generated code. That alignment is where the next control gap will be found.
For practitioners
- Define assistant privilege boundaries Limit what coding assistants, plugins, and extensions can access in the developer environment. Separate read-only code help from any workflow that can reach repositories, secrets stores, build agents, or cloud consoles.
- Require secret-safe development workflows Block API keys, tokens, and credentials from being pasted into prompts or shared with external AI systems. Pair this with secret scanning and a review step for any AI-assisted change that touches configuration or infrastructure code.
- Tighten review for AI-generated privilege changes Route changes that affect roles, service accounts, or permission checks through deeper scrutiny than ordinary feature work. Watch especially for code that introduces new escalation paths, hidden dependencies, or broad default access.
- Measure production readiness, not prompt speed Track defect escape rate, security review burden, and rollback frequency for AI-assisted work. Those measures show whether the assistant is reducing delivery friction or simply moving effort into later stages of the pipeline.
Key takeaways
- AI coding assistants can reduce typing but still increase total delivery effort when review, debugging, and security validation expand.
- The sharper risk is not speed alone, but the way AI-assisted code can increase secrets exposure, privilege paths, and release-time control failures.
- Practitioners should govern coding assistants as privileged workflow components and measure production readiness, not prompt throughput.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | AI assistants touch secrets and machine credentials in the delivery pipeline. |
| NIST CSF 2.0 | PR.AC-4 | AI-enabled development changes how access and trust must be controlled across pipelines. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust is relevant where assistants can reach cloud and developer assets. |
Map assistant permissions into access control reviews and limit standing access to build resources.
Key terms
- AI Coding Assistant: An AI coding assistant is a tool that generates, explains, or modifies software code from prompts and context. In practice it can reduce boilerplate work, but it also introduces trust questions around review, secret handling, and whether generated changes match the intended architecture and permission boundaries.
- Context Rot: Context rot is the tendency for an AI model's output quality to degrade as a session accumulates more prompts, assumptions, and irrelevant detail. The model can drift from the original task, producing code that looks plausible but no longer fits the security, architecture, or production requirements.
- Secrets Exposure: Secrets exposure is the accidental disclosure of credentials such as API keys, tokens, and certificates to places the organisation does not control. In AI-assisted workflows, this can happen when developers paste sensitive material into prompts, logs, or extensions that retain data outside the intended boundary.
- Privilege Escalation Path: A privilege escalation path is a route in code or infrastructure that lets an identity gain more access than intended. In AI-generated code, these paths can appear in permission checks, defaults, or scaffolding choices that look harmless but widen the authority of the resulting system.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Cerbos: AI coding assistants expose the gap between speed and production safety. Read the original.
Published by the NHIMG editorial team on 2025-09-12.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org