Vercel Runs DeepSec as a Harness. The Auth Plugin Is the Control.

Vercel did not ship DeepSec as a cloud scanner you turn on in the dashboard. Malte Ubl's 4 May post is the operator document: an Apache-2.0 harness that runs on your infrastructure, uses coding agents at maximum thinking, and is expensive on purpose. How Vercel handles security with it is more specific than "we run AI on the repo." They wrote a matcher for their own auth, they fan the work across a thousand sandboxes, and they published the two-job CI they use on their own pull requests.

What DeepSec actually is.#

The README is blunt. DeepSec is for on-demand review of large existing repos, not for a five-file side project. It is configured to use the best models at maximum thinking. Scans of large codebases can cost thousands or tens of thousands of dollars. Customers, Vercel says, paid it because the findings were ones that would otherwise have stayed unfixed.

The pipeline is the same one Vercel describes for its own work:

1. scan runs the regex matcher set. No model. About 15 seconds on a 2,000-file tree. This only picks candidates.
2. process sends pending files to Codex, Claude, or Pi. Current docs default Codex to gpt-5.5 and Claude to Opus 4.8. The May launch post used Opus 4.7 at max effort and GPT 5.5 at xhigh.
3. revalidate has a second agent re-read the code and the git history and mark each finding true-positive, false-positive, fixed, or uncertain. Vercel’s launch post put raw false positives at roughly 10 to 20 percent and said revalidation is how they live with that. The FAQ now quotes about 10 to 29 percent on HIGH and above after revalidation, and a 50 percent-plus cut on most repos.
4. enrich attaches committers, and an ownership plugin if you have one.
5. export turns findings into markdown or JSON that a human or another coding agent can file.

On 10 August, Ubl collapsed first-run setup into npx deepsec init: isolated .deepsec workspace, model route, generated attack-surface notes, extra matchers where coverage is thin, then the first paid review. Interrupted runs resume. Caps exist for spend and duration.

How Vercel runs it on Vercel.#

The launch post is the only public account of internal use, and it is specific. Running DeepSec against Vercel’s own monorepos found subtle edge cases in auth conditions. The follow-up was not a severity dashboard. It was a custom scanner plugin that covers every authentication path in their code.

That is the part to steal. The built-in matcher set is generic. The architecture notes say organization-specific matchers, notifiers, and ownership oracles slot in as plugins. Generated matchers, when setup writes them, compile from strict JSON and are not evaluated as model-written code. Vercel’s own plugin is the difference between "we ran an agent" and "we know every login."

Scale is the other number. Scans on Vercel’s codebases routinely use 1,000 or more concurrent Vercel Sandboxes. A single machine can take days. Sandbox mode tarballs the working tree, excludes .git, and keeps model credentials on the host. Workers see a placeholder. The real token is injected at the allowed egress host. Network from a worker sandbox is limited to coding-agent hosts after bootstrap.

They also ran it on customer and partner open source during development. James Perkins at Unkey and Steven Tey at dub.co are the named replies in the launch post. Tey’s line is the one that matches the product: lots of automated reports, few of them actionable, and it runs on infrastructure the app owner controls.

Vercel is explicit about fit. DeepSec works best for applications and services. Libraries and frameworks likely need custom prompts and scanners. That is a bound, not a feature list.

The security model of the scanner.#

The README tells you to treat DeepSec like a coding agent with full shell access on the box that runs it. Inputs are supposed to be your source. Vendored code and dependencies are still a prompt-injection surface. Sandbox is how they shrink that:

• Agent API keys are injected outside the sandbox and cannot be read out of the worker.
• Worker egress is limited to coding-agent hosts. Bootstrap can reach further; the agent loop cannot.

CI is where Vercel’s own process is most concrete. Reviewing changes documents process --diff and then says, in those words, that the workflow below is the one they use to review their own PRs.

Two jobs. analyze checks out the pull request, installs, and runs DeepSec with the AI Gateway secret. It has contents: read and no write. comment has pull-requests: write and never runs pull-request code. It only posts a markdown artifact. Fork PRs are skipped. Exit code 1 means net-new findings. Pre-existing findings on touched files do not fail the build.

The threat-model notes in that page are the practitioner cut. A pull request can add a postinstall script or a config file the CLI loads. If that job also has permission to comment, the agent and the attacker share a step. Do not collapse the jobs. Pin actions to SHAs in production. The Gateway secret still flows through PR-controlled install. The same-repo gate is what keeps that from being a fork issue. For defense in depth they suggest a label gate.

Model data is a separate decision from the Vercel project link. The link exists so Sandbox can authenticate. The model route can be Gateway, a direct provider key, or a machine-wide claude or codex login. DeepSec stores the name of the key’s environment variable, not the key. Gateway’s advertised property is zero retention of prompts. Direct Anthropic is Anthropic’s policy.

What it is not.#

It is not a sound analyzer. Matchers miss, and files with no hits still get a holistic agent read in PR mode, which is how they avoid "the regex said this file is fine." It is not cheap enough to spray across every draft branch. The FAQ’s Opus ballpark is 25 to 60 dollars per 100 files, hundreds for 500, and 500 to 1,200 dollars for 2,000, swinging two to three times with file complexity. triage is about a cent a finding. revalidate costs like process.

It is not a substitute for a human on auth. Vercel’s own lesson is that the first scan told them where the matcher was wrong. Cyber-tuned models are optional. Refusals are logged on the file record so a later --reinvestigate with the other backend can pick them up. Findings dedupe across agents.

1. 2026-05-04
   Vercel open-sources DeepSec. Ubl describes internal monorepo use, a custom auth matcher, and 1,000-plus sandbox fan-out.
2. 2026-08-10
   Changelog: npx deepsec init now scaffolds the workspace, threat model, coverage matchers, and the first review in one checkpointed run.
3. 2026-09-12
   Public docs still describe the same pipeline, PR-mode --diff, and the two-job GitHub Actions Vercel says it uses on its own pull requests.

What to do.#

If you ship a Vercel or Next.js app, or you already run coding agents on a monorepo:

1. Decide the cadence before you spend. Full-repo scan plus process is the initial sweep. process --diff is the PR gate. Do not use PR mode as your first look at a 5,000-file tree.
2. Write the matcher for your auth, tenancy, and data layer. Vercel’s internal control was "every authentication path," not "we bought more tokens." The docs tell you to hand a first run to a coding agent and ask it which matchers are missing. Review what it writes.
3. Revalidate HIGH before anyone files. Export after that, so tickets match a second agent’s verdict, not the first pass.
4. If you gate CI, keep the two-job split. Analyze has the secret and no write. Comment has write and no pull-request code. Skip forks. Pin actions.
5. If the repo is large enough to saturate a laptop, use Sandbox on purpose, not because the init wizard linked a project. Keys stay on the host. Workers are not your laptop.

Vercel’s security story with DeepSec is not that an agent found bugs. It is that they treated the first findings as a coverage gap, wrote the matcher, and built a CI path that assumes the pull request is hostile. Copy that, not the launch screenshot.