In short. An automated checker can send a Vercel project bypass secret in a header or query parameter, or use a Trusted Sources identity token.
Definition: As of 17 October 2026, Vercel's Protection Bypass for Automation grants an automated checker access to protected deployments through a project secret sent as an HTTP header or URL query parameter. Trusted Sources provides another access method using short-lived identity tokens.
Key facts
- Vercel's Deployment Protection documentation requires authentication for all requests, including requests to Routing Middleware.
- The bypass methods overview lists Protection Bypass for Automation on all plans and gives its secret access to all deployments in a project.
- The Trusted Sources documentation requires a valid token signature, matching configured claims and an allowed deployment environment.
- The automation bypass reference says active attack mitigations remain effective, including attack-related rate limits and security challenges.
How does a checker send the bypass secret?
Vercel's automated access guide gives this setup path: select the project, open Settings > Deployment Protection, then select Create under Protection Bypass for Automation. The checker stores the value in its secret configuration or an environment variable. The guide supplies this request pattern:
curl -H "x-vercel-protection-bypass: $VERCEL_AUTOMATION_BYPASS_SECRET" \
https://your-deployment.vercel.app/api/endpoint
For a tool that accepts only a URL, the equivalent query parameter is:
https://your-deployment.vercel.app/api/webhook?x-vercel-protection-bypass=your_bypass_secret_here
The guide recommends headers because URL secrets can appear in proxy and server logs. It also advises keeping secrets out of source files and version control.
How does browser navigation keep access?
Vercel's automation bypass reference documents an additional header or query parameter for follow-up browser requests. Alongside the bypass secret, the initial request sends:
x-vercel-set-bypass-cookie: true
Vercel sets a bypass cookie through a redirect with a Set-Cookie header. For an embedded page in an iframe, the documented value samesitenone sets the cookie's SameSite attribute to None; its default is Lax.
Each bypass secret remains valid across the project's deployments until revoked. Multiple secrets allow separate access management for different tools. Vercel assigns one secret to the deployment environment variable VERCEL_AUTOMATION_BYPASS_SECRET at build time, so changing that value requires a redeployment.
When can a checker use Trusted Sources?
Trusted Sources authorizes workloads through OpenID Connect (OIDC), an identity token mechanism. It supports other Vercel projects in the same team and external services such as GitHub Actions.
An external service is added under Settings > Deployment Protection > Trusted Sources > External Services. Its rule identifies the token issuer, the required claims and the deployment environments it can access. A claim is a named value in the token: aud identifies the audience, and an identity claim such as repository scopes the calling workload.
Each request carries the token in this header:
x-vercel-trusted-oidc-idp-token: <OIDC_TOKEN>
Vercel validates the signature and checks the configured claims and target environment. A failed check sends the request through the project's other Deployment Protection settings.
What do the other bypass options allow?
Vercel's bypass methods overview describes Deployment Protection Exceptions as preview domains made publicly accessible. Removing an exception restores the default protection settings. Shareable Links grant external access to specific branch deployments through a secure query parameter.
The OPTIONS Allowlist exempts matching paths only for OPTIONS requests, the preliminary requests browsers use for cross-origin access checks. An allowed path prefix therefore covers those preliminary requests; the checker still needs access for its content requests.
Related terms
- How do I protect Vercel preview deployments from public access?
- How do I read Vercel's request and cache response headers?
- How do I filter Vercel runtime logs for a function request?
FAQ
Why does my checker still receive a login page or a 403 response?
Vercel's troubleshooting guide tells you to check that the outgoing request includes the bypass header or parameter and that its value matches an active project secret. After regeneration, update your tool's value and redeploy the project.
Can I revoke one checker's access independently?
Yes. The same automated access guide documents independently revocable secrets, so you can assign each checker its own secret.
Does Standard Protection cover the production domain?
Vercel's Deployment Protection documentation says Standard Protection covers all domains except production domains. All Deployments also covers production domains.
Sources
- Vercel, "Deployment Protection on Vercel", updated 15 September 2026
- Vercel, "Bypass Deployment Protection for testing, sharing, and automation", publication date not stated
- Vercel, "Protection Bypass for Automation", updated 16 September 2026
- Vercel, "Automated & Agent Access", updated 15 September 2026
- Vercel, "Trusted Sources", updated 28 August 2026
Check how a page reads to answer engines. Open the GEO score analyzer