---
title: Trusted Sources
product: vercel
url: /docs/deployment-protection/methods-to-bypass-deployment-protection/trusted-sources
type: conceptual
prerequisites:
  - /docs/deployment-protection/methods-to-bypass-deployment-protection
  - /docs/deployment-protection
related:
  - /docs/security/deployment-protection/methods-to-protect-deployments/vercel-authentication
  - /docs/security/deployment-protection/methods-to-protect-deployments/password-protection
  - /docs/security/deployment-protection/methods-to-protect-deployments/trusted-ips
  - /docs/oidc
  - /docs/security/deployment-protection/methods-to-protect-deployments
summary: Learn about trusted sources on Vercel.
install_vercel_plugin: npx plugins add vercel/vercel-plugin
---

# Trusted Sources

> **🔒 Permissions Required**: Trusted Sources

Trusted Sources is a single setting that lists every caller you've authorized to reach this project's protected deployments. Each caller authenticates by attaching a short-lived OIDC token, so you don't need to share a secret or open the deployment to the public.

The setting is split into two subgroups:

- **Vercel Projects** — other Vercel projects in the same team. This project is always pinned at the top of the list and can call its own deployments by default.
- **External Services** — non-Vercel workloads such as GitHub Actions, GitLab CI, or Bitbucket Pipelines that present an OIDC token from their own identity provider.

Use Trusted Sources for service-to-service traffic when you want to keep [Vercel Authentication](/docs/security/deployment-protection/methods-to-protect-deployments/vercel-authentication), [Password Protection](/docs/security/deployment-protection/methods-to-protect-deployments/password-protection), or [Trusted IPs](/docs/security/deployment-protection/methods-to-protect-deployments/trusted-ips) enabled for everyone else.

## How it works

Each request from a trusted caller carries an OIDC token in the `x-vercel-trusted-oidc-idp-token` header. Vercel validates the token against its issuer, confirms the caller matches a rule on this project, and allows the request through Deployment Protection.

### Default access

By default, this project can call its own deployments within matching environments:

- Production to production
- Preview to preview
- Custom environments to custom environments with the same slug

No other caller is allowed until you add it to Trusted Sources. When you add a Vercel project or external service, the same matching-environment rule applies unless you define custom access rules.

## Vercel Projects

The **Vercel Projects** subgroup covers calls from one Vercel project to another in the same team. The calling project's functions forward their [Vercel OIDC token](/docs/oidc), and Vercel verifies that token against this project's trusted source list.

Secure Backend Access with OIDC Federation must be enabled on the calling project so Vercel can attach the token. This is on by default. If your function does not receive the `x-vercel-oidc-token` header, check the calling project's **Settings** > **Security** > **Secure Backend Access with OIDC Federation**.

### Forward the OIDC token from your code

In the calling project's function, read the incoming OIDC token and forward it on your outgoing request:

```ts filename="app/api/call-protected/route.ts"
export async function GET(request: Request) {
  const oidcToken = request.headers.get('x-vercel-oidc-token');

  if (!oidcToken) {
    return new Response('Missing OIDC token', { status: 401 });
  }

  const response = await fetch('https://protected-project.vercel.app/api/data', {
    headers: {
      'x-vercel-trusted-oidc-idp-token': oidcToken,
    },
  });

  return new Response(await response.text(), { status: response.status });
}
```

### Customize this project's self-access

This project is always listed first in **Vercel Projects**, labeled `(this project)`. By default, it can call its own deployments within the same environment and nothing more.

Customize self-access when you need to:

- Allow access across environments in the same project, for example preview calling production.
- Expand access to additional custom environments.

To customize:

1. Go to **Settings** and select [**Deployment Protection**](https://vercel.com/d?to=%2F%5Bteam%5D%2F%5Bproject%5D%2Fsettings%2Fdeployment-protection\&title=Go+to+Deployment+Protection+settings).
2. In **Trusted Sources** > **Vercel Projects**, open the menu on the first row and select **Customize**.
3. Define `from` and `to` environment pairs that you want to allow.
4. Select **Save rules**.

> **⚠️ Warning:** Custom access rules replace the default same-environment access. If you still want production to reach production or preview to reach preview, add those rules explicitly.

To return to the default, open the menu on the same row and select **Reset to default**.

### Add another Vercel project

1. Go to **Settings** and select [**Deployment Protection**](https://vercel.com/d?to=%2F%5Bteam%5D%2F%5Bproject%5D%2Fsettings%2Fdeployment-protection\&title=Go+to+Deployment+Protection+settings).
2. In **Trusted Sources** > **Vercel Projects**, select **Add**.
3. Choose a project from your team.
4. Optionally, add a note to describe why the project is trusted.
5. Optionally, expand **Custom access rules** to define `from` and `to` environment pairs. Each rule maps environments on the trusted project to environments on this project.
6. Select **Add**.

### Remove a Vercel project

1. Open **Settings** > **Deployment Protection** on the project that granted access.
2. In **Trusted Sources** > **Vercel Projects**, open the menu for the project and select **Remove**.
3. Confirm the removal.

The removed project can no longer reach this project's protected deployments.

## External Services

The **External Services** subgroup covers non-Vercel workloads that present a token from their own OIDC issuer. For each service you tell Vercel:

1. The provider's issuer URL, for example `https://token.actions.githubusercontent.com`.
2. The claims the token must include, such as `aud` and `sub`, along with the values you accept for each claim.
3. The environments on this project that requests are allowed to reach.

On each incoming request, Vercel validates the token against the issuer, confirms every required claim matches one of the values you configured, and allows the request through Deployment Protection.

### Supported providers

The dashboard includes templates that prefill the issuer and common claims for:

- **GitHub Actions**
- **Vercel OIDC (external team)** — calls from another team's Vercel projects
- **GitLab CI**
- **Bitbucket Pipelines**
- **Custom provider** — any OIDC provider not listed above

Each template links to the provider's OIDC documentation so you can find the claim values that identify your workload.

### Attach the OIDC token from your code

The external service must attach its OIDC token to each outgoing request in the `x-vercel-trusted-oidc-idp-token` header.

For example, from a GitHub Actions job:

```yaml filename=".github/workflows/e2e.yml"
jobs:
  e2e:
    permissions:
      id-token: write
    steps:
      - uses: actions/github-script@v7
        id: token
        with:
          script: |
            const token = await core.getIDToken('https://github.com/<org>');
            core.setOutput('token', token);
      - run: |
          curl -sSf https://protected-project.vercel.app/api/data \
            -H "x-vercel-trusted-oidc-idp-token: ${{ steps.token.outputs.token }}"
```

Replace `https://github.com/<org>` with the audience you configure when you add the service. Other providers expose the token in their own way: see their OIDC documentation for the exact call.

### Add an external service

1. Go to **Settings** and select [**Deployment Protection**](https://vercel.com/d?to=%2F%5Bteam%5D%2F%5Bproject%5D%2Fsettings%2Fdeployment-protection\&title=Go+to+Deployment+Protection+settings).
2. In **Trusted Sources** > **External Services**, select **Add**.
3. Choose a provider template, or select **Custom provider** to enter your own issuer.
4. Confirm or edit the **Issuer URL**. It must be an `https://` URL with no placeholder segments.
5. Optionally, add a note to describe the workload.
6. Under **Required claims**, enter the values the incoming token must have. The token must include every claim you list, and its value must match one of the comma-separated entries. `aud` and `sub` are required.
7. Under **Applies to environments**, select which environments on this project the rule allows the external service to reach.
8. Select **Add**.

> **⚠️ Warning:** Every claim you configure must match exactly. If you leave a claim out, any value is accepted for it, which weakens the check. Scope `sub` as tightly as your provider allows, for example to a specific repository and branch.

To allow the same provider to reach different environments with different claims, for example a production audience and a preview audience, add one entry per environment.

### Remove an external service

1. Open **Settings** > **Deployment Protection** on the project that granted access.
2. In **Trusted Sources** > **External Services**, open the menu for the entry and select **Remove**.
3. Confirm the removal.

The external service can no longer reach this project's protected deployments.

## Related resources

- [Vercel OIDC](/docs/oidc)
- [Methods to protect deployments](/docs/security/deployment-protection/methods-to-protect-deployments)
- [Methods to bypass Deployment Protection](/docs/security/deployment-protection/methods-to-bypass-deployment-protection)


---

[View full sitemap](/docs/sitemap)