Keep GitLab's CI/CD job token allowlist enabled and add only the projects and groups that truly need to call your project from a pipeline. With the allowlist on, a job token from an unlisted project cannot access your project's protected resources. Turning the limit off lets jobs from any project try.
What the job token is
Every GitLab CI/CD job gets a job token, available as CI_JOB_TOKEN. It lets the job call parts of the GitLab API, pull from registries and fetch artifacts. GitLab's documentation lists what it can reach, including the container registry, the package registry, the Terraform module registry, parts of the repository and commits APIs, and the environments and deployments APIs.
The token is short-lived, but while a job runs it carries real access. GitLab's runner security page lists CI_JOB_TOKEN among the secrets that can be stolen from a compromised job environment.
How the allowlist works
By default, per GitLab's docs, the job token's group or project must be on the target project's allowlist before it can access the target. If a project is public or internal, some features are reachable without being on the list, for example fetching artifacts from public pipelines. You can limit that by setting features to be visible only to project members.
GitLab names the setting "CI/CD job token allowlist" in recent versions, after several renamings. The wording in your interface may differ with version, so read the label rather than relying on a name.
Steps to tighten it
- Open the project that holds the resources others use, such as a package registry or shared artifacts.
- Go to Settings, then CI/CD, then Job token permissions.
- Make sure the setting says the project and the allowlist only, not all groups and projects.
- Add the specific groups or projects that need access. You need the Maintainer role to change this.
- For public or internal projects, open Visibility, project features, permissions, and set the features you want restricted to project members only.
- Run the dependent pipelines and confirm they still work. If one fails, add the project explicitly rather than reopening access.
Why not leave it open
GitLab's docs say it is a security risk to disable the token access limit and allowlist. A malicious user could try to compromise a pipeline created in an unauthorized project, and if one of your maintainers created that pipeline, the job token could be used to try to reach yours. The user who triggers the pipeline must also have permission to access your project, which is a second check, but you should not rely on one check alone.
The docs say this option exists on self-managed and dedicated installations when the instance setting that enforces the allowlist is off, and recommend turning the allowlist back on as soon as testing is done.
Related hygiene
- Protect production variables so only protected branches see them. See protected variables in GitLab CI.
- Use ID tokens with a narrow audience instead of stored cloud keys when the service supports it.
- Keep runners clean between jobs, because a compromised job environment exposes the token. See just-in-time runners.
Where Safeguard fits
Safeguard scans dependencies and enforces pull request policy. Job token scope is a GitLab setting, so include it in your quarterly pipeline review.
Quick check
Does the job token expire?
It is tied to the running job. Even so, treat it as sensitive while the job runs, because a stolen token can be used in that window.
Who can change the allowlist?
GitLab's docs say you need the Maintainer or Owner role for the project to change these settings.
Sources
Last reviewed: 19 October 2026.
