Vibe coding security exposes the gap between working and safe code

At a glance

What this is: This is an analysis of vibe coding security and the central finding is that code which works can still be dangerously insecure.

Why it matters: It matters because IAM, application security, and NHI teams must assume AI-generated code can introduce hardcoded secrets, broken access control, and API exposure that conventional review workflows miss.

By the numbers:

• In one Carnegie Mellon benchmark, 61% of AI-generated code passed functional tests but only 10.5% passed security tests.
• Over 80% of functionally correct AI solutions contained security vulnerabilities in one study of 200 real feature requests.
• An AI coding scanner found 970 security issues across 7 vibe-coded MVPs, including 801 high-severity weaknesses.
• At least 5.2% of packages suggested by commercial models were fabricated in one study of 16 popular models.

👉 Read Equixly's analysis of vibe coding security gaps and AI-generated code risk

Context

Vibe coding is the practice of using natural language to drive an AI coding assistant that generates, iterates, and refines code with minimal manual implementation. The security gap appears when teams equate a successful build with a secure one, because AI systems are optimised to satisfy the request, not to prove the absence of exploitable flaws. For IAM and NHI practitioners, that matters because generated applications often expose APIs, secrets, authentication flows, and service-to-service trust boundaries before those controls are fully reviewed.

The article is fundamentally about application security governance in AI-assisted development, but it also touches identity security in practical ways. Hardcoded secrets, weak authentication, broken object-level authorization, and over-permissive agent access all create identity and privilege problems that look like ordinary coding defects until they are exploited. This is now a familiar pattern in cloud-native and agentic workflows: the code may be new, but the control failures are not.

Key questions

Q: How should teams secure AI-generated applications before they reach production?

A: Treat security as a precondition of generation, not a review step at the end. Start with approved templates, shared authentication libraries, runtime secret retrieval, CI gates, and default-deny network policy. The goal is to make the safe path the easiest path, so generated code inherits controls instead of inventing them under pressure.

Q: Why do vibe-coded applications create NHI and secrets risk?

A: Because AI-generated code often embeds machine credentials directly into the application, such as API keys, JWT secrets, and database passwords. Those values behave like standing non-human identities with unclear ownership and lifecycle, which increases the chance of misuse, reuse, and exposure across environments.

Q: What breaks when AI tools are allowed broad write access to internal systems?

A: Broad write access turns an AI tool from a helper into an unreviewed operator. It can modify code, create tickets, change records, or move data in ways that expand the attack surface and complicate incident response. The failure is not only overprivilege, but also the loss of clear accountability for actions taken through the AI intermediary.

Q: Who is accountable when an AI coding tool introduces insecure code into production?

A: Accountability stays with the organisation that allowed the tool to operate without enforced guardrails. The model is not the accountable party. Security, engineering, and platform owners share responsibility for defining policy, enforcing it at runtime, and logging the decision trail that proves controls were applied.

Technical breakdown

Why secure prompts do not produce secure code

Prompting an AI assistant to "write secure code" sounds sensible, but the article shows why that approach fails. Coding agents optimise for local task completion, which means they will often satisfy a visible error condition even if the fix destroys the security model. In practice, this can turn an access-control failure into a dangerous overcorrection, such as making data broadly readable because the agent only sees the functional error. Security has to be evaluated as an outcome of the running application, not as a property inferred from the prompt.

Practical implication: require security tests and threat modelling for every AI-generated feature, not just prompt-level guidance.

How hardcoded secrets and fabricated packages become NHI risk

AI-generated code repeatedly introduces secrets in places where they should never exist, including API keys, database passwords, and JWT signing secrets. That is an NHI problem because these values are machine credentials, not ordinary source-code artefacts, and once they are embedded they become standing identities with attack value. The article also highlights package hallucination, where models invent names that attackers can pre-register and weaponise. The result is a supply-chain and secrets-management issue at the same time.

Practical implication: scan generated code for secrets and validate dependencies before any build reaches shared environments.

Why the API layer is where vibe-coded apps usually fail

Most of the damage becomes visible at the API layer, where authentication, access control, rate limiting, and input validation must all work together. Vibe-coded applications often look fine in source review but fail under adversarial requests because object-level authorisation, session handling, and error handling were never fully defined. This is why dynamic testing matters more than static inspection alone. A secure-looking endpoint is not a secure endpoint if it leaks data, trusts unvalidated input, or exposes administrative functions through predictable routes.

Practical implication: test the running API with adversarial inputs and broken-authorisation probes before release.

Threat narrative

Attacker objective: The attacker wants to turn AI-assisted development shortcuts into direct access to credentials, data, or privileged application functions.

1. Entry occurs when attackers target the toolchain around vibe coding, including injected instructions, fabricated dependencies, or unsafe configuration that the AI agent treats as trusted context.
2. Escalation follows when the generated application inherits hardcoded secrets, missing authentication, or over-broad API permissions that let an attacker move from code execution to account or data access.
3. Impact is the exposure of tokens, private messages, backend credentials, or administrative functions, which turns rapid development into rapid compromise.

NHI Mgmt Group analysis

Vibe coding security is really application security under compression. The article shows that AI does not invent new security principles, it accelerates the consequences of skipping them. Functional correctness and security assurance are now decoupled, which means teams need explicit controls for review, testing, and release gating. The practitioner conclusion is simple: if the code ships faster than it is tested, security debt accumulates immediately.

Hardcoded secrets are the clearest NHI failure mode in AI-generated code. When an AI assistant embeds API keys, JWT secrets, or service credentials, it creates unmanaged non-human identities inside the application itself. That is a governance failure, not just a coding defect, because the secret now behaves like a standing credential with unclear ownership and lifecycle. The practitioner conclusion is that secrets discovery and rotation must be built into CI/CD, not treated as after-the-fact cleanup.

API trust boundaries are the named concept teams should watch: predictable endpoints with unverified authorisation. Vibe-coded apps often expose login, data, and admin paths before the underlying access rules are hardened, which makes broken object-level authorisation and missing session controls especially common. This aligns with NIST CSF and OWASP-style application security expectations, but the operational lesson is sharper: if the API layer is not adversarially tested, the application has not been validated. The practitioner conclusion is to treat the API as the primary security boundary, not the source code.

Agent privilege now needs the same discipline as human privilege. The article’s least-privilege advice for AI agents is a reminder that delegated tooling can overreach just as easily as a human operator can. In environments where agents can run code, call tools, or access repositories, the relevant control question becomes who or what may act, not just what the application does. The practitioner conclusion is to scope agent access to development and test assets only, then verify it continuously.

Model-layer improvements do not remove governance responsibility. Even if secure-code generation improves, the organisation that ships the software still owns the risk. That means AI governance, application security testing, and release accountability must remain separate controls rather than being collapsed into prompt engineering. The practitioner conclusion is to measure secure output at runtime and hold delivery teams accountable for the deployed state, not the intent of the prompt.

What this signals

Hardcoded secrets are now a governance signal, not just a code-quality issue. As AI-assisted development expands, teams need to assume that machine credentials can appear anywhere from source files to generated configuration. The practical response is to make secret detection, rotation, and ownership checks part of the delivery system, not an afterthought.

The control model needs to shift from reviewing code artefacts to validating runtime behaviour, because many AI-generated flaws only appear when an attacker exercises the API. That creates a direct link to application security testing, least privilege, and identity-aware controls for both service accounts and AI agents.

API trust boundaries are becoming the place where identity governance and software governance meet. In practice, this means the team that owns application delivery also has to own the access paths exposed by generated code, including authentication flows, service credentials, and delegated agent permissions.

For practitioners

• Enforce security acceptance criteria before generation Write threat-modelled security requirements alongside functional requirements before an AI coding assistant generates a feature, and block release until those requirements are tested in the running application.
• Automate secrets detection in every pipeline Scan commits, pull requests, and build artefacts for hardcoded API keys, JWT secrets, database passwords, and certificates before code reaches shared environments.
• Adversarially test the API layer Probe authentication, object-level authorisation, error handling, and rate limiting with malicious inputs and broken-session scenarios, because those are the failure points AI-generated code most often hides.
• Restrict AI agent privileges to non-production scopes Limit agent access to development and test systems, separate approval for auto-execution, and review any tool or repository access that could expose production secrets.

Key takeaways

• Vibe coding shortens delivery time, but it also shortens the path from a bad prompt to a real security exposure.
• The strongest evidence in the article is the functional-versus-security gap, where code can work correctly and still fail basic security validation.
• Teams should treat generated code as a runtime security problem, with adversarial testing, secrets governance, and agent least privilege built into release control.

Key terms

• Vibe Coding: A software development workflow where natural language prompts drive an AI assistant to generate, edit, and iterate code with limited manual implementation. The main governance risk is that speed increases while security validation is often postponed, incomplete, or assumed rather than tested.
• 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.
• Agent Least Privilege: A governance pattern that limits what an AI agent can read, modify, execute, or deploy based on the minimum access needed for the task. It is essential when agents can run commands, reach repositories, or interact with secrets, because delegated automation can exceed intended scope very quickly.

What's in the full article

Equixly's full blog post covers the operational detail this post intentionally leaves for the source:

• Benchmark examples showing how specific AI coding models fail on secure implementation choices across different languages and tasks
• The exact attack patterns seen in vibe-coded apps, including indirect prompt injection, fabricated packages, and lies-in-the-loop approvals
• Practical testing guidance for continuous penetration testing against APIs and business logic flaws
• Specific examples of security checks that dynamic testing surfaces when static analysis does not

👉 Equixly's full blog post covers the benchmark data, attack patterns, and API testing recommendations in more detail

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is suitable for practitioners who need to connect identity control to broader software delivery risk.