Shadow IT from Vibe Coding: The New Governance Risk

Vibe coding has shifted the playing field. Whoever used to grab a SaaS license now builds their own app with Cursor or Claude in a single afternoon and deploys it to Vercel. IT finds out about it when the first data leak surfaces. This is exactly where a new form of shadow IT through vibe coding emerges, and it behaves differently from anything platform teams have dealt with so far.

What vibe coding really means

The term comes from Andrej Karpathy. His point: with today's coding assistants you describe software at a higher level and mostly check the behavior at the end, not every line of code. You develop in the flow, in the vibe, hence the name.

In practice that means tools like Cursor, Claude Code, v0, Lovable, Bolt or Replit Agents take a prompt and deliver a runnable application, often with frontend, backend, database schema and deployment configuration. Anyone with a bit of technical understanding gets from idea to a running product in a few hours.

This isn't a toy. Product managers build reporting tools that the BI team would deliver in three sprints. Marketing builds landing pages with lead capture and a database behind them. HR builds a small onboarding portal. And developers in the business units build everything they would otherwise have to request from the platform team anyway.

Why this becomes a new class of shadow IT

Classic shadow IT consisted of SaaS tools someone bought with a credit card. That was manageable: you could enforce SSO, sign a DPA with the vendor, run the tool behind a reverse proxy, or block it in an emergency.

Vibe-coding shadow IT works differently. There is no vendor to negotiate with. There is an application someone wrote themselves — based on generated code, in a GitHub account that maybe belongs to the company, maybe is private. The database sits on Supabase or Neon. The frontend runs on Vercel. Authentication happens through Clerk or Auth0, often on a personal account.

Structurally, this shifts responsibility. With a SaaS tool the vendor carries part of the security and maintenance load. With a self-vibed app no one carries it. The code exists, runs, processes data, but there is no maintainer, no on-call, no patch management.

The concrete risks in detail

Data protection and GDPR

When an employee builds an app that processes customer data and hosts it on a US platform, several GDPR obligations are violated very quickly. Typically there's no DPA with the host, no entry in the record of processing activities, no data protection impact assessment, and no technical safeguard for the data transfer. The business unit often doesn't know this, and the data protection officer learns about the application only when something goes wrong.

Generated code makes it worse. AI tools set defaults that make sense in a typical US startup context: logging to an external service, telemetry to OpenAI, third-party scripts in the frontend. In a German mid-sized company handling processor data, that's a string of compliance violations.

Security holes from unreviewed code

AI-generated code isn't inherently worse than hand-written code, but it gets read less often. Whoever codes in the vibe checks the app's behavior, not the implementation. That's exactly where the problems pile up: hardcoded API keys in the repository, missing input validation, SQL statements without prepared statements, CORS configurations that allow everything, JWT validation that accepts tokens as soon as they have the right format.

Every developer knows the hand-written example. Here's a typical vibe-code snippet for an API endpoint:

app.post("/api/orders", async (req, res) => {
  const order = req.body
  await db.query(`INSERT INTO orders (data) VALUES ('${JSON.stringify(order)}')`)
  res.json({ ok: true })
})

It runs. It orders pizza. It also orders anything else an attacker writes into req.body, with no authentication, with SQL injection, with no rate limiting. In a code review this would never get through. In a vibe-coding session it gets through, because the behavior is fine.

Maintenance, key-person risk and black boxes

AI-generated code has an unpleasant property: it works, but no one can change it quickly. Whoever didn't prompt it themselves faces a codebase with no clear architecture, no conventions, often with libraries in odd versions because the model happened to suggest them.

When the person who built the app leaves the company, a black box is left behind. Dependency updates, security patches, adjustments to new requirements — all of it suddenly costs more than the app ever delivered in value. In the worst case it keeps running in production because no one dares to switch it off.

Lock-in with external hosts

Vibe-coding stacks have a tendency toward platforms that look brilliant in the demo. Vercel for frontend and edge functions, Supabase for database and auth, Resend for mail, Upstash for Redis. Each of these platforms is good on its own — together they form a bouquet of vendors with no consolidated logging, no shared identity model, and no unified backup strategy.

Migrating back into a controlled environment is then expensive. Data export, auth migration, domain move, rebuilding the edge logic. This is exactly the step business units avoid, so the apps stay outside.

Why bans fail

The reflexive answer of many IT departments is a ban. Vibe coding becomes a policy issue, AI tools get blocked on company machines, repositories outside the organization are forbidden.

The problem: bans don't solve the original problem. Business units didn't start vibe coding for fun. They started it because their IT requests otherwise mean two quarters of waiting. Ban the fast path without making the slow path faster, and vibe coding simply moves into the shadows — on private devices, in private GitHub accounts, with data carried out by copy-paste.

The more honest diagnosis is this: vibe coding exposes a real bottleneck. When citizen developers can code but not deploy, platform and IT teams deliver self-service options that are slower and more cumbersome than a prompt to Claude. As long as that stays true, the shadow will grow.

The platform answer: self-service with guardrails

The only path that holds up in the medium term is an Internal Developer Platform approach that doesn't ban vibe coding but steers it into a controlled corridor. The goal is simple: it has to be just as fast on your own platform as on Vercel, and the standard path has to bring security, compliance and maintainability out of the box.

What an internal developer platform has to deliver

For a platform to absorb vibe coding without losing its advantages, it needs to do a few things really well:

• Push-to-deploy without a ticket. Push a repository, build automatically, deploy automatically. If that costs more than one click and a commit, the developer goes back to Vercel.
• Built-in identity. Auth, SSO and user management have to be a platform service, not a DIY job. Otherwise auth tokens end up hardcoded in the codebase again.
• Database as a service with backups, encryption at rest and logs by default. No one should have to decide whether backups run.
• Secrets management as a platform feature, not a pull-request convention. AI tools write secrets into .env — the platform has to catch that.
• Observability out of the box. Logs, metrics, traces with no configuration. Otherwise apps emerge that no one can debug.
• Clear defaults for compliance. Region, data residency, data processing — all preconfigured, so a vibe-coding session deploys GDPR-compliant by default.

What a healthy workflow looks like

In the target picture, almost nothing changes in speed for the vibing developer, but a lot changes in the consequences. A realistic flow:

1. The developer prompts her app with Cursor or Claude Code. She gets a frontend, backend, database schema.
2. Instead of deploying to Vercel, git push runs against an internal Git that the platform detects automatically.
3. The platform builds the code, recognizes the needed components — a Postgres database, an object storage — and provisions them as managed services.
4. SSO is wired in automatically. The app inherits the organization's identity model; hardcoded auth tokens are stripped out at build time or blocked.
5. Logs, metrics and traces flow automatically into central observability. Whoever wrote the app sees its errors. Platform and security see anomalies.
6. A policy engine checks on deploy for typical vibe-coding problems: open CORS headers, missing authentication on API routes, unencrypted connections, unusual external calls.
7. The app gets an internal URL and, on request, an external domain. Data residency and backups run with no further effort.

For the developer it's still vibe coding. For IT it's no longer a shadow.

Where a PaaS fits into this picture

Delivering exactly this workflow is the job of a modern PaaS. It takes the code an AI tool spits out and turns it into an application with identity, database, logs, backups and compliance — without anyone writing YAML. Anyone who takes vibe coding seriously in their organization should look at what such a platform looks like and what standards it brings for AI-generated code. That shifts the question away from "How do we ban this?" toward "How do we lift what our people are already doing onto a solid foundation?".

Conclusion

Vibe coding is here to stay. It bypasses classic IT governance because it's faster than any process. Answer with bans, and you push the problem into the shadows. Answer with a platform that combines speed and standards, and you bring it back into the light. The tools for that exist — the only question is who builds them before the next vibe-coded app ends up in a data leak.