GitLab CI_JOB_TOKEN allowlist: control cross-project access

A GitLab job token is valid only while the job runs, and by default it can reach only the project that created the pipeline. To let one project's jobs touch another, add it to the CI/CD job token allowlist. Keep the allowlist enabled, add the narrowest entries you can, and review the access log.

What the token is

GitLab generates a unique token for each CI/CD job, exposed as the CI_JOB_TOKEN predefined variable. Jobs use it to authenticate with certain GitLab features. When the job ends, access is revoked.

The token has the access of the user who triggered the pipeline, but it can reach fewer resources than a personal access token. Only specific endpoints are available for many APIs, and job tokens cannot authenticate GraphQL requests. Git clone works with the user gitlab-ci-token and the token as the password.

Cross project access

By default a token can access only its own project. To allow another, add the group or project to the allowlist in the target project's settings. Adding a project does not grant extra permissions. The triggering user still needs access to the resources.

Notes from the documentation:

• A group entry covers every project in that group and its subgroups, including ones created later.
• The limits are 200 groups and 200 projects, counted separately.
• Maintainer or Owner role is required to change allowlist and token settings.
• Public and internal projects can still expose some resources, like artifacts, registries, releases and repositories, to tokens from any project. You can restrict these to project members.

Why prefer project over group entries

A group entry grows by itself as new projects appear. That is convenient and also quietly widens access. For sensitive targets, list individual projects.

Settings to leave alone

GitLab's security recommendations:

• Keep the allowlist enabled. Disabling it is a security risk and should only be temporary.
• Send the token in the JOB-TOKEN header, not in a query string.
• Avoid Docker privileged mode on reused machines.
• Avoid the shell executor when jobs share a machine.
• Git push with job tokens is off by default. Turning it on needs several conditions and should not be used on pull mirrors.

Tokens are masked in job logs, but as covered in masked versus protected variables, masking is not a full defense.

Review who used your project

GitLab provides a job token authentication log. Use it to see which projects have used tokens to access yours. If you find one you did not expect, remove it from the allowlist and ask why it was calling.

Fine grained permissions can also explicitly limit the REST endpoints a token can reach. Use them where available.

Quarterly routine

1. List each project's allowlist entries.
2. Remove entries whose owners cannot explain them.
3. Check the log for unexpected callers.
4. Replace group entries with project entries for sensitive repositories.

Safeguard asset discovery and the free scan at gold.safeguard.sh/scan can help you see what your projects contain.

Quick check

Sources

• CI/CD job token

Last reviewed: 19 October 2026.