When Andrej Karpathy coined "vibe coding" in early 2025, he highlighted a trend many development teams already recognized: using AI to generate code quickly without fully understanding it. This approach is fast and effective, but it's quietly reshaping your IAM attack surface.
The myths below persist because vibe coding seems like a developer workflow issue, not an identity problem. However, every AI-generated Lambda function involves IAM decisions. Each generated API integration creates service accounts. The code ships with permissions attached, and those permissions don't expire just because no human consciously designed them.
Myth 1: "AI-generated code is just faster development, it doesn't change our security model"
Reality: AI-generated infrastructure embeds access decisions that bypass your existing review processes.
When a developer prompts an AI to "build a Lambda that reads S3 and writes to DynamoDB," the output includes an IAM role. This role wasn't designed by someone who knows your least-privilege standards. It's optimized to work during testing, meaning it's broad enough to avoid permission errors. s3:* is easier than s3:GetObject constrained to a specific bucket ARN.
The functional code gets reviewed, but the IAM policy often doesn't. The developer who accepted the generated output can't easily assess what it actually grants. You're not shipping faster code; you're shipping faster privilege creep.
Myth 2: "Our pre-commit hooks catch hardcoded secrets, so we're covered"
Reality: AI coding assistants can read the secrets your hooks would catch, turning secret discovery into an access path.
Pre-commit scanning stops credentials from reaching your repository. But if your AI assistant has repository access, it can read environment files, deployment scripts, and configuration objects. A credential accidentally committed becomes accessible not just if a human finds it, but if the agent does.
This changes the threat model. Secret discovery and identity governance are no longer separate problems. Every exposed credential within the assistant's visibility scope effectively becomes part of its privilege set. Scanning tools need to account for assistants that can search the codebase before anything ships.
Myth 3: "We'll tighten permissions after the prototype works"
Reality: Vibe-coded infrastructure rarely gets revisited, and over-privileged roles become permanent.
Consider a team that prompts an AI to connect an 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 edge cases more reliably than tightly scoped permissions. The dashboard works, and the developer ships it.
Six months later, no one remembers the service account exists. The credential remains active, over-privileged, and accessible to every workflow in that environment. The "we'll fix it later" assumption fails because there's no forcing function. The application works, the developer has moved on, and the IAM policy is now infrastructure no one owns.
Least privilege can't be a post-deployment cleanup task. It needs to be a deployment gate that constrains what can reach production, regardless of how the code was written.
Myth 4: "Non-human identities are tracked in our IGA system"
Reality: Vibe coding creates service accounts faster than governance processes can inventory them.
Each AI-generated application that reaches production spins up OAuth clients, API keys, machine roles, and service accounts. In organizations where vibe coding is common, this inventory grows faster than manual tracking can keep pace. 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 project ends or the developer leaves, the identities remain: active, credentialed, and attached to permissions that were generous from the start. You can't decommission identities you don't know about, and you can't enforce lifecycle policies on infrastructure that was never formally registered.
Continuous identity discovery isn't optional anymore. You need an automated view of service accounts and machine roles, mapped to their owning application and team, that updates as deployments happen, not as tickets get filed.
Myth 5: "The AI just writes code, humans still make the access decisions"
Reality: The AI makes access decisions by default. The human just accepts them.
AI code generation tools optimize for working code, not least-privilege code. When generating Terraform configurations or cloud SDK calls, they default to permission sets broad enough to cover common use cases because that produces fewer errors during testing. Neither the developer nor the AI is optimizing for minimum access surface.
The result is infrastructure that works correctly and is chronically over-privileged. Because the developer didn't write the IAM policy themselves, they often can't assess whether it's scoped appropriately. The access decision happened. It just happened implicitly, embedded in generated output that looked reasonable enough to ship.
What to do instead
Require explicit review of AI-generated IAM policies. Any code that configures cloud permissions should go through a review step focused specifically on access scope, separate from functional logic review. Automated policy analysis tools can flag overly broad permissions before deployment.
Enforce least privilege at the platform layer. Controls that depend on developers fully understanding generated implementation don't hold up. Use 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 shouldn't persist long-lived credentials because it's operationally convenient. Issue short-lived, scoped credentials per session.
Inventory non-human identities continuously. Identity discovery needs to keep pace with rapid infrastructure generation. Maintain a real-time view of service accounts, API keys, and machine roles mapped to owning teams.
Apply lifecycle policies explicitly to vibe-coded workloads. When a project ends, decommission its associated identities as part of the close-out process. This requires someone accountable for those identities, which requires they were tracked from the start.
Design for blast radius containment. In environments where AI-assisted development increases the volume of generated infrastructure, some overly broad permission will eventually reach production. Your security model can't depend on perfect review. It needs to assume mistakes will occur and ensure no single credential becomes a terminal failure event when they do.
The IAM policy an AI generates is just as binding as one a human wrote. In practice, it's often broader, less documented, and attached to identities no one is actively managing. The code ships with access decisions already made. Your job is to govern them before they become permanent.
