# Vercel Runs DeepSec as a Harness. The Auth Plugin Is the Control. > Vercel handles application security with DeepSec, an open-source agent harness it launched on 4 May 2026. A regex scan picks candidate files. Coding agents investigate them. A second run revalidates HIGH findings. On Vercel monorepos the team wrote a matcher for every auth path and reviews PRs with a two-job CI gate so pull-request code cannot write comments. Source: https://hackerlogs.com/blog/vercel-deepsec-harness Published: 2026-09-12 ## Key takeaways - DeepSec is not a Vercel-hosted scanner. It runs on your laptop or CI. The only thing it adds to the repo is a .deepsec workspace. Vercel says it does not phone home. - The pipeline is scan, process, revalidate, enrich, export. Regex is free and picks candidates. Agents do the expensive read. Revalidation is what cuts false positives. - On Vercel's own monorepos, DeepSec found auth-condition edge cases. The response was a custom matcher plugin that covers every authentication path, not a dashboard. - Vercel published the GitHub Actions it uses on its own PRs: one job reads the diff with no write permission, a second job posts the comment and never runs pull-request code. - Treat DeepSec like a coding agent with a shell. Sandbox mode keeps model keys on the host. Generated matchers compile from JSON and do not eval model-written code. Vercel did not ship DeepSec as a cloud scanner you turn on in the dashboard. [Malte Ubl's 4 May post](https://vercel.com/blog/introducing-deepsec-find-and-fix-vulnerabilities-in-your-code-base) 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. Three panels for how Vercel runs DeepSec: a local harness pipeline of scan, process, revalidate, and export; dogfooding on Vercel monorepos with a custom auth matcher and 1,000-plus sandboxes; and a two-job PR gate that never lets pull-request code write comments. ## What DeepSec actually is. The [README](https://github.com/vercel-labs/deepsec) 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](https://vercel.com/changelog/simplified-onboarding-for-deepsec) 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. > It is a CLI you run. The FAQ says DeepSec does not phone home. Findings stay under `data/` on the machine that ran the job unless you export them. Vercel Sandbox is an optional fan-out, not the product. ## 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](https://deepsec.sh/docs/architecture) 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](https://vercel.com/docs/vercel-sandbox). 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](https://deepsec.sh/docs/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. > If you copy the workflow and merge the comment step into analyze, you copied the YAML and missed the control. The two-job split is the security design. The scan is the content. 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. ## 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. ## Sources - [Introducing deepsec: The security harness for finding vulnerabilities in your codebase](https://vercel.com/blog/introducing-deepsec-find-and-fix-vulnerabilities-in-your-code-base) (2026-05-04) - [Simplified onboarding for deepsec](https://vercel.com/changelog/simplified-onboarding-for-deepsec) (2026-08-10) - [vercel-labs/deepsec](https://github.com/vercel-labs/deepsec) (2026-09-12) - [Reviewing changes (PR mode)](https://deepsec.sh/docs/reviewing-changes) (2026-09-12) - [FAQ](https://deepsec.sh/docs/faq) (2026-09-12) - [Architecture](https://deepsec.sh/docs/architecture) (2026-09-12)