Just-in-time elevation for GitLab service accounts reduces CI/CD risk

At a glance

What this is: This demo shows how a GitLab pipeline can use just-in-time elevation to let a GCP service account write to a GCS bucket only during an approved build step.

Why it matters: It matters because CI/CD service accounts with standing privilege are a common NHI governance gap, and IAM teams need task-scoped access models instead of always-on permission.

👉 Read P0 Security's demo on just-in-time elevation for GitLab service accounts

Context

CI/CD service accounts are non-human identities that execute build and deployment tasks on behalf of software delivery workflows. The governance problem is not whether they can work, but whether their permissions stay broader and longer than the task actually needs.

This article is about moving a GitLab pipeline from standing access to just-in-time elevation. That shift matters because the access window, approval step, and automatic revocation become part of the control model, not an afterthought.

Key questions

Q: What breaks when CI/CD service accounts do not use just-in-time access?

A: Standing access turns build automation into a persistent privilege path. The pipeline can keep writing, deploying, or modifying cloud resources long after the task that justified access has finished, which increases blast radius if the account is compromised or misused.

Q: Why do standing permissions in GitLab pipelines increase security risk?

A: Because the identity can act outside the specific build step that needed access. A broad service account role lets a future pipeline run, or an attacker who controls it, reach buckets, secrets, and infrastructure without a fresh governance decision.

Q: How do you know if just-in-time elevation is actually working?

A: JIT is working only when privilege is time-bound, task-scoped, and revoked at the end of the session without relying on a later scheduled rotation. You should be able to prove who approved the access, what happened during the session, and that the privilege could not be reused after the task completed.

Q: What is the difference between just-in-time access and standing privilege for NHIs?

A: Just-in-time access grants permissions only when a task requires them and removes them afterward, while standing privilege leaves access in place continuously. For NHIs, the difference is critical because ephemeral access only reduces risk if revocation and monitoring are automatic.

Technical breakdown

Standing privilege in CI/CD pipelines

CI/CD pipelines often run with service accounts that are granted broad roles to avoid build friction. In practice, that means a machine identity can read, write, deploy, and reconfigure long after the specific job it was created for is done. The technical risk is not just excess privilege, but persistence: the identity remains authorised across future runs, so any compromise or misuse inherits the same scope until someone manually changes it.

Practical implication: treat pipeline service accounts as revocable execution identities, not durable operators.

Just-in-time elevation for machine identities

Just-in-time access changes the permission state from permanent to task-scoped. A pipeline begins with minimal rights, requests a temporary role for a defined action, and then returns to its baseline once the window expires. For machine identities, this is an access issuance pattern, not a login experience: the control must be bound to the build step, the approved scope, and the expiry event so the identity cannot carry extra authority into the next run.

Practical implication: bind elevated roles to specific pipeline steps and enforce automatic reversion at expiry.

Approval, auditability, and reversion as control mechanics

The demo shows that access control is only complete when approval, logging, and revocation all work together. Approval provides context, auditability creates a record of why a machine identity changed state, and auto-reversion removes the need for manual cleanup. Without all three, just-in-time elevation becomes a temporary policy label rather than a real containment mechanism. That distinction matters in CI/CD because the next pipeline execution is often minutes away.

Practical implication: require approval records and automated rollback for every temporary machine privilege grant.

Threat narrative

Attacker objective: The attacker wants to turn trusted automation into a reusable privilege path that reaches cloud resources and secrets.

1. Entry occurs through a CI/CD pipeline service account that already has broad standing permissions to production resources.
2. Escalation happens when that identity can write, reconfigure, or assume additional roles beyond the specific build step it was meant to support.
3. Impact follows when a compromised or misused pipeline account can modify buckets, leak secrets, or alter infrastructure without a fresh access decision.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing access is the core governance failure in CI/CD machine identity programmes. The article makes clear that the risky condition is not pipeline automation itself, but service accounts that retain broad permissions after the build step ends. Once a GitLab pipeline can write to cloud storage whenever it runs, the identity has become a standing operator rather than a task-scoped actor. Practitioners should treat persistent elevation as a lifecycle defect, not a convenience choice.

Just-in-time elevation is a permission state change, not a workflow feature. The meaningful control here is that the machine identity starts with minimal access, receives a scoped grant for a narrow build action, and then automatically returns to baseline. That sequence matters because governance for NHIs is about when authority exists, not just what the role contains. The implication is that access controls must be evaluated at issuance time, not only at provisioning time.

Ephemeral credential trust debt: CI/CD teams accumulate trust debt whenever they allow a machine identity to keep write or admin rights between build runs. That debt is invisible until a compromised token, misused role, or forgotten approval window turns a routine pipeline into a cloud-impact event. The practitioner conclusion is simple: every standing permission in delivery automation is latent exposure that must be justified repeatedly.

Approval, audit, and auto-reversion must be treated as one control plane. A temporary elevation request without logging leaves no trace, and a logged request without automatic rollback leaves lingering authority. The article shows that the control works only when the approval decision, the time window, and the removal event are linked. Teams should govern these three states as a single lifecycle, not as separate tools.

CI/CD identity governance now sits at the intersection of NHI and cloud privilege management. GitLab service accounts increasingly act as the operational bridge between code, infrastructure, and data services, which means their access scope shapes overall blast radius. This is where NHI governance and cloud IAM converge: the question is not whether the pipeline can deploy, but whether it can do anything else while it does.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Guide to NHI Rotation Challenges

What this signals

Ephemeral credential trust debt: CI/CD programmes that leave service accounts permanently elevated accumulate risk every time a build succeeds. The governance issue is not whether the pipeline can function, but whether each permission grant has an end state.

The operational signal to watch is whether access reviews are still being asked to govern identities that should never have stayed privileged between runs. In CI/CD, the cleaner control point is issuance and expiry, not periodic cleanup after the fact.

Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That level of visibility gap makes it difficult to prove that pipeline permissions are truly task-scoped.

For practitioners

• Define pipeline-specific baseline roles Start every GitLab service account with the smallest role that allows the build to begin, then separate read, compute, and write steps so only the write step can request elevation.
• Use time-bound elevation for write actions Grant temporary permissions only for the exact build step that needs them, and set the expiry so the identity returns to its original state automatically.
• Record approvals and expiry events Keep an auditable trail for every privilege change, including who approved it, what scope was granted, and when the access window closed.
• Re-run failed write steps after elevation Design pipelines so a failed write step triggers a new access request rather than leaving the service account permanently over-privileged.
• Review all always-on cloud roles used by CI/CD Inventory GitLab, GitHub Actions, and Jenkins identities that can write to buckets, assume roles, or modify infrastructure outside a narrow job scope.

Key takeaways

• CI/CD service accounts become a governance problem when they keep broad permissions after the build step they were created for.
• The demo shows a read-only pipeline failing on write, then succeeding after a five-minute approval window, which is the right control shape for temporary machine elevation.
• The deciding control is not whether a service account can elevate, but whether its extra authority disappears automatically when the task is done.

Key terms

• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Privilege elevation: Privilege elevation is the process of granting an identity higher permissions for a specific task or time period. In a secure programme, it should be deliberate, bounded, and separately verified so that standard access does not quietly expand into broad administrative control.

What's in the full article

P0 Security's full video covers the operational detail this post intentionally leaves for the source:

• The exact GitLab pipeline sequence used to demonstrate read-only access, failed write access, and temporary elevation
• The approval flow for granting five minutes of elevated storage.objectCreator access to the service account
• The automatic permission reversion that returns the identity to storage.objectViewer after the time window expires
• The live rerun of the build after elevation, showing how the write step succeeds only inside the approved window

👉 P0 Security's full video shows the GitLab pipeline sequence, approval window, and automatic permission rollback.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.