The vibe coding threat model

A vibe coding threat model is a structured map of where AI-assisted software development actually breaks: which components have access to what, where trust boundaries sit, and where an attacker can turn a natural-language prompt into a foothold in your infrastructure. It treats vibe coding as a system with named parts, not a vague risk category.

Most of what’s published about vibe coding security so far is a risk list. Ten bullet points, a comparison table of scanning vendors, a call to action. That’s useful, but it isn’t a threat model. A threat model names the concepts in the system, draws the trust boundaries between them, and traces specific attack paths through those boundaries to specific mitigations. Without that structure, “vibe coding is risky” tells you nothing about what to fix first.

Andrej Karpathy coined “vibe coding” in February 2025: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” That shift, from reviewing code to reviewing behavior, is exactly why the old AppSec threat models don’t transfer cleanly. You’re not just modeling a codebase anymore. You’re modeling an agent that reads, writes, and executes on your behalf.

The concepts in a vibe coding threat model

Traditional application threat modeling deals with a fairly stable cast: client, server, database, network boundary. Vibe coding adds concepts that didn’t exist in that picture, or existed but weren’t attacker-reachable the same way.

Concept	Role	Trust level
AI agent	Interprets prompts and generates or executes code	Semi-trusted, acts on your behalf but can be manipulated
Host / IDE	Where the agent runs, with access to your filesystem and local network	Trusted, but only as strong as the agent’s sandboxing
MCP server	Extends the agent with tools, data sources, and external integrations	Variable, ranges from vetted internal tools to unvetted third-party servers
Context window	Everything currently influencing the agent’s output: prompts, file contents, tool results	Untrusted by default, anything that lands here can steer the agent
Executors	Whatever actually runs the generated code (local shell, CI runner, sandbox, production)	High-value target, RCE here is the endgame for most attack paths
Internet-sourced resources	Packages, documentation, scraped pages, API responses the agent pulls in	Untrusted, this is where prompt injection and supply-chain risk both originate
Crown jewels	The credentials, source repos, and production systems the agent can eventually reach	Protect at all costs, everything above exists to reach or defend these

Backslash Security’s threat model, one of the only other attempts at naming this cast explicitly, uses a similar breakdown. Where it stops short is depth: it names the concepts and lists six risks, but doesn’t map specific threats to specific boundaries. That’s the gap this framework fills.

Trust boundaries: where vibe coding threats actually cross

A trust boundary is any point where data or control passes from a less-trusted concept to a more-trusted one without a checkpoint. In a vibe coding setup, three boundaries matter more than the rest.

Internet-sourced resources → context window. Nothing filters what an agent pulls in from a package registry, a scraped webpage, or an API response before it becomes part of the context that shapes the next output. If that content contains instructions, the agent may follow them.

Context window → AI agent output. Whatever’s in context, prompt, file contents, tool results, gets treated as instruction-adjacent by default. There’s no reliable syntactic boundary between “data the agent should read” and “instructions the agent should obey.” This is the mechanism behind prompt injection.

AI agent → executors. Once the agent decides to run something, whether that’s a shell command, a test suite, or a deploy script, the executor usually just runs it. Few vibe coding setups put a real approval gate at this boundary, which is why remote code execution shows up so often in vendor writeups of real incidents.

Everything downstream of these three boundaries eventually points at the crown jewels: credentials in environment variables, the production database, the CI/CD pipeline’s deploy keys.

Threat-by-concept breakdown

AI agent

The agent itself is the softest target because it’s designed to be persuadable. It follows instructions by design, that’s the whole point, and it has no reliable way to distinguish “the developer told me to do this” from “a file I read told me to do this.”

• Over-trust in generated output. Databricks’ AI red team found that Cursor and GPT-4o-based tools could be steered into producing a GGUF parser with a heap-based buffer overflow: an unchecked integer overflow in a malloc() call let a subsequent memcpy() write past the allocated buffer.
• Excessive agency. OWASP’s LLM08 risk category covers agents given more autonomy than a task requires, an agent with unscoped file-system access when it only needed to edit one directory, for example.

MCP server

Model Context Protocol servers extend what an agent can do, and that’s exactly the problem. Every MCP server you connect is a new piece of attack surface with its own trust level.

• Malicious or compromised MCPs. An MCP server that looks like a legitimate integration but has been altered, or was malicious from the start (sometimes called shadow MCP), can feed instructions directly into the agent’s context.
• Excessive MCP permissions. MCP servers are frequently granted broader filesystem or network access than the specific tool call needs, because scoping permissions per-call is more setup work than granting them once.
• Local network exposure. Some MCP implementations bind to network interfaces more broadly than intended, making them reachable from other processes or devices on the same network, not just the agent that’s supposed to use them.

Context window

If the agent is the softest target, the context window is the easiest to poison, because almost nothing challenges what lands in it.

• Prompt injection. Instructions embedded in a file, a webpage, a code comment, or a tool’s output get read into context and can override or redirect the agent’s actual task.
• Context poisoning via internet-sourced content. An agent that fetches documentation or searches for a code example can pull in a page written specifically to manipulate agents that scrape it.

Executors (remote code execution)

This is where a successful attack stops being theoretical.

• Arbitrary code execution. In one of Databricks’ test cases, a generated snake-game example deserialized network objects with Python’s pickle module without any validation, a pattern the researchers flagged as known to be exploitable for arbitrary remote code execution.
• CI/CD execution paths. Agents that can open pull requests or trigger pipelines extend the executor surface into infrastructure the agent doesn’t need direct access to, only the ability to get something merged.

Internet-sourced resources

• Hallucinated dependencies. A USENIX Security 2025 study found that 19.7% of 2.23 million code samples generated by common models referenced packages that don’t exist. Attackers register those exact package names, a technique sometimes called slopsquatting, and wait for an agent to “helpfully” install one.
• Exposed secrets pulled from public sources. Agents that search GitHub or scrape documentation for examples can surface real credentials accidentally committed by someone else, and copy them into your codebase as a working example.

How vibe coding threats differ from traditional STRIDE threat modeling

STRIDE, Microsoft’s original threat-modeling framework, categorizes threats as Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. It still applies to vibe coding, but the concepts it maps onto are different, and one category becomes disproportionately important.

STRIDE category	Traditional AppSec example	Vibe coding equivalent
Spoofing	Fake login page	Malicious MCP server posing as a legitimate tool
Tampering	Modified request payload	Prompt injection altering agent behavior mid-task
Repudiation	Missing audit logs on a transaction	No record of which agent action produced which code change
Information disclosure	SQL injection leaking a database	Agent pulling secrets into context and echoing them into generated code
Denial of service	Traffic flood on an API	Agent stuck in a loop consuming compute or hitting rate limits on an external service
Elevation of privilege	Broken access control on an admin route	Excessive agency: an agent using its own permissions to reach systems beyond its task scope

Elevation of privilege does the most work in a vibe coding context, because most of the concepts above (MCP servers, executors, the agent itself) are built to have more access than any single task requires. That’s convenience for the developer and opportunity for an attacker.

Mapping threats to mitigations

Threat	Concept	Mitigation	Who owns it
Prompt injection via scraped content	Context window	Treat all fetched content as untrusted; strip or quote instructions found in retrieved data before it reaches the agent	Platform/security team
Malicious MCP server	MCP server	Maintain an allowlist of vetted MCP servers; review permissions scope before connecting a new one	AppSec / platform team
Excessive agent permissions	AI agent, executors	Scope credentials per-task, not per-session; use short-lived tokens over standing access	DevOps / platform team
Hallucinated dependencies	Internet-sourced resources	Verify package existence and provenance before install; pin to a vetted internal registry where possible	Developer, enforced by CI
RCE via generated code	Executors	Sandbox execution environments; require human approval before code reaches a production-adjacent runner	Security engineering
Secrets exposure	Internet-sourced resources, crown jewels	Secret scanning pre-commit and pre-merge; rotate anything an agent has ever had in context	AppSec team

None of these mitigations are exotic. What’s different is where they need to sit: at the boundaries named above, not scattered across a generic checklist.

FAQ

Does vibe coding create more vulnerabilities than manual coding?
Not inherently more vulnerability types, but more volume and less review. The change volume from AI-assisted development regularly outpaces what security teams can manually review, and the failure mode isn’t usually a novel bug class, it’s the same old bug classes shipping faster and with a thinner review step.

Can traditional AppSec tools secure vibe-coded apps?
Partially. Static and dynamic analysis still catch insecure code patterns after the fact. What they don’t cover is the agent-specific attack surface, MCP server permissions, context poisoning, excessive agency, because that surface didn’t exist when those tools were designed.

What’s the difference between vibe coding and AI-assisted coding?
AI-assisted coding usually means a developer uses an AI tool to help write specific lines or functions, reviewing each suggestion. Vibe coding means the developer describes an outcome and lets the agent write, run, and iterate on code with lighter line-by-line review, trusting the result rather than the process.

Which applications shouldn’t rely on vibe coding alone?
Anything touching authentication, payment handling, or infrastructure provisioning deserves a human reviewing actual code, not just outcomes. The lighter the review, the more the trust boundary shifts onto the agent, and that’s exactly where this framework says the risk concentrates.

Next step

If you’re building or evaluating a vibe coding workflow, start by drawing your own version of the concept table above for your specific setup: which MCP servers you’ve connected, what the agent’s executor actually has access to, and where your crown jewels sit relative to all of it. That fifteen-minute exercise usually surfaces the one boundary nobody’s watching. For the wider risk picture beyond this framework, see our breakdown of vibe coding security risks.