Most CI/CD pipelines run with more access than they need. This quick demo in the Five minutes to zero standing access series shows how to fix that—by using just-in-time access for GitLab service accounts.
Follow a real example where a GCP service account elevates its permissions to write to a GCS bucket—only during a specific build step, and only after approval.
In modern CI/CD workflows, machines deploy code, configure infrastructure, push artifacts, and interact with critical services - all without human intervention. But they often do it with standing permissions that are far broader than necessary.
When non-human identities (NHIs) are permanently over-permissioned, every Git push becomes a potential privilege escalation.
In this demo, we show how P0 enables just-in-time privilege elevation for a machine identity running in a GitLab pipeline - so it gets exactly the access it needs, for just as long as it needs it.
It’s easy to grant a service account “admin” privileges to get a deployment working. It’s harder to come back later and scope that access down. So teams leave it — and over time, CI/CD pipelines become trusted automation running with untrusted levels of access.
This is especially dangerous with GCP service accounts or AWS IAM roles used by GitLab, GitHub Actions, or Jenkins. If they’re compromised or misused, they can write to buckets, reconfigure resources, or leak secrets.
P0 changes the model: machine identities start with minimal access, and only elevate temporarily - with approvals, auditability, and auto-reversion built in.
This video walks through a GitLab CI/CD pipeline using a GCP service account with read-only access to a Google Cloud Storage (GCS) bucket. The pipeline runs three tasks: reading from the bucket, fetching mock data, and writing back to the bucket.
Initially, the write step fails - because the machine identity doesn’t have write privileges. We then show how P0 can grant temporary elevation using a just-in-time access request, approved for a short time window. Once the access is approved, the same pipeline is re-run and completes successfully - including the write step. After the time window expires, permissions are revoked automatically.
Here’s the sequence the video follows:
<<INSERT SCREENSHOT TO VIDEO HERE: and link to XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX>>
Most CI/CD security incidents don’t come from new exploits - they come from over-permissioned automation. Service accounts that can write to any bucket, assume any role, or modify resources long after their original use case is forgotten.
P0 fixes this by shifting permission from “always available” to “available on demand” - and only for as long as needed. Developers and pipelines get what they need to move fast, but security teams stay in control of scope, duration, and context.
There’s no risk of forgetting to revoke. No spreadsheet tracking who changed what. No lingering access in production.
After running the pipeline with elevated access, the write step completes, a new file is created in the GCS bucket, and everything behaves as expected. Then, when the 5-minute window expires, P0 removes the elevated permission and resets the identity to its original state.
The next time the pipeline runs, it will once again fail to write - unless a new request is approved.
That’s what least privilege looks like in action: dynamic, safe, and repeatable.
If your CI/CD pipelines still rely on permanently privileged machine identities, this video demo shows how to decouple delivery speed from security risk - without slowing anything down.
Control and govern privileged access across all identities with P0 Security.
