Vibe coding security exposes the gap between working and safe code

At a glance

What this is: This is an Equixly analysis of vibe coding security showing that AI-generated code can look correct while still failing basic security checks, especially at the API layer and in secret handling.

Why it matters: It matters because teams that trust functional testing alone may ship exploitable code faster than they can review it, forcing IAM, API, and application security controls to validate what the runtime actually does.

By the numbers:

• 61% of AI-generated code passed functional tests in a Carnegie Mellon University benchmark, but only 10.5% passed security tests.
• 75% of developers use some form of vibe coding, and 90% find it useful.

Context

Vibe coding is the practice of asking an AI coding assistant to write and iterate code from natural-language prompts, but the real security gap appears after the code looks functional. The core problem is that application logic, authentication, and access control can all be syntactically correct while still being insecure at runtime, which makes this an application security and identity governance issue as much as a developer productivity one.

For IAM and NHI practitioners, the important intersection is not the code-generation workflow itself but the credentials, permissions, and API boundaries that the generated application depends on. When AI-assisted development introduces hardcoded secrets, weak authentication, or over-broad access paths, the security model shifts from who wrote the code to what the running system can actually prove and enforce.

Key questions

Q: What is the biggest security failure mode in vibe-coded applications?

A: The biggest failure mode is not that the code fails to run. It is that the code runs correctly while still containing weak authentication, broken authorization, or hardcoded secrets that create immediate abuse paths. Functional success does not prove security, so teams must validate the live application against hostile inputs and credential misuse.

Q: Why do AI-generated apps often fail enterprise security reviews?

A: They usually start from functional code and basic authentication, but enterprise reviews look for control boundaries, evidence, and lifecycle management. Missing SSO, weak authorization, poor logs, and unclear tenant separation are common reasons a working prototype gets rejected. Security teams are evaluating governability, not just whether the app runs.

Q: What do security teams get wrong about AI-generated code risk?

A: They often focus on catching insecure output after code is written, which is too late for AI-native workflows. The more important control point is the moment the agent is allowed to initiate the action. If that step is not governed, testing becomes a detection layer rather than a prevention layer.

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 functional correctness and security diverge in vibe-coded apps

AI coding agents are optimised to produce code that compiles, executes, and satisfies the visible prompt, not to reason about adversarial abuse paths. That creates a structural gap: a feature can pass functional tests while still containing broken authentication, insecure defaults, or access control mistakes that only emerge when the application is exercised like an attacker would. In practice, this means source review alone is not enough because many flaws are context-dependent and only become visible in the running system.

Practical implication: Validate vibe-coded features with runtime security tests, not just code review or unit tests.

Why hardcoded secrets and broken access controls keep appearing

The article highlights a recurring pattern in AI-generated code: model output often includes API keys, database passwords, JWT secrets, and permissive access logic because those choices resolve errors quickly. In identity terms, that turns the generated application into a credential-risk amplifier, since leaked or weakly generated secrets can be reused for authentication bypass, token forgery, or account takeover. The problem is not just leakage, but the combination of exposed credentials and weak enforcement around who or what can use them.

Practical implication: Treat secret scanning and credential lifecycle controls as mandatory gates for AI-generated code.

Why the API layer becomes the real attack surface

Vibe-coded applications often fail at the boundary where generated logic meets real users, tokens, and requests. That boundary is usually the API layer, where broken object-level authorization, missing authentication checks, and incomplete input validation turn design flaws into exploitable paths. Because these weaknesses can be hidden behind code that appears reasonable, adversarial testing is more effective than static inspection alone for finding the conditions that let an attacker read, change, or delete data through normal endpoints.

Practical implication: Test APIs with attack-style scenarios before deployment, especially for authorization and data access paths.

Threat narrative

Attacker objective: The attacker aims to turn insecure AI-generated code into direct application compromise by abusing weak authentication, exposed secrets, and API-layer access control gaps.

1. Entry occurs when an AI coding agent generates or modifies application code from prompts, imported context, or external files that the developer treats as trusted inputs.
2. Credential harvesting or abuse follows when the generated application contains hardcoded secrets, predictable JWT values, or weak authentication logic that can be used to impersonate users or forge access.
3. Escalation and lateral movement occur when broken access control or over-broad API permissions let an attacker move from a single request to broader data access or administrative actions.
4. Impact is the exposure, tampering, or deletion of application data, including dashboard compromise, account takeover, or unrestricted access to protected functions.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.

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

Vibe coding creates an assurance gap, not just a development shortcut. The central issue is that generated code can satisfy functional intent while remaining insecure under attack conditions. That means the governance question is no longer whether the feature works, but whether the runtime proves access, identity, and data-handling decisions correctly.

Hardcoded secrets are the clearest NHI warning sign in AI-generated software. API keys, database passwords, and JWT secrets are not just implementation mistakes. They are machine credentials that can be replayed, forged, or leaked into downstream systems, which makes OWASP-NHI and credential lifecycle controls directly relevant to vibe-coded applications.

API-layer assurance is now the real control boundary: once generated code reaches production, broken object-level authorization, missing authentication checks, and permissive endpoints become the practical failure modes. That shifts defensive effort toward adversarial testing, identity-aware validation, and runtime policy enforcement rather than confidence in source readability.

Prompting for secure code is not a governance strategy. The article is right to frame security as a first-class objective that has to be tested independently from functional correctness. For practitioners, this means security acceptance criteria and evidence of runtime enforcement should be required before release, not after defects are discovered.

AI-assisted development compresses the time between mistake and exposure. When code can be produced, revised, and shipped quickly, controls that rely on human intuition catching problems later lose effectiveness. The practical conclusion is that security review must move upstream into generation-time requirements and downstream into adversarial verification.

What this signals

Vibe coding pushes security governance upstream and into the release pipeline. The practical shift is from trusting developer intent to proving that generated code enforces identity, authorization, and data-handling decisions at runtime. Teams that still rely on human review alone will miss the failure modes that only appear once the feature is live.

Hardcoded secrets in generated code are an NHI problem, not just a code-quality smell. API keys, tokens, and JWT secrets behave like machine credentials the moment they leave the editor, which means the controls around discovery, storage, and revocation need to be as strict as any other credential workflow.

Runtime testing is becoming the decisive control for AI-assisted development. Security teams should expect static analysis to miss context-dependent flaws and should invest in adversarial testing that exercises the live endpoint behaviour, especially for authentication and object-level authorization.

For practitioners

• Define security acceptance criteria before generation Write explicit controls for authentication, access checks, secret handling, and data exposure before prompting the coding agent. Tie those controls to the feature's threat model so the AI is constrained by security requirements from the start.
• Scan generated code for hardcoded secrets Make secret scanning mandatory in CI/CD and block releases that contain API keys, database passwords, JWT secrets, or other reusable credentials. Treat any discovered secret as a credential incident, not a code-quality issue.
• Test the running application with adversarial cases Use dynamic testing and continuous penetration testing to probe authentication logic, broken object-level authorization, unexpected input handling, and error-message leakage in the live application.
• Restrict agent permissions to non-production environments Limit what AI coding agents can access and execute, keep them out of production systems, and require human confirmation for auto-execution that could change privileged state.
• Treat APIs as the primary security boundary Validate login routes, admin functions, and data retrieval endpoints with the same rigor you would apply to an externally exposed service. Prioritise authorization checks and object-level access rules over source-level assumptions.

Key takeaways

• Vibe coding turns software delivery into an assurance problem because code can be functional and still unsafe at the same time.
• The most repeatable weaknesses are hardcoded secrets, broken authorization, and API-layer flaws that only show up under adversarial testing.
• Teams need security criteria, runtime validation, and tighter agent permissions before AI-generated code is allowed to ship.

Key terms

• Vibe Coding: A software development approach where natural-language prompts drive much of the implementation and AI produces the code. In practice, the term covers a wide range of control levels, from no-review prototyping to structured engineering with tests, review, and architecture held by humans.
• Hardcoded Secret: A hardcoded secret is a credential written directly into source code, scripts, configuration files, or build assets. It is convenient for development but dangerous in production because it can be copied, indexed, propagated, and reused outside the intended control boundary.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Runtime security testing: Runtime security testing evaluates an application while it is executing, not just by reading code or configuration. This matters for APIs because authentication, service calls, and data handling often behave differently once the full dependency chain is active.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for teams that need to control credential risk across modern development pipelines. It helps security and engineering teams align identity governance with practical control decisions.