AI Agent Hallucinates Repo ID, Deploys Wrong Code to Vercel

Vercel CEO Guillermo Rauch posted a detailed incident report yesterday after a user's account unexpectedly deployed an unknown GitHub repository to their team project. What looked like a potential security breach turned out to be something arguably stranger: an AI agent that fabricated a repository ID from thin air and sent it directly to Vercel's deployment API.

A Vercel user reported an issue that sounded extremely scary. An unknown GitHub OSS codebase being deployed to their team...

Turns out Opus 4.6 *hallucinated a public repository ID* and used our API to deploy it.

- Guillermo Rauch (@rauchg) March 3, 2026

What Happened

The user was running Claude Opus 4.6 inside the OpenClaw agent framework with access to Vercel's API. The agent's task was to deploy a project. Instead of calling the GitHub API to retrieve the actual repository ID, it skipped that step entirely and invented a plausible-looking numeric value: 913939401.

The JSON payload it sent to Vercel's API looked like this:

"gitSource": {
  "type": "github",
  "repoId": "913939401",  // hallucinated
  "ref": "main"
}

The agent had the correct Vercel project ID and project name. It knew those details. It just never looked up the GitHub repo ID - there were zero GitHub API calls in the session before the deployment fired. The number 913939401 appears for the first time at line 877 of the session log. The agent fabricated it entirely.

By chance, that numeric ID belonged to a harmless public repository containing student homework code. Nothing ran. The user noticed an unfamiliar repo had been linked to their team project and filed a report. Vercel's security and infrastructure teams engaged before determining the source was not an external attacker but the user's own agent behaving unexpectedly.

Rauch confirmed the repo ID published in the post was randomized for privacy - the real incident involved a different (equally harmless) repository.

Why This Matters

Hallucinations in chat contexts are irritating. Hallucinations in agentic contexts with live API access are a different problem category.

The agent here had sufficient permissions and correct authentication to execute a real deployment. It used a fabricated ID not because it was confused about what a repo ID is - it understood the field perfectly - but because it skipped the verification step that would have produced the correct value. It filled in the gap with something that looked right and moved on.

Rauch's summary is blunt: "Humans make lots of mistakes, but certainly not make up a random repo ID."

This is the core asymmetry. Human errors in workflows tend to cluster around predictable failure modes - typos, copy-paste mistakes, misreading values. Agent errors can be arbitrary in ways that are genuinely hard to anticipate. An off-by-one error would be detectable. An entirely fabricated integer that happens to resolve to a valid public repo is not something any review checklist is written to catch.

The API vs. CLI Question

Rauch flagged a structural issue worth noting: the agent chose to call Vercel's REST API directly rather than using the CLI or an MCP integration. He argues this likely made the failure worse.

The CLI and MCP tools built for Vercel deployments include validation steps that the raw API does not enforce at the call level. An agent hitting the API directly bypasses those guardrails. The API exists to let legitimate integrations deploy legitimate code efficiently - not to serve as a sandbox where an agent can supply unverified inputs.

Vercel's own sandbox documentation for running OpenClaw recommends network egress lockdown and restricted allowed-domain policies precisely to limit what an agent can reach. Whether the affected user had those controls in place is not known.

OpenClaw's Role

Rauch was careful not to blame OpenClaw specifically. "I don't think OpenClaw was to blame here per se. It's just an agent with access to tools and keys." The framework gave the agent access to the Vercel API, which is what it is designed to do. The failure was in the model's reasoning, not the tool scaffolding.

This distinction matters for how teams think about agent security. Sandboxing and tool access controls reduce blast radius, but they do not address the underlying issue: a model that skips a verification step and fills the gap with a fabricated value will do so whether it is running in OpenClaw, Claude Code, or any other framework.

What Vercel Is Doing

Rauch committed to making Vercel "the most secure platform for agentic engineering" through deeper integrations with tools like Claude Code and additional guardrails. No specific technical changes were announced.

The obvious mitigations are not new - subagent verification steps, human approval gates before consequential API calls, repo ID lookups as a required precondition before any deployment payload is constructed. What this incident illustrates is that those guardrails need to be built into the workflow design rather than assumed to emerge from a capable model.

The agent knew enough to deploy. It did not know enough to verify what it was deploying. That gap is not a model capability problem. It is a workflow design problem. And until agentic workflows treat unverified inputs as blockers rather than gaps to fill, incidents like this will keep surfacing - usually harmless, occasionally not.