Your microservices fleet has 3,000 machine identities and 300 employees — a 10:1 ratio that is conservative by industry standards, where surveys regularly report machine identities outnumbering humans by 45:1 or more. Service accounts, API keys, OAuth tokens, CI/CD pipeline identities, workload certificates: none of them can use MFA, none of them log out, and almost none of them get retired when the workload that used them goes away.
AI agents make this problem sharply worse. Every agent you deploy is a credential-bearing actor that can reason about its own access needs, request permissions, and chain actions across systems its operators never explicitly anticipated. A single agent token may unlock a dozen downstream services, and when the agent is decommissioned, the credential often lives on. This post walks through what non-human identity (NHI) governance actually requires in practice: inventory, ownership, least privilege, short lifetimes, and monitoring — and how each one changes when the identity belongs to an autonomous agent. The Cloud Security Alliance’s agentic identity research calls the resulting gap a governance vacuum; you do not need their report to see it in your own infrastructure.
Why non-human credentials are the soft underbelly
Stolen credentials remain the most common initial access vector in breach reports, year after year. Human credentials are at least defended by MFA, conditional access policies, and users who notice weird login prompts. Non-human credentials have none of that. They authenticate silently, run with standing privileges that no human account would ever be granted, and are frequently hardcoded, committed to version control, or passed through environment variables that end up in build logs.
The scale problem compounds it. Every microservice, every background worker, every integration, every CI pipeline, every container needs its own credentials. Automation created identities faster than any governance process could track them. The result is a large population of orphaned, overprivileged credentials that nobody owns — invisible until they appear in an incident timeline.
What counts as a non-human identity
The taxonomy is broader than most teams assume:
- Service accounts in directory services
- API keys and bearer tokens for REST and GraphQL integrations
- OAuth 2.0 access and refresh tokens
- Cloud IAM roles assumed by workloads
- Machine TLS certificates issued to servers and containers
- CI/CD pipeline identities
- Secrets issued to or acquired by AI agents and multi-agent orchestrators
The last category is the newest and least governed. Legacy identity systems — OAuth, SAML, directory services — were designed for static identities with predictable lifecycles. Agents are dynamic: they may spawn sub-agents, request new scopes mid-task, and act across system boundaries in sequences that produce emergent behavior. The credential an agent holds is not just a key; it is the principal identity of an actor whose future behavior is not fully knowable at issuance time.
The lifecycle problem: the agent is gone, the credential is not
The most damaging pattern in NHI security is credential persistence. A service gets deprecated, an agent gets decommissioned, a pipeline gets deleted — and its credentials remain valid. This is persistent blast radius: credentials that outlive their operational context and remain exploitable indefinitely. Attackers actively hunt for exactly these orphans, because they come with no owner to notice the abuse.
Response speed makes it worse. In most organizations, responding to a credential exposure is still a manual process measured in hours or days. Against an attacker operating at machine speed, that response window is orders of magnitude too slow. By the time the ticket is triaged, the token has already been used.
The governance baseline that actually works
The controls here are not exotic. They are the same discipline you apply to service accounts — enforced everywhere, including agents:
- Continuous inventory. You cannot secure what you cannot see. Automated discovery must map machine identities across cloud and hybrid environments in real time, including the ones created by developer scripts three months ago.
- A named human owner for every credential. Not a team alias. If a credential has no owner, it is an orphan, and orphans get revoked.
- Least privilege per task. Scope each credential to the minimum access its task requires. A read-only reporting agent does not need write access to your production database.
- Short lifetimes and automated rotation. Long-lived static keys are the single biggest risk factor. Prefer workload identity federation or short-lived tokens where the platform supports them.
- Pre-authorized revocation. The revocation runbook must exist before the incident, and the ability to revoke must not require human approval loops measured in hours.
- Behavioral monitoring. Baseline what each identity normally does and alert on deviation — an agent suddenly reading a different data store is a signal, not noise.
What changes for AI agents specifically
Agents stress every one of those controls harder than a normal workload. Three adjustments matter most in practice.
1. Zero standing privilege
Surveys of identity security posture consistently show organizations relying on long-lived credentials far more often than just-in-time authorization. Agents make that trade indefensible. An agent should request elevated access at task start, hold it for the duration of the task, and lose it automatically at task end. If your identity infrastructure cannot express “grant this scope for 20 minutes to this specific task run,” agents will end up with standing access — and standing access plus autonomy equals unbounded blast radius.
2. Scope the agent, not just the deployment
A deployment-level service account shared by every agent instance means one compromised instance compromises all of them. Give each agent — ideally each task run — its own identity. This is more credentials, not fewer, which is why inventory automation has to come first. Per-task identities turn “which agent did this?” from an archaeology project into a log query.
3. Verify on every hop
Multi-agent orchestration introduces delegation chains: agent A calls agent B, which calls agent C. A common failure is trusting the upstream hop — B assumes that because A authenticated, C can trust B. The zero-trust principle applies here literally: NIST SP 800-207 makes no exception for machine callers. Every system in the chain should independently verify the identity and current authorization on every request rather than inheriting trust from the previous hop. Delegation tokens that carry the original caller’s identity plus the chain of intermediaries make this auditable after the fact.
A practical starting checklist
If you are deploying your first production agents this quarter, sequence the work like this:
- Enumerate every non-human credential in your environment. Assign an owner or schedule it for revocation.
- Delete or expire every credential whose workload no longer exists. This single step collapses the persistent blast radius.
- Move agents to short-lived, per-task credentials before scaling the fleet — retrofitting identity later means migrating hundreds of hardcoded keys.
- Wire revocation automation into your incident tooling and rehearse it. Target minutes, not days.
- Baseline agent behavior and alert on anomalous access patterns, especially reads of data stores outside the agent’s task scope.
None of this requires new infrastructure so much as consistent enforcement. The teams that struggle are the ones that treat agent credentials as a configuration detail to clean up later. Treat each agent as a first-class principal with a lifecycle, an owner, and a scope, and the rest of the governance model falls into place.
Wrapping up
Non-human identities already outnumber human ones by orders of magnitude, and AI agents are the fastest-growing, least-governed slice of that population. The fundamentals — inventory, ownership, least privilege, short lifetimes, fast revocation, behavioral monitoring — are unchanged, but agents compress the tolerance for error: standing privilege, shared identities, and slow response that were merely risky for service accounts are genuinely dangerous for autonomous actors. Build the identity controls while the agent fleet is small, because retrofitting them at scale is far more expensive.