Vibe Coding Goes Mainstream — And the Security Team Just Found Out

Vibe coding is the practice of building software through rapid, conversational AI prompting — describing what you want and letting the model generate the code — rather than writing it line by line. Coined by Andrej Karpathy in February 2025, it has since moved from a developer curiosity to a mainstream workflow, raising serious questions about security, code ownership, and governance.

The numbers back this up. Lovable, one of the leading vibe coding platforms, reported hitting $500 million in annualized revenue with one million new projects created per week as of early June 2026. That scale means an enormous volume of AI-generated code is going into production, much of it without the review cycles that traditional software development requires.

Why Security Teams Are Catching Up Late

The adoption curve for vibe coding moved faster than most security functions could track. Developers discovered they could ship working prototypes in hours. Product teams loved it. Security teams, mostly not in the loop, are now dealing with the consequences.

The core problem is not that AI generates bad code on purpose. It is that AI-generated code reflects the patterns it was trained on, including insecure ones. Without a developer who deeply understands what the code is doing at each layer, vulnerabilities can slip through that no one on the team would catch on review — because the review is cursory, or skipped entirely.

SecurityWeek summed it up bluntly: everybody is vibe coding, but nobody told the security team.

The specific risks that show up repeatedly in AI-assisted codebases include:

• Hardcoded credentials: API keys and secrets embedded directly in generated code, especially in early prototypes that graduate to production
• Insecure dependencies: AI models pulling in libraries without evaluating their security posture or maintenance status
• Overpermissioned integrations: Connections to GitHub, Jira, databases, and internal APIs granted broader access than the application actually needs
• No input validation: Generated code that trusts user input by default, creating injection vectors
• Invisible attack surface: When developers do not fully understand the code, they cannot model what an attacker would target

What "Agentic Engineering" Changes (and What It Doesn't)

Karpathy, who coined vibe coding, has reportedly moved on from the term itself. Writing in Forbes in June 2026, he now advocates for what he calls "agentic engineering" — a more structured approach where AI agents handle discrete, well-defined tasks with clearer human oversight rather than raw free-form generation.

The distinction matters for security. Agentic engineering implies:

• Agents operate within defined scopes and permissions
• Outputs are reviewable at discrete checkpoints
• Human engineers remain in the loop for architectural and security decisions

This does not eliminate the risk, but it creates natural control points. If an agent's job is narrowly defined, its blast radius when something goes wrong is also narrower. That is a much more defensible posture than "the AI built the whole thing and I shipped it."

Secure Connection Patterns for AI Agents

One of the highest-risk areas right now is AI agents connecting to sensitive systems. When an agent has write access to your GitHub repo, can create Jira tickets, or queries production databases, the stakes change entirely.

A few patterns that actually reduce risk:

Least-privilege credentials by default. Every integration should start with the minimum permissions the agent needs to complete its task — nothing more. Read-only where possible. Scoped tokens, not admin keys.

Credential isolation per agent. Different agents connecting to the same system should not share credentials. If one agent is compromised or misconfigured, that credential getting rotated should not take down unrelated workflows.

Cryptographic identity for agent-built applications. Atsign's AI Architect, announced in early June 2026, takes an interesting approach here: applying cryptographic protections at the identity layer so that even if vulnerabilities exist in AI-generated application code, attackers cannot easily target those applications because their network identities are effectively invisible. It is an early-stage approach but signals where the industry is heading — building security into the agent execution layer, not bolting it on after.

Audit logs on every external call. Agents making API calls to external systems should be logging those calls with enough detail to reconstruct what happened. When something goes wrong — and it will — you need the trail.

MCP and the Governance Gap in Multi-Platform Deployments

The Model Context Protocol (MCP) has become the de facto standard for connecting AI agents to tools and data sources. That is useful for interoperability. It also means that a misconfigured MCP server is now a potential entry point into any system that server connects to.

For enterprise teams running agents across multiple platforms, the governance problems compound:

Problem	What it looks like in practice
No central inventory	Teams do not know what MCP servers are running or what they connect to
Inconsistent auth	Some servers use tokens, some use OAuth, some have no auth at all
No change management	MCP configs change without review, quietly expanding the attack surface
Siloed visibility	Security has no view into what agents are doing across the stack

The answer is not to prohibit MCP usage — that ship has sailed. The answer is centralized discovery and management: knowing what servers exist, what they can access, and who approved those connections.

What Enterprise Teams Should Do Now

If your organization is running vibe coding workflows at any scale, here is where to start:

1. Audit what exists. Map every AI agent, every MCP server, every external integration. You cannot govern what you do not know about.
2. Require code review for AI-generated output going to production. Not cursory review — actual review by someone who understands the security implications.
3. Implement secrets scanning in CI/CD. Catch hardcoded credentials before they ship, not after.
4. Define approved integration patterns. Document what it looks like to securely connect an agent to GitHub, Jira, or a database. Give developers a template so the safe path is also the easy path.
5. Separate prototype from production standards. Vibe coding for exploration and prototyping is lower risk. The problem is when prototype-speed practices carry into production deployment.

The Actual Tension Here

Vibe coding is not going away. Lovable's revenue figures alone tell you that. The productivity gains are real, and developers who have adopted this workflow are not going back to writing everything from scratch.

The challenge for security teams is not to stop it. It is to build the guardrails fast enough to keep pace with adoption. That means getting involved in how agents are built and deployed — not waiting until something breaks.

The move toward agentic engineering, with more defined scopes and clearer human checkpoints, is a useful shift in framing. But frameworks do not protect you. Implementation does. The teams that figure out how to ship fast and maintain a defensible security posture are going to have a real advantage. The ones that are still arguing about whether to allow vibe coding at all are losing time they do not have.