Vibe coding is creating new identity and access management debt

At a glance

What this is: This analysis argues that vibe coding turns AI-generated software into an identity and access management problem by multiplying over-scoped permissions, embedded secrets, and unmanaged non-human identities.

Why it matters: IAM and NHI teams need to treat generated infrastructure as a governance surface because the access decisions inside the code can outlive the developer’s intent.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read P0 Security's analysis of the identity risks of vibe coding

Context

Vibe coding is a shorthand for building software by prompting an AI, reviewing the output loosely, and iterating toward something that works. The security problem is that access control, secret handling, and workload identity decisions are baked into code that may not be fully understood by the person shipping it. For IAM and NHI governance, that means the usual assumption that developers can explain and review the permissions they create starts to break down.

The article’s core claim is not that AI invents new identity flaws. It is that it accelerates familiar ones: broad permissions, credential leakage, and identities that outlive their purpose. That is a typical pattern for emerging development modes. The difference here is scale, speed, and reduced human visibility into what the generated code actually grants.

Key questions

Q: How should security teams govern IAM for vibe-coded applications?

A: Security teams should treat generated IAM as production access logic, not as developer convenience. The right control set includes explicit policy review, least-privilege enforcement at deployment, short-lived credentials, and identity inventory tied to ownership and expiry. If the access model cannot be explained quickly, it should not be allowed to persist.

Q: Why does vibe coding increase non-human identity risk?

A: Vibe coding increases NHI risk because it creates more service accounts, API keys, and machine roles faster than governance teams can track them. The identities often outlive the application that created them, which leads to orphaned access, unclear ownership, and delayed revocation. That is a lifecycle failure, not just a coding issue.

Q: What is the difference between code review and access review in AI-generated software?

A: Code review checks whether the application works and whether the logic is acceptable. Access review checks whether the workload has the minimum permissions, secret handling, and identity lifecycle needed to operate safely. In vibe coding environments, both are necessary, because functional code can still carry dangerous privilege.

Q: When does JIT access help with vibe coding risks?

A: JIT access helps when the main concern is persistent privilege attached to generated workloads or human operators. It reduces standing exposure by issuing credentials only when a task needs them. It is less effective if secret sprawl, overly broad policies, or poor inventory remain unresolved, because those problems can still recreate the blast radius.

Technical breakdown

How vibe coding changes IAM policy generation

When developers ask an AI to build cloud functions, dashboards, or internal tools, the model often produces access policies that are functional rather than minimal. That usually means broad permissions, generic resource scopes, and patterns that pass tests more easily than a tightly constrained policy would. The important technical point is that the IAM decision is embedded in generated code, not applied later as a separate control. Once deployed, the permission is real even if nobody fully reviewed its exact effect.

Practical implication: Treat AI-generated IAM as production access logic that requires explicit least-privilege review before deployment.

Credential handling failures in generated code

Generated code commonly introduces secrets exposure through environment files, logging, placeholder credentials, or copied connection strings. The risk increases because developers may not recognise the credential pattern inside code they did not write themselves. If AI assistants can inspect the repository, the exposure boundary expands further because a leaked secret is no longer only visible to a human reviewer. In NHI terms, secret discovery and identity governance become the same control problem.

Practical implication: Scan generated code for hardcoded secrets and insecure credential flows before commit and before build.

Why vibe coding accelerates NHI sprawl

Every deployed AI-assisted application tends to create service accounts, API keys, OAuth clients, or machine roles. The identity problem is lifecycle drift: identities are created quickly, ownership is unclear, and decommissioning happens late or not at all. This is how NHI sprawl develops. The technical failure mode is not just too many identities, but too many identities whose purpose, owner, and expiry are not reliably tracked.

Practical implication: Bind each generated workload to an owner, lifecycle record, and retirement trigger from day one.

Threat narrative

Attacker objective: The attacker wants durable access through neglected non-human identities and over-scoped permissions rather than a one-time exploit.

1. Entry occurs when AI-generated code introduces over-broad IAM roles or exposed credentials into a workload that appears to function correctly.
2. Escalation happens when those permissions or secrets are reused by adjacent tools, repositories, or assistants that can read the same environment.
3. Impact is persistent access exposure, because the identity often remains active long after the developer has moved on or the code has changed.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vibe coding is an IAM problem before it is a software engineering problem. The article correctly places access scope, secret handling, and identity lifecycle at the center of the risk. That is the right framing for practitioners because code generation changes who can create permissions, not whether permissions matter. Security teams should treat generated infrastructure as governed access material, not as benign development output.

Ephemeral authoring does not create ephemeral access. The fact that a human did not hand-write the policy does not make the resulting privilege temporary or safe. Generated IAM often survives far longer than the context that created it, which means blast radius is governed by lifecycle controls, not by developer intent. Practitioners should assume every generated role can become long-lived debt unless it is actively bounded.

Identity blast radius is the right concept for vibe-coded systems. The article’s strongest insight is that the security issue is not just secret leakage or over-privilege in isolation, but the combined effect of both across many fast-moving workloads. That creates a compounding exposure surface where one weak credential can affect multiple services. The practical conclusion is to design containment around every generated identity.

Least privilege must move from review guidance to deployment enforcement. In vibe coding workflows, human review alone is too fragile because the person approving the code may not understand the generated access model well enough to judge it. That shifts the control point to policy gates, automated analysis, and runtime constraints. The programme implication is simple: if access can be generated quickly, access must also be constrained automatically.

Lifecycle governance is the missing control plane for AI-assisted development. Organisations can no longer rely on project teams remembering which service account belongs to which generated application. Without discovery, ownership, rotation, and decommissioning, vibe coding turns into permanent NHI accumulation. The field should now treat AI-assisted development as a lifecycle management problem with security consequences.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For the lifecycle view, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how rotation and offboarding should be tied to generated workloads.

What this signals

Identity blast radius is now a development outcome, not just a security metric. As AI-assisted coding accelerates workload creation, security teams need a tighter view of where generated identities live, who owns them, and how they are retired. With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per Ultimate Guide to NHIs, the governance gap is already structural rather than theoretical.

Vibe coding will force IAM programmes to become more lifecycle-driven and less review-driven. That means moving from occasional approval of permissions to continuous discovery, expiry enforcement, and offboarding discipline, especially for workload identities created as side effects of rapid delivery.

For practitioners

• Require explicit review of generated IAM policies Route every AI-generated cloud permission block through a security review that checks resource scope, action breadth, and unintended wildcard access before deployment.
• Add secret scanning to pre-commit and CI gates Detect hardcoded API keys, connection strings, and credential-like patterns in generated code before they reach repositories or build pipelines.
• Enforce zero standing privilege for generated workloads Issue short-lived, task-scoped credentials for AI-assisted applications and remove persistent access by default unless a documented exception exists.
• Inventory every non-human identity created by AI-assisted work Map service accounts, OAuth clients, machine roles, and API keys to an owner, application, and expiry date so orphaned identities can be retired on schedule.
• Gate deployment on blast radius containment Use platform controls that limit what a generated identity can reach even if the policy is broader than intended, including resource-level constraints and conditional access.

Key takeaways

• Vibe coding turns generated software into an identity governance problem because the access decisions live inside the code.
• The main risks are over-scoped permissions, exposed secrets, and orphaned non-human identities that outlast the application.
• Security teams should enforce least privilege, short-lived credentials, and lifecycle ownership before generated workloads reach production.

Key terms

• Vibe Coding: A development pattern where a developer prompts an AI to produce working code, then reviews and iterates loosely rather than designing every detail up front. In security terms, it shifts risk into generated IAM policies, secret handling, and workload identities that may be deployed faster than they can be understood.
• Identity Blast Radius: The amount of damage a single identity can cause if it is misused, over-scoped, or compromised. In NHI environments, blast radius depends on permissions, secret exposure, and how long the identity stays active, which makes lifecycle control as important as initial provisioning.
• Zero Standing Privilege: A model where access is not kept permanently on an identity but is issued only when a task needs it. For AI-assisted workloads, this reduces persistent exposure by replacing always-on credentials with short-lived, task-scoped access that expires automatically.
• NHI Sprawl: The uncontrolled growth of non-human identities such as service accounts, API keys, OAuth clients, and machine roles. It becomes a governance problem when ownership, purpose, rotation, and decommissioning are unclear, leaving dormant credentials active long after their original use case ends.

What's in the full article

P0 Security's full post covers the operational detail this post intentionally leaves for the source:

• Policy review patterns for AI-generated IAM and cloud permissions
• Examples of how service accounts and API keys accumulate in vibe-coded workloads
• Operational guardrails for zero standing privilege in AI-assisted development
• Recommended scanning points for secrets and overly permissive policy documents

👉 P0 Security's full post covers the access patterns, lifecycle gaps, and remediation focus in more detail.

Deepen your knowledge

Vibe coding and IAM debt are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams are building AI-assisted workloads, the course helps translate that risk into practical governance.