Introduction
When teams talk about access control, they almost always mean human access. Who can log into the console, who can reach the database, who can touch production. The entire vocabulary — users, approvers, sessions, sign-in — is built around people. And while the industry has spent years getting better at governing human access through SSO, least privilege, and just-in-time grants, a second population of identities has grown up almost entirely ungoverned alongside it.
Those are the non-human identities: the CI/CD pipelines, service accounts, Lambda functions, container workloads, and increasingly the AI agents and internal products that act in your cloud without a person behind each action. They authenticate, they hold permissions, they do work. And unlike human access — which at least gets reviewed when someone joins, moves, or leaves — non-human identities tend to be created once, granted broad permissions “to make it work,” and then never looked at again.
This is the next frontier of the standing-access problem, and it’s arguably worse than the human version, because the credentials are permanent by design, the review cadence is zero, and the blast radius is often enormous. This post makes the case for treating non-human identities as first-class access citizens — and shows how the same just-in-time discipline you apply to people applies to machines.
Why Non-Human Identities Are the Harder Problem
Human standing access is bad, but it has natural checks. People leave the company and get deprovisioned. Access reviews, however imperfect, periodically ask “should this person still have this?” Humans forget credentials, change roles, go on vacation — there’s churn that occasionally surfaces stale access.
Non-human identities have none of that. Consider how a service account’s permissions typically evolve:
- A pipeline needs to deploy an artifact, so it gets a permission to write to one storage location.
- Next quarter it needs to update a service, so a deployment permission is added.
- Then it needs to read a secret, then touch another resource, then another.
- Each addition is reasonable in isolation. Nobody ever removes anything, because removal is risky and the pipeline “works.”
The end state is a non-human identity with broad standing permissions, holding long-lived credentials, that no human reviews because no human owns its day-to-day behaviour. It is the “temporary became permanent” problem from human access, except the credential was never meant to be temporary and there’s no joiner-mover-leaver process to ever catch it.
And the blast radius is severe. A pipeline’s credentials, if leaked, hand an attacker exactly the broad, standing, production-capable access the pipeline accumulated. A leaked human credential is dangerous; a leaked pipeline credential is often catastrophic, because pipelines are built to change production and tend to be over-permissioned to avoid breakage.
The Three Categories Worth Governing
“Non-human identity” is a broad bucket. In practice, three categories matter most for access governance, and each has a distinct shape.
CI/CD pipelines and build systems. These are the classic over-permissioned machine identities. A central build system that deploys to many services tends to accumulate the union of every permission any deployment ever needed — and holds it 24/7, even though it only deploys for a few minutes at a time. The mismatch between when it needs the access (briefly, during a deploy) and when it holds the access (always) is enormous.
Service accounts and workloads. Lambda functions, container workloads, and standing service accounts that call cloud APIs as part of normal operation. These are often necessary, but their permissions sprawl the same way pipelines’ do, and they’re even easier to forget because they’re embedded in running infrastructure rather than visible in a pipeline config.
The products and agents you build. This is the category teams least expect to govern. When you ship an internal product, platform, or AI agent that acts in the cloud, it needs machine identity and permissions — and it’s easy to grant it standing access during development and never revisit it. A newly built internal product that automates work across accounts is a non-human identity with real reach, created by your own team, often with the broad permissions that made development convenient. If you build things that act in your cloud, you are manufacturing non-human identities, and they deserve the same scrutiny as the ones your vendors ship.
The Core Insight: Machines Don’t Need Standing Access Either
Here’s the reframe that makes the whole problem tractable. The reason humans don’t need standing access is that they only use access intermittently — so access that exists only when they’re using it is sufficient. Exactly the same is true of machines, and often more so.
A pipeline that deploys for three minutes doesn’t need deployment permissions for the other 1,437 minutes of the day. A service account that performs a specific operation on a schedule doesn’t need its permissions between runs. An agent that acts in bursts doesn’t need standing credentials between actions. The intermittent-use property that justifies just-in-time access for humans applies even more cleanly to machines, because machine behaviour is often more predictable and bursty than human behaviour.
So the question “how do we govern non-human identities?” has the same answer as the human version: don’t give them standing access. Give them access when they act, scoped to what they’re doing, and take it away immediately after. The lifecycle is identical — request (or trigger), elevate, act, auto-revoke — just initiated by code instead of a person.
What JIT for Non-Human Identities Looks Like
Applying just-in-time access to machines looks different in mechanism from the human flow (there’s no Slack button for a Lambda function), but it follows the same principle. A few patterns:
Register the identity once, elevate per action. Instead of a pipeline holding standing permissions, the pipeline is registered as a known non-human identity, and a short SDK or CI-library call elevates it to the permissions it needs for the specific step, then revokes immediately after the step completes. The pipeline’s resting state is near-zero privilege; it reaches up for permission only during the operation that needs it. Agentic JIT is built for exactly this: seconds-level elevation for CI/CD and workloads with no standing credentials in between.
Scope the elevation to the operation. A deploy step elevates to deploy permissions, not to everything the pipeline has ever needed. The elevation is as narrow as the action, so even during the brief window the credential is live, its reach is bounded. A leaked credential mid-deploy exposes only the deploy-scoped permission, not the full historical union.
Audit the machine like you audit the human. Every elevation is recorded: which non-human identity, which operation, what scope, when it elevated, when it revoked. This gives you something you almost never have for service accounts today — an actual access history, per action, that you can review and that an incident investigation can use.
Extend it to AI and coding agents. AI coding agents are the newest non-human identity, and they’re especially risky because they can take a wide range of actions and are driven by prompts rather than fixed code. The same discipline applies: an agent gets credentials minted and scoped for a specific task, with the credential destroyed afterward, rather than holding a standing key. Keeping a human in the loop for sensitive elevations makes this safe to adopt without slowing the agent down for routine work.
The Objection: “This Will Break Our Pipelines”
The most common pushback on governing non-human identities is operational fear: our pipelines work today, and anything that changes how they authenticate risks breaking deploys. It’s a legitimate concern — a broken pipeline is a bad day — but it’s the same fear that kept human standing access in place for years, and it has the same answer.
The transition doesn’t have to be a cliff. You identify the non-human identity’s actual required permissions per operation (which you should know anyway, and if you don’t, that ignorance is itself the finding). You introduce per-action elevation for one operation, verify it works, and expand. The pipeline’s behaviour doesn’t change — it still deploys the same way — only its resting privilege changes, from standing-broad to near-zero-with-just-in-time-elevation. Done incrementally, the risk is contained and the payoff is immediate: the single most over-permissioned, most-likely-to-leak identity in your environment stops being a 24/7 standing liability.
A Place to Start: Find Your Most Over-Permissioned Machine
If the non-human identity problem feels too large to tackle — and in a mature estate it can involve hundreds of service accounts and pipelines — there’s a pragmatic entry point that delivers outsized risk reduction: find the single most over-permissioned machine identity and govern that one first.
In most environments, it’s the central build or deploy system. It tends to be the identity that accumulated the broadest permissions (because it touches the most things), holds the longest-lived credentials (because rotating them risks breaking deploys), and has the worst blast radius if leaked (because it’s built to change production). It is, in other words, the identity where “standing, broad, production-capable, un-reviewed credential” is most completely true. Governing it is where the first unit of effort buys the most risk reduction.
The approach is incremental and low-drama. Enumerate the operations the build system actually performs — deploy to this service, write to that artifact store, read this secret — which you should be able to reconstruct from its pipeline definitions. For each operation, identify the narrow permission it genuinely needs. Then introduce per-action elevation for one operation: the pipeline, instead of carrying that permission permanently, elevates to it for the duration of that step and drops it immediately after. Verify the deploy still works. Expand to the next operation. Over a few iterations, the build system’s resting privilege collapses from “the union of everything it ever needed” to “nearly nothing, with just-in-time elevation per step.”
You don’t have to boil the ocean. One governed build system is a materially smaller attack surface than before, and it proves the pattern for the rest of your non-human identities. Starting with the worst offender means the first visible win is also the most valuable one.
The Compliance Angle Nobody Mentions
There’s a quiet compliance dimension to non-human identities that tends to go unaddressed until an audit forces it. Access-review requirements — the periodic “confirm who has access and why” that frameworks like SOC 2 and ISO 27001 expect — are almost always implemented as reviews of human access. The service accounts and pipelines sit outside the review entirely, not because anyone decided they should, but because the review process was built around people.
An auditor who asks the sharper question — “show me the review of your non-human identities’ standing permissions” — frequently gets silence, because that review doesn’t exist. The machine identities have standing access that no process ever revisits, which is precisely the kind of unreviewed standing privilege that frameworks are trying to eliminate. Governing non-human identities with just-in-time elevation changes the answer: when a pipeline holds near-zero resting privilege and elevates per action, the “standing permissions review” for that identity becomes trivial — there’s little standing to review — and the per-action elevations are logged and auditable. You turn an uncomfortable audit gap into a clean story, and you do it by removing the standing access rather than by documenting it more thoroughly.
Why This Belongs in Your Access Strategy Now
Non-human identities are growing faster than human ones. Every new service, pipeline, workload, and agent adds to the population, and the trend lines are steepening as teams adopt automation and AI. If your access strategy governs humans rigorously and machines not at all, you’ve secured the smaller and slower-growing half of your identity surface while leaving the larger, faster-growing, higher-blast-radius half untouched.
The good news is that you don’t need a separate philosophy for machines. The just-in-time principle — access exists only when it’s being used — is identity-agnostic. It works for the engineer requesting console access from Slack and for the pipeline elevating for a deploy step, because both are intermittent actors that don’t need standing privilege. Treating them under one model, with one audit trail, is what turns “we govern access” from a half-truth about humans into a complete statement about everything that acts in your cloud.
Conclusion
The access-control conversation has been human-centric for so long that non-human identities became a blind spot — permanent credentials, zero review, enormous reach, hiding in plain sight inside your pipelines, service accounts, and the products you build. They are the standing-access problem in its purest and most dangerous form, and they’re multiplying.
The fix isn’t new; it’s the discipline you already believe in, extended to a population you’ve been ignoring. Machines don’t need standing access any more than humans do. Register the identity, elevate per action, scope it to the operation, revoke immediately, and audit every elevation. Apply that to your pipelines, your workloads, and the agents and products you ship, and you close the half of your identity surface that was quietly becoming your biggest risk. The engine that does this for people — just-in-time access — is the same engine that does it for machines.
