In a nutshell
“Vibe coding” is becoming a common development pattern. It lowers the barrier to building functional software, which is genuinely useful. It also produces a category of identity and access risk that most security teams have not yet accounted for. Code that no one fully understands tends to request more permissions than it needs, embed credentials in ways that are hard to find, and spin up identities that outlive their purpose. Vibe coding quickly accumulates compounding IAM debt.
The model did not invent over-privileged access. It industrialised it.
What vibe coding actually means for identity
The term was coined by Andrej Karpathy in early 2025 to describe a mode of development where the developer prompts an AI, reviews outputs loosely, and iterates toward a working result, sometimes without deeply understanding the implementation details. For prototyping, internal tooling, and rapid experimentation, this is often a reasonable trade-off. The problem is that infrastructure and access decisions are embedded directly into the generated code: IAM policies, permission scopes, API key handling, and service account configurations. Those decisions do not become safer simply because a human did not consciously design them.
When a developer asks an AI to “build a Lambda function that reads from S3 and writes results to a DynamoDB table,” the AI will produce something that works. It will also, by default, tend to generate an IAM role with permissions scoped to the task at hand but without the fine-grained, resource-level constraints that a security-conscious engineer would apply. Broad s3:* is easier than s3:GetObject scoped to a specific bucket ARN. The code runs. The review might be cursory. The privilege exists indefinitely.
A similar pattern appeared in the PocketOS incident discussed in my last blog. The problem was not that the AI agent invented a destructive capability. It was that an over-scoped credential already existed, persisted longer than anyone intended, and was reachable by an actor operating faster than the surrounding governance model assumed. Vibe-coded infrastructure creates the same conditions at scale: identities that work, permissions that are broader than necessary, and ownership boundaries that become unclear once the application is running.
A common example looks deceptively harmless. A developer prompts an AI assistant to “connect this internal dashboard to production billing data.” The generated implementation creates a service account with read access across the entire billing dataset because broad access resolves testing issues more reliably than tightly scoped permissions. The dashboard works. The developer ships it. Six months later, no one remembers the service account exists, but the credential remains active, over-privileged, and accessible to every workflow connected to that environment.
Three places where identity risk accumulates
Over-provisioned roles as the path of least resistance
AI code generation tools optimise for working code, not least-privilege code. When generating IAM policies, Terraform configurations, or cloud SDK calls, they will default to permission sets broad enough to cover common use cases because that produces fewer errors during testing. The developer’s goal is a functioning application, and the AI’s implicit goal is the same. Neither is optimising for minimum access surface. The result is infrastructure that works correctly and is chronically over-privileged; because the developer did not write the IAM policy themselves, they often cannot easily assess what it actually grants.
Hardcoded and mishandled credentials
AI-generated code frequently uses placeholder credentials that developers then populate with real values and those values sometimes travel further than intended. API keys appear in environment variable files that get committed. Connection strings end up in configuration objects that are logged. Short-lived tokens get cached in ways that extend their effective lifetime. These are not new problems, but vibe coding accelerates them because developers have lower familiarity with the implementation and are less likely to catch the patterns that create exposure. A developer who wrote the database connection logic themselves is more likely to notice credentials being handled incorrectly. One who accepts AI-generated output has less context to work from.
The problem also becomes more acute when AI coding assistants themselves have access to the repository. A credential accidentally committed to a configuration file is no longer just a risk if a human notices it. It becomes a risk if the agent notices it. If the assistant can search the codebase, read environment files, or inspect deployment scripts, then every exposed secret within its visibility scope effectively becomes part of its accessible privilege set. In practice, this means secret discovery and identity governance can no longer be treated as separate concerns.
Non-human identity sprawl from unreviewable infrastructure
Each vibe-coded application that reaches production creates a set of non-human identities: service accounts, OAuth clients, API keys, machine roles. These identities need to be provisioned, scoped, monitored, and eventually decommissioned. In organisations where vibe coding is common, this inventory grows faster than governance processes can track it. The developer who built the application may not know which service account it uses. The team that owns the cloud account may not know the application exists. When the application is retired or the developer moves on, the identities frequently remain: active, credentialed, and attached to permissions that were generous from the start.
Recommendations
The response to vibe coding is not to prohibit it. It is to apply identity governance to the outputs, not just the process.
- Treat AI-generated IAM policies as requiring explicit review. Any code that configures cloud permissions should go through a review step focused specifically on access scope, independent of whether the functional logic has been reviewed. Automated policy analysis tools can help flag overly broad permissions before they reach production.
- Enforce least-privilege as a deployment gate, not a coding standard. In a vibe coding workflow, controls that depend on the developer fully understanding the generated implementation do not reliably hold up. Least privilege cannot remain a documentation exercise or a best-practice recommendation. It needs to be enforced at the platform layer through guardrails that constrain what can be deployed regardless of how the code was produced.
- Default vibe-coded workloads to zero standing privilege. AI-generated applications should not persist long-lived credentials simply because it is operationally convenient. Short-lived, scoped credentials issued per session dramatically reduce the blast radius of generated infrastructure.
- Inventory non-human identities created by AI-assisted development. If teams are generating and deploying infrastructure rapidly, identity discovery needs to keep pace. A continuously updated view of service accounts, API keys, and machine roles, mapped to their owning application and team, is the foundation for managing the lifecycle correctly.
- Apply lifecycle policies to vibe-coded workloads explicitly. When a project built through AI-assisted development ends, the associated identities need to be decommissioned as part of the close-out process. This requires that someone is accountable for those identities, which requires they were tracked in the first place.
- Scan generated code for credential handling patterns before commit. Pre-commit hooks and CI pipeline checks that detect hardcoded secrets, insecure credential storage, and overly permissive policy documents catch the most common issues before they are deployed. These controls are not new, but they become more important as the volume of generated code increases.
- Design for blast radius containment, not perfect review. In an environment where AI-assisted development dramatically increases the volume of generated infrastructure and access configurations, some overly broad permission will eventually reach production. The security model cannot depend on every generated IAM policy being reviewed perfectly before deployment. It needs to assume mistakes will occur and ensure no single credential, service account, or workload can become a terminal failure event when they do.
In a nutshell…
Vibe coding changes the relationship between a developer and the code they ship. It does not change the fact that code carries identity and access decisions, and that those decisions have consequences. The IAM policy an AI generates is just as binding as one a human wrote and in practice it is often broader, less documented, and attached to identities that no one is actively managing.
Security and identity teams that want to stay ahead of this trend need to focus less on where the code came from and more on what identities, permissions, and long-lived access paths it creates. TThe critical question is no longer whether the developer fully understood the generated implementation. It is whether the resulting access model is governed tightly enough that inevitable mistakes remain survivable.