The Cloud Security Alliance published a research note in June 2026 documenting what it called the vibe coding governance gap. The finding was not that AI coding tools are dangerous. The finding was that enterprise organizations are deploying them at scale without any written policy governing how they are used in shared codebases. The consequences are measurable: independent security research found that 65% of vibe-coded production applications contain security vulnerabilities, and zero out of 5,600 surveyed apps had basic protections like CSRF controls or properly scoped access policies.
The tools are not the problem. The absence of a policy is.
stateDiagram-v2 direction TB state "Ad Hoc AI Coding (no policy)" as Adhoc state "Policy Drafted and Communicated" as Policy state "Tool Evaluation Against Policy" as Eval state "Controlled Rollout with Review Gates" as Rollout state "Production Governed" as Governed state "Security Incident — Emergency Response" as Incident [*] --> Adhoc Adhoc --> Policy: governance project initiated Adhoc --> Incident: vulnerability reaches production Policy --> Eval Eval --> Rollout Rollout --> Governed Incident --> Policy: reactive remediation Governed --> [*]: ongoing operating model
What a Policy Gap Looks Like in Practice
Most enterprise AI coding adoption follows a pattern: a few engineers start using AI coding assistants individually. The results are positive. Word spreads. More engineers adopt. By the time the topic reaches a formal discussion, a meaningful percentage of the production codebase has already been touched by AI-generated code — written under no shared guidelines, reviewed with no shared standard, and deployed through the same gates as any other code.
At that point, the question is not whether to have a policy. The question is whether to have a policy before or after the security incident.
The organizations that end up in the reactive position are not making a deliberate choice to skip the policy. They are moving fast and assuming that existing code review processes will catch the risks. That assumption is generally wrong. Standard code review is calibrated to catch logic errors and style inconsistencies in code the reviewer understands. It is not calibrated to catch the category of risks that appear specifically in AI-generated code: implicit assumptions baked into generated auth patterns, secrets embedded in configuration files, API integrations that expose more than intended because the generation was not prompted with the specific data boundary in mind.
What the Policy Needs to Cover
An enterprise AI coding policy does not need to be long. It needs to cover six things:
Approved tools and their scope. Which AI coding tools are sanctioned for use, in which types of codebases. A tool approved for internal tooling may not be approved for a codebase that touches regulated data. This distinction needs to be explicit, not inferred.
Code areas requiring manual review. Authentication and authorization logic, secrets handling, external API integrations, data encryption, and any code path that touches regulated data should require a manual review gate before production deployment. AI-generated code in these areas should not merge on a standard review cycle — it should require explicit sign-off from someone with security expertise.
Secrets management requirements. AI models trained to generate functional code will generate functional code that embeds credentials when that is the most direct path to functionality. The policy needs to specify that no AI-generated code containing credentials, API keys, or tokens in any form — hardcoded, in configuration files, in environment variable templates — passes review.
Data handling during generation. Which data the AI coding tool is permitted to see during generation, and which is off-limits. Prompting with production data containing PII or regulated records raises compliance and privacy questions that need to be resolved before engineers make ad hoc decisions about what to paste into a prompt.
Output review standard. What “reviewed” means for AI-generated code. The standard should be that the reviewer can explain what the code does and why it does it — not just that it works when tested. If the reviewer cannot explain it, they have not reviewed it.
Deployment gates. Whether AI-generated code in high-risk areas requires additional automated security scanning before deployment, beyond what is applied to all code.
The Architectural Discipline That Governance Requires
At LERETA, where I led over 30 developers through a multi-year, $20M+ modernization of two flagship products, the discipline that made the project succeed was not the specific technology choices — it was the consistent architectural oversight applied to every decision that touched the core systems. Every design that went into the flagship products went through an architecture review process. Not because the engineers were not capable of making good decisions independently, but because the compounding effects of individual decisions at scale require a coordinating layer to stay coherent.
Enterprise AI coding policy is that coordinating layer for AI-assisted development. Without it, the individual decisions each engineer makes about when to use AI coding assistance, which tool to use, what code to accept without review, and what to do when a generated pattern looks unfamiliar accumulate into an architecture that nobody explicitly designed. With it, the AI coding capability gets built into the engineering practice in a way that is sustainable and reviewable.
Starting the Policy Conversation
The minimum viable version of an enterprise AI coding policy is a one-page document that answers: which tools are approved, which code areas require manual security review, and what the secrets management rule is. That document — even in draft form, shared with the engineering team for comment — surfaces the gaps in current practice and creates a starting point for iteration.
Oversight of technology — vendors, developers, AI integrators — that rolls up to one accountable technology leader with clear authority over these decisions is the infrastructure that makes the policy enforceable rather than aspirational. Without that accountability layer, a written policy stays aspirational.
The 65% vulnerability rate in vibe-coded production applications is not a technology failure. It is a governance gap. The technology is producing what it is asked to produce. The question is whether the organization has been deliberate about what it is asking for.
