# Treat a GitLab job-token allowlist as a second gate, not a permission grant

> Cross-project job access requires an allowed source and an already-authorized triggering user.

- Canonical URL: https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-15T13:33:39+00:00
- Modified: 2026-10-15T13:36:17+00:00
- Last reviewed by DSE: 2026-10-15
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Cross-project job access requires an allowed source and an already-authorized triggering user.

## Potentially affected

This applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.

## DSE recommendation

DSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline.

## Article

Cross-project job access requires an allowed source and an already-authorized triggering user.

## Source facts

GitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.

Source: [GitLab — CI/CD job token](https://docs.gitlab.com/ci/jobs/ci_job_token/).

## Applicability

This applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.

## DSE recommendation

DSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.

## Verification

Test the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.

## Official reference

[GitLab — CI/CD job token](https://docs.gitlab.com/ci/jobs/ci_job_token/). Reviewed October 15, 2026.

## Primary reference

- Name: GitLab — CI/CD job token
- Authority: docs.gitlab.com
- URL: https://docs.gitlab.com/ci/jobs/ci_job_token/
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Treat a GitLab job-token allowlist as a second gate, not a permission grant,” DSE Security, https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.