Vibe Coding Security Risks in AI-Assisted Enterprise Development

A developer who writes a line of code by hand knows why it exists. They know why the query is parameterized, why row-level security is switched on, why the token lives on the server instead of the browser. Authorship and understanding are the same act: that is why code review has worked as a security control for four decades, and the person who shipped the bug can usually explain, under questioning, what they were trying to do. A developer describes what they want in a natural-language prompt, an AI model produces the implementation, and the developer accepts it because it runs and does what was asked. Nothing in that transaction requires the developer to know what the model left out: no rate limiting, no input sanitization, no check on who's allowed to call the endpoint. Call this the comprehension gap. Functional correctness and security correctness used to travel together because one person was responsible for both. Vibe coding lets them separate, quietly, and the separation holds no matter how skilled the person typing the prompt happens to be.

Who is actually doing vibe coding today and why that expands the blast radius

The comprehension gap would be containable if it only applied to professional engineers, most of whom at least know what a security review looks like even when they skip one. It doesn't stay contained, because most people vibe coding today aren't developers. Analysts, ops staff, and product managers are building landing pages, internal dashboards, and CRM automations that used to take an engineering team weeks, and they make up most of the people doing this work. Adversa AI calls this group "citizen developers," people with no engineering background shipping tools straight into production, and the firm notes they tend to overestimate the security of what they've built, if they think about security.

Builder platforms such as Lovable and Base44 make the problem worse by removing the few decisions a citizen developer might otherwise have to make. The platform hosts the app, owns the authentication, manages the database, and sets the deployment defaults, so every tenant inherits whatever security posture the vendor shipped with. Subscriptions start cheap enough to expense on a personal card, no IT approval required. Coding agents like Claude Code, GitHub Copilot, and Cursor present a related but distinct risk: non-professionals running these tools with auto-accept switched on hand the agent their own permissions and supply almost no human review in return. Either path produces the same blind spot. Vibe-coded apps are usually public by default, so a standard endpoint security tool can't tell a builder-platform click from someone just reading the news. The enterprise doesn't know what's being built, and it doesn't know what's been deployed either.

The vulnerability classes AI-generated code reliably produces

The comprehension gap doesn't produce random failures. It produces the same handful of failures, over and over, because AI models learn from training data that skips the same defensive patterns consistently. Wiz, as documented by Adversa AI, found that Base44 exposed undocumented registration endpoints that required no authentication at all, letting anyone holding a public app ID mint a verified account across internal corporate chatbots and HR tools. The registration flow worked exactly as intended. It just never checked who was asking.

SQL injection and cross-site scripting follow a similar path. A security research group found XSS vulnerabilities in a large majority of AI-generated code samples tested across major language models, and the reason is mundane: models trained on older codebases keep reproducing string-concatenated queries instead of parameterized ones, because that's what most of the training data looked like. Over-permissive identity and access management appears at the infrastructure level too. If you ask an AI coding agent to write an infrastructure template, it will reach for wildcard permissions almost every time. Apiiro's enterprise data shows that AI-generated code has significantly more privilege escalation paths than code you write by hand. Arnica's review of the Tea app incident puts the pattern at consumer scale, free of any corporate complexity: broken access control logic generated by AI shipped without a security review, and private direct messages ended up visible to other users. No sophisticated attacker was involved. The code just did what it was asked and nothing more.

The Moltbook and Base44 Breaches as a Model for Enterprise Risk

What makes the Base44 breach useful as a case study is the absence of any complexity. Wiz found undocumented registration endpoints that required no authentication, so anyone with a public app ID could mint a verified account. The endpoint satisfied the functional request, so user registration worked, but it quietly failed the security requirement that only authorized users should be able to register. That gap sat there until someone found it.

The pattern repeats across builder platforms, Base44 and Lovable among them: the AI fulfills the request as stated, the developer accepts the result because it runs, and the security failure stays invisible until someone exploits it. No malware, no insider, no social engineering. Just an open door nobody checked for. That simplicity is what makes these breaches the right model for enterprise risk, rather than a distraction from it: strip away the usual noise of a security incident and what's left is the comprehension gap operating in pure form. The obvious objection is that enterprises run more mature review processes than a solo builder on a weekend project. That objection collapses against the population described earlier: the non-developer majority shipping internal tools inside large companies isn't routed through those mature review processes. They build on personal credit cards, outside the engineering org chart.

Why traditional SAST cannot close the comprehension gap

Static application security testing was built for a world where a human wrote the code, so a scanner could pattern-match what came out against a known library of vulnerability signatures. That architecture doesn't map cleanly onto how AI-generated code fails.

Hallucinated dependencies are the clearest mismatch. A scanner cannot flag a package that doesn't exist yet at scan time, and by the time an attacker registers that exact package name and ships malicious code into it, the scan already passed clean. Authorization gaps are harder still, because you need to understand intent, not just syntax. A scanner can confirm that a route exists. It cannot tell whether that route should require a login, because that decision lives in a requirements document the tool never reads. Pipeline manipulation and prompt-layer attacks happen earlier in the chain than any scan runs. Rules File Backdoors hide malicious Unicode inside.cursorrules or.windsurfrules configuration files, and MCP configuration poisoning, tracked as CVE-2025-54136 and known as MCPoison, compromises the agent's instructions before a line of code is even generated. SAST runs after the code exists. These attacks are already finished by then.

The gap worsens as volume increases. Adversa AI documents that AI-assisted developers commit code significantly faster than their unassisted counterparts, which scales the number of security findings from the thousands into the tens of thousands per month. A security team drowning in that volume doesn't get safer. It gets numb, triaging less carefully as the queue grows, which is the opposite of what more scanning was supposed to buy. Better SAST rules, including AI-specific rule sets tuned to these new patterns, help close known gaps and are worth building. They still can't see an authorization decision if it was never written down, or an attack that happened in a configuration file before the model ever generated output.

The attack surface that runs above the code: agent-layer and MCP threats

Everything above concerns the code an AI model writes. A separate layer of risk sits above that: the agents and MCP servers developers wire together to let AI tools act on their behalf, infrastructure most of them don't fully understand either. Hidden Unicode in a.cursorrules file and the MCPoison configuration-poisoning exploit tracked as CVE-2025-54136 both operate here, compromising an agent's behavior before it ever touches a code repository.

Adversa AI notes that an agent running with auto-accept enabled inherits the full rights of the human who's using it, so any untrusted content that agent ingests, a malicious webpage, a poisoned document, can leak data or quietly install an attacker's MCP server on that employee's machine. The scale of this problem inside large enterprises is already measured. An Okta case study of a large regulated asset manager found thousands of agents running inside the company's environment, and almost none had been approved by anyone, while only a handful out of hundreds of MCP servers had gone through any sanctioning process. That ratio describes an enterprise with no visibility into its own agent sprawl: the comprehension gap occurs here too, not in a line of code but in the plumbing connecting dozens of systems together.

Banning Vibe Coding Drives the Risk Underground

The instinctive response to all of this is prohibition: block the builder platforms, restrict the coding agents, write a policy and call it solved. Adversa AI states that bans don't work and only push the behavior underground, and the logic holds up under scrutiny. Banning a tool doesn't remove the incentive that made someone reach for it in the first place, a dashboard needed by Friday, a CRM automation nobody has engineering time to build. It just moves the activity somewhere IT can't see it.

The comparison to shadow IT makes the mechanics concrete. Enterprises never solved shadow SaaS by banning Dropbox. They built governed distribution layers instead: single sign-on integration, data loss prevention controls, an approved catalog that made the sanctioned option easier to reach than the unsanctioned one. Vibe coding is following the identical curve. Banning it doesn't remove the Base44 registration-endpoint vulnerability; you just lose the ability to know the app exists before something exploits it. The usual counter says a strong acceptable-use policy backed by manager enforcement can suppress the behavior, but that misjudges who's actually doing this work. The non-developer majority building internal tools doesn't report through engineering management structures, and the tools they use cost less than a monthly parking pass, so they pay on a personal card that never crosses a manager's desk.

What a Governed Layer for Vibe Coding Looks Like

Closing the comprehension gap takes a governed layer operating at three levels: tool access, code gates, and runtime agent controls, built to plug into identity infrastructure the enterprise already runs rather than standing up a parallel security stack from scratch.

Tool access starts with a sanctioned marketplace, SSO-integrated and IT-approved, and it's genuinely faster to use than digging out a credit card and signing up for an unapproved builder platform. Authorization finer than role-based access control allows sits above that: relationship-based (ReBAC) or attribute-based (ABAC) models express context-sensitive permissions in ways a fixed role never could, and this matters once an AI agent, not a human, is the one making the access decision in real time.

MCP traffic needs a gateway between agents and the servers they call, one that authenticates every client, controls which tools each caller can see, and logs every call made. It works the way an API gateway works for a conventional web service, except the clients making requests are autonomous. That gateway needs to issue short-lived tokens scoped to specific tool sets, tie into identity providers such as Okta or Entra ID through OIDC, and refresh credentials automatically, because static API keys and long-lived secrets have no place in an enterprise MCP deployment. The commercial options already reflect this requirement in different ways. NeuralTrust's TrustGate runs a Security Engine that inspects the content of tool calls inline and reasons across an entire session, so it doesn't stop at the question of who's allowed to call what. Cloudflare's AI Gateway, paired with MCP Server Portals, uses Cloudflare Gateway's DLP engine to spot unauthorized remote MCP servers running on the network, with identity carried through Cloudflare Access. One vendor's MCP Gateway runs natively on a container orchestration platform, authenticating clients with Entra ID bearer tokens and assigning app roles per server and per tool, with telemetry flowing into Azure Monitor. Amazon's Bedrock AgentCore Gateway is fully managed on AWS, handling inbound authentication for agent identity with observability and auditing built in.

Code gates close the loop at the pipeline level: mandatory secrets scanning before any merge, dependency integrity checks that catch hallucinated or unrecognized packages before they ship, and AI-specific SAST rules aimed squarely at the authorization gaps and over-permissive IAM patterns these models keep reproducing. Threat detection at the agent layer, blocking PII exposure, defending against prompt injection, catching exposed secrets, needs to run inline as the agent operates, not get bolted on afterward as a report nobody reads. Adversa AI frames this as protecting the build process and the live runtime at the same time, not one or the other. None of it works without data classification sitting in front of agent access: an agent should only reach the data its task actually requires, and wiring an autonomous agent straight into production data with no classification layer in between is how both the Base44 and Moltbook failures happened.

The principle holding all three levels together is the same one shadow IT already taught the industry once: a governed path only works if it's genuinely less friction than the workaround. If the sanctioned marketplace is slower than signing up for Base44 on a personal card, the comprehension gap will route straight around it, the same way it always has.