Vibe Coding Security: Governance for AI-Written Code
Vibe coding security is the governance and runtime-control discipline that manages AI-generated code before and after it reaches production. It addresses risks from unreviewed merges, over-permissioned coding agents, unvetted dependencies, and unclear code provenance through mechanisms such as agent identity, least-privilege access, policy enforcement, and audit logging.
What Vibe Coding Means for Security Teams
The term "vibe coding" was popularized by AI researcher Andrej Karpathy in early 2025 to describe a workflow in which developers prompt an AI model to generate code and accept the output with little or no review of the underlying logic. From a security standpoint, vibe coding is distinct from conventional AI-assisted development, where tools suggest code line by line and a developer evaluates each suggestion before accepting it.
In vibe coding workflows, larger blocks of AI-generated logic move directly into a merge with limited scrutiny of implementation details, effectively collapsing the design, review, and testing gates that traditional development processes rely on. This is not a coding style question. It is a governance and control-flow problem: who or what authored a given code path, what permissions were used to generate or merge it, and whether it was subject to any independent verification before reaching production.
Where AI-Generated Code Introduces Distinct Risk
AI coding assistants can reproduce insecure patterns, such as missing input validation, because those patterns exist in the training data the models learned from, not because of a deliberate design decision. An academic study by Perry et al. found that developers using AI code-generation assistants produced code with more security vulnerabilities while reporting higher confidence in its security than developers who did not use such tools. This gap between confidence and actual security posture is a central concern in vibe coding workflows, where the volume of unreviewed code increases along with reliance on the tool's apparent competence.
Unreviewed Merges
AI-generated code blocks merged with minimal manual review of underlying logic.
Over-Permissioned Agents
Coding agents operating with broader repository or system access than a task requires.
Unvetted Dependencies
AI-suggested packages that are unverified or do not yet exist.
Unclear Provenance
Version control metadata that does not distinguish human, AI-suggested, and AI-autonomous commits.
A second risk vector is dependency integrity. AI-generated code can reference third-party packages that do not exist or have not been vetted, creating exposure to dependency confusion or typosquatting if a malicious actor later publishes a package under that name. OWASP's Top 10 for LLM Applications categorizes this as a supply chain vulnerability distinct from traditional dependency risk, alongside "Excessive Agency," which describes AI tools or agents operating with broader permissions than their task requires.
A third gap is provenance. Standard version control metadata frequently does not distinguish human-authored commits from AI-suggested or AI-autonomous ones, which complicates both code review prioritization and incident response when a vulnerability is traced back to its origin.
Governance Mechanisms for AI-Written Code
Enterprises are addressing these gaps by extending existing access control and pipeline governance models to AI coding agents, rather than treating AI-generated code as exempt from standard controls.
-
Agent identity
Treat coding agents as distinct principals with their own credentials, separate from human developer accounts, so actions can be attributed and scoped independently.
-
Least-privilege access
Limit repository, environment, and system permissions to only what a given task requires, reducing the blast radius of excessive agency.
-
Policy enforcement in the pipeline
Route AI-generated changes through the same CI/CD gates used for human commits, including SAST, SCA, secret scanning, and mandatory review on high-risk paths.
-
Audit logging and provenance
Capture which agent, model version, prompt context, and human reviewer were involved in each change so incident response and compliance reviews have a clear trail.
Governance as an Ongoing Process, Not a Configuration Step
NIST's AI Risk Management Framework (AI RMF 1.0), published in January 2023, defines Govern, Map, Measure, and Manage functions that apply to AI coding tools as much as to other AI systems, and NIST's SP 800-218A, released in 2024, extends the Secure Software Development Framework specifically to generative AI and AI-assisted code. These frameworks, along with OWASP's LLM guidance and CISA's Secure by Design principles, provide reference structures rather than turnkey controls; each requires organization-specific mapping to development tooling, repository structure, and existing CI/CD pipelines.
CISA's Secure by Design initiative calls on software producers to reduce reliance on end users to catch security defects after release, a principle that applies equally to code authored by AI tools, since downstream vulnerabilities carry the same production risk regardless of who or what wrote the code. Google's Secure AI Framework similarly identifies strong access controls for AI agents and pipelines as a baseline expectation.
Because permission grants and tool configurations tend to expand over time, governance should include periodic review of AI coding tool access and audit logs, not only an initial policy rollout. Without this review cycle, permission creep in coding agents can reintroduce the excessive-agency risk that initial controls were designed to prevent.
Operational Controls Before and After Merge
Translating governance mechanisms into practice requires concrete controls embedded in existing development tooling rather than a separate approval process.
| Stage | Control focus | Practical outcome |
|---|---|---|
| Before generation | Agent identity and scoped credentials | Agents cannot inherit broad human developer permissions by default |
| During authoring | Dependency verification and secret scanning | Non-existent or unvetted packages and leaked secrets are caught early |
| Before merge | CI/CD policy gates and mandatory human review | High-risk paths require independent approval regardless of AI confidence |
| After merge | Provenance metadata and continuous audit review | Incidents can be traced to agent, model, prompt, and reviewer |
Questions to Ask Before Extending AI Coding Tool Access
Use the following checklist when evaluating or expanding AI coding tool access in an enterprise environment.
- How does the AI coding tool authenticate and scope its permissions relative to human developer accounts, and can access be restricted to least privilege?
- What audit trail links a specific code change to its originating prompt, model version, and approving reviewer?
- Does the tool integrate with existing CI/CD policy gates, including SAST, SCA, and secret scanning, to block risky AI-generated code before merge?
- Can administrators enforce mandatory human review for changes to defined high-risk code paths regardless of AI-assigned confidence?
- How does the tool handle dependency verification to avoid suggesting non-existent or unverified packages?
Bring Runtime Governance to AI-Written Code
Trussed AI applies agent identity, least-privilege permissions, and audit logging to AI coding agents and other enterprise AI systems, extending governance beyond initial configuration into ongoing runtime enforcement.
Explore Runtime Governance