Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Conversational AI / SaaS Platform |
| Cloud Environment | AWS (primary), Azure, GCP |
| CI/CD | Jenkins |
| Identity Provider | Keycloak (for human SSO) |
| Non-Human Identities | Jenkins pipelines, service accounts |
| Focus Area | JIT for non-human identities (CI/CD) |
The Situation: The Pipelines Had More Standing Access Than the People
This team had started thinking seriously about eliminating standing privilege for their human engineers. But the sharper, less-watched exposure was on the non-human side. Their CI ran on Jenkins, and their pipelines and service accounts held long-lived credentials to reach cloud resources — keys that existed continuously, were rarely reviewed, and in aggregate had broad reach into the environment.
This is the quieter half of the identity problem. Human access at least gets periodic access reviews and offboarding. A Jenkins pipeline’s AWS credentials, by contrast, tend to be set once and left alone — they do not resign, they do not change teams, and nobody gets a calendar reminder to rotate them. They simply persist, which makes them one of the most attractive and least monitored targets in the environment.
The Core Challenge
Non-human identities — Jenkins pipelines and service accounts — held standing, long-lived credentials to cloud resources. These credentials existed whether or not a pipeline was running, were not governed by the same request-and-revoke discipline the team wanted for humans, and represented a persistent, under-reviewed slice of blast radius.
Why Standing Credentials for Machines Are a Distinct Risk
1. A Leaked Pipeline Credential Has the Same Reach at 2 AM as at 2 PM
A long-lived key baked into a pipeline gives whoever holds it the pipeline’s full reach, at any time, with no human in the loop. If that key leaks — through a log, a misconfigured artifact, a compromised build node — an attacker inherits standing access to production resources. The credential does not know it has been stolen; it just keeps working.
2. Non-Human Identities Escape Normal Governance
Access reviews, joiner-mover-leaver processes, and quarterly recertifications are built around people. Service accounts and pipeline identities usually fall outside those rituals. Nobody “offboards” a Jenkins job, so its credentials accumulate and persist indefinitely — ungoverned by design.
3. Broad, Static Scope Because Rotation Is Painful
Because rotating a pipeline credential can break builds, teams often over-provision scope and avoid touching it. The result is a static, broadly-scoped credential that is both more powerful than it needs to be and never refreshed — the opposite of least privilege.
The Cloudanix Approach: JIT for the Machines, Too
Cloudanix extends the same Just-In-Time lifecycle it applies to humans to non-human identities — treating a Jenkins pipeline or service account as an identity that requests scoped, time-bound access and has it revoked automatically, rather than one that holds a permanent key.
Agentic JIT for CI/CD Pipelines
With Agentic JIT, a pipeline or automated process is registered once, and then elevates for the seconds it actually needs access via an SDK or CI-library call — receiving a short-lived, scoped credential that auto-revokes when the task completes. Instead of a Jenkins job holding a standing AWS key, the job requests access at run time, uses it, and the access disappears. There is no permanent credential sitting in the pipeline to leak.
Same Lifecycle as Human Access
The request → approve → time-boxed grant → auto-revoke model is identical to the one applied to human engineers, which means non-human identities are finally governed by the same discipline rather than living in an ungoverned corner. This closes the gap where “temporary became permanent” for machines exactly as it does for people.
Scoped Instead of Broad-and-Static
Because access is granted per-run and time-bound, the pipeline gets only the scope it needs for the task at hand, for the duration of the task — replacing the over-provisioned, never-rotated static credential with least-privilege access that expires on its own. Rotation stops being a scary manual chore because there is no long-lived secret to rotate.
Identity-Stamped Audit for Machine Access
Every elevation is logged against the pipeline or service-account identity, producing an audit trail of exactly which non-human identity accessed what, when, and for how long — the same zero-standing-privilege evidence the team wanted for humans, now covering the machines.
Human JIT on the Same Engine
Because Cloudanix runs human and non-human JIT on one engine — and layers on top of the team’s existing Keycloak SSO for human access without replacing it — the team governs both under one policy model and one audit trail, rather than a separate tool for machine identities.
The Outcome
The team moved Jenkins pipelines and service accounts off standing, long-lived credentials and onto short-lived, scoped, auto-revoking access — extending zero standing privilege from human engineers to the non-human identities that had previously held the most persistent, least-reviewed access in the environment.
Key Results
✅ No Standing Pipeline Keys: Jenkins jobs request access at run time, then it auto-revokes ✅ Machines Governed Like Humans: Same request → grant → revoke lifecycle ✅ Least-Privilege by Default: Scoped, time-bound access instead of broad static credentials ✅ Nothing to Leak: No permanent secret sitting in the pipeline ✅ Identity-Stamped Audit: Every machine elevation tied to its identity ✅ One Engine: Human and non-human JIT under one policy model
Are Your Pipelines Holding Standing Cloud Credentials?
If your Jenkins jobs and service accounts carry long-lived keys that nobody rotates, Cloudanix Agentic JIT gives them short-lived, scoped access that expires on its own — no permanent credential to leak.
Schedule a Demo to see JIT for non-human identities in your CI/CD.
