Shadow AI Development: The Codebase Risk No One Is Measuring
About 63% of active vibe coders on r/vibecoding — a community of over 153,000 people — aren't developers (February 2026 analysis). They're product managers, founders, ops leads, and marketing teams. And they're shipping AI-generated code to production.
Your SAST scanner isn't watching them. Your PR review process probably doesn't cover them. Your AppSec program was designed around a world where the only people committing code had committed access — and knew what a trust boundary was.
That world is gone.
Shadow IT Grew Up. It Now Deploys on Fridays.
Shadow IT used to be a Dropbox folder. Or a Slack workspace the IT team didn't approve. Annoying, but containable — the blast radius was usually a data governance headache, not a security incident.
Shadow AI development is different. The output isn't a file on someone's personal cloud. It's a FastAPI endpoint handling user data, connected to your production database, written in forty-five minutes by someone who has never heard of CWE-89.
Brian Armstrong said in 2026 that approximately 40% of Coinbase's daily code is AI-generated — and that non-technical teams are shipping to production. If that's the trajectory at Coinbase, a company with a mature security function, think about what it looks like at the 200-person SaaS startup whose CISO doubles as the head of IT.
The volume of code is exploding. The number of security-trained people writing it is not. Those two lines crossed somewhere around mid-2025 — and the gap is widening every quarter.
The Measurement Gap Is the Real Problem
AppSec programs are built to measure developer behavior. Branch protection rules. Required code review. SAST scans on PR. Mandatory AppSec review for high-risk changes. These controls assume a single on-ramp into production: the pull request, reviewed by an engineer.
Non-technical teams often skip that on-ramp entirely. A PM builds an internal tool on Lovable, connects it to the company Airtable, and ships it to the ops team by Thursday. No PR. No code review. No SAST run. Nothing in your AppSec metrics catches it because nothing in your AppSec program was watching for it.
You can't measure what you haven't instrumented. And most enterprises haven't instrumented this.
Why the Toolchain Built for Developers Doesn't Transfer
The standard AppSec response to "more code is being written" is "run more SAST." Run it — it catches real things on a schedule and belongs in your toolchain. But that logic breaks when the people writing the code aren't using the tools your SAST scanner hooks into.
SAST runs on committed code. Non-technical vibe-coding workflows often don't produce traditional commits — they produce deployed artifacts. The PR review bot that catches SQL injection in a developer's code never sees the PM's endpoint because the PM didn't open a PR.
Even when non-technical teams do use GitHub, the branch protection rules and required-review gates that your engineering org configured often don't apply to new repos spun up for internal tools. Those defaults aren't set. No one thought to set them because no one planned for the PM to create the repo.
The threat model your AppSec team built was accurate for 2022. In 2022, developers wrote code. Threats entered through developer commits. Controls sat at the commit and PR layers. That model worked.
It doesn't describe 2026.
Security Has to Move Into the Prompt
The only intervention point that works across both technical and non-technical code authors is the prompt itself.
A developer's prompt and a PM's prompt both go through the same model. The model's output is shaped by what it receives as context. If that context includes threat-informed guardrails — "parameterize all SQL queries," "require authenticated user before fetching records," "validate webhook signatures before processing" — the model generates secure code on the first prompt, regardless of whether the person prompting knows what SQL injection is.
This is the upstream shift. Not SAST on the PR. Not a security review after the code is deployed. Guardrails at the point of generation, derived from a threat model of the actual repo — its entry points, trust boundaries, where user input lands, where secrets live.
The approach: threat-model the repo first (MODEL), generate guardrails mapped to those specific threats and to the OWASP Top 10 (2025) and the Cisco AI Security Taxonomy (GUARD), then serve those guardrails into the IDE via MCP server — inside Claude Code, Cursor, Codex, and Copilot (REVIEW). The same threat-informed context that shapes a senior developer's output shapes the PM's output. Because they're using the same IDE. With the same guardrails running in the background.
The threat-model travels with the tool. The person using the tool doesn't need to know what CWE-89 is.
Start Measuring What You've Been Missing
The first step isn't technology. It's instrumentation.
Ask your AppSec team: how many tools and internal applications are running in your environment that were built by non-engineering teams in the last six months? If they can't answer that, the measurement gap is already real — and growing.
The second step is moving security upstream. Controls that live at the PR review layer only catch what reaches the PR. Guardrails that live at the prompt layer catch everything — from the senior engineer's microservice to the PM's internal dashboard.
Shadow AI development isn't a trend to get ahead of. It's the current state of most enterprise engineering organizations, whether they've acknowledged it yet or not. The question for CISOs isn't whether non-technical teams are shipping AI-generated code. They are. The question is whether that code is being generated with any security context — or entirely in the dark.
Your AppSec program needs to be in the room where the code gets written. That room is now an IDE. And the code generation starts with the prompt.
VibeReview — from the makers of SecurityReview.ai — template-models your repo, generates threat-informed guardrails, and serves them into Claude Code, Cursor, Codex, and Copilot via MCP. Hook up GitHub or GitLab in 30 seconds. 14-day free trial, no card required.