An application built through low-code or AI-assisted tools by a non-specialist or semi-technical user. The security risk comes from speed and accessibility outpacing review, so secret handling, authorization and deployment guardrails can be weak or missing.
Expanded Definition
A vibe-coded application is software assembled quickly through low-code platforms, AI-assisted builders, or prompt-driven workflows by a non-specialist or semi-technical creator. The term is descriptive rather than formal, and usage in the industry is still evolving, so definitions vary across vendors and practitioners. In security discussions, the key issue is not the interface used to build the app, but the governance gap that can appear when functionality is produced faster than it is reviewed. That gap often shows up in weak authentication, over-broad API access, exposed secrets, insecure defaults, and deployment paths that bypass normal change control.
Because the application may look polished while hiding fragile controls, it is easy to confuse speed of delivery with maturity of design. NHI Management Group treats the term as a risk signal: if an application can be created without software engineering discipline, then it can also be launched without the guardrails normally expected in secure development. That is why the concept is closely related to secure configuration, identity-aware access, and secrets management, even when it is not itself an identity term. For broader governance context, the NIST Cybersecurity Framework 2.0 is useful for mapping the resulting control gaps. The most common misapplication is treating a vibe-coded application as low risk simply because it is small or internal, which occurs when teams assume limited scope means limited exposure.
Examples and Use Cases
Implementing vibe-coded applications at speed often introduces review debt, requiring organisations to weigh rapid prototyping against the cost of retrofitting security after deployment.
- An internal workflow app is built in a low-code platform to automate approvals, but it stores API keys in plain text and exposes too many actions to general users.
- A business team uses an AI assistant to generate a customer-facing portal, then deploys it without code review, resulting in missing authorization checks and weak session handling.
- A semi-technical developer connects SaaS tools together with scripts and webhooks, but no one documents ownership, secret rotation, or incident response responsibilities.
- A small data intake tool is released directly to production after a prompt-based build session, yet it lacks logging, change approval, and least-privilege service access.
- A prototype becomes operational because it solves an urgent business need, but the absence of review makes it difficult to determine whether it aligns with basic cybersecurity governance expectations.
These examples show why the term is increasingly used in security reviews of shadow IT and citizen development. The application may function well enough for business use, but its build path can leave no clear record of who approved access, who owns the secrets, or whether the deployment was tested for abuse cases.
Why It Matters for Security Teams
Security teams care about vibe-coded applications because they compress multiple risks into one artifact: weak identity controls, unclear ownership, poor asset inventory, and uncontrolled data exposure. The problem is not that non-specialists build software, but that governance often fails to keep pace with how fast the software becomes real. When a tool handles customer data, connects to privileged APIs, or automates an operational process, it can create an attack path that is invisible until something breaks.
This term also matters because it sits near the boundary of NHI governance. Many vibe-coded applications rely on service accounts, tokens, and API keys that function as Non-Human Identities, yet those credentials may be created informally, stored insecurely, or never rotated. In practice, that can turn a convenience app into a persistent access channel. A useful governance lens comes from the NIST Cybersecurity Framework 2.0, which helps teams connect application risk to asset management, access control, and recovery planning. Organisations typically encounter the real severity only after a token leak, access misuse, or failed audit, at which point the vibe-coded application becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC, PR.AC, PR.DS, DE.CM | CSF 2.0 frames governance, access, data protection and monitoring gaps exposed by this term. |
| OWASP Non-Human Identity Top 10 | Vibe-coded apps often create unmanaged service credentials and tokens, an NHI risk pattern. | |
| NIST AI RMF | GOV, MAP | AI-assisted building changes accountability and context mapping for software produced this way. |
| NIST SP 800-63 | AAL2 | User-facing vibe-coded apps often need identity assurance controls when they process sensitive actions. |
| NIST Zero Trust (SP 800-207) | SC-7, AC-4 | Zero trust limits the blast radius of weakly governed apps and their service connections. |
Define human oversight, purpose limits and accountability before allowing AI-assisted app generation.
