Non-Human Identities: Securing the Machine Accounts and AI Agents Nobody Owns

In every environment audit we've run in the past year, non-human identities — service accounts, API keys, CI/CD pipeline credentials, and now autonomous AI agents — outnumber human user accounts, often by a wide margin. Almost none of them go through the access review process a human employee's account goes through. That gap is now one of the largest blind spots we find.

Why Non-Human Identities Slip Through Every Existing Process

Identity governance programs were built around the joiner-mover-leaver lifecycle of a human employee: someone starts, changes roles, eventually leaves, and access follows that lifecycle. A service account created by a developer to connect two systems has no HR record, no manager to certify its access in a quarterly review, and often no expiration date at all. It gets created for a specific project, keeps working long after the project ends, and sits there with standing permissions until someone — usually a security audit, not a routine process — notices it.

What's Changed With AI Agents

An AI agent built on Bedrock, Copilot Studio, or a custom framework introduces a new wrinkle: it's not just a static credential, it's an identity that takes autonomous action — calling APIs, reading and writing data, sometimes invoking other agents — based on a model's output rather than a human's direct command in the moment. The permissions scoped to that agent determine the blast radius if the model does something unintended, is prompt-injected, or is compromised. Most organizations are provisioning these agents with far broader access than the use case requires, because narrowly scoping permissions takes real engineering effort and the demo works fine with an admin-level key.

• No inventory. Most organizations cannot produce a complete list of active service accounts, API keys, and agent identities on request — a prerequisite for governing them.
• No owner. A human-employee account has a manager to certify it. A service account or agent frequently has no assigned owner at all once the person who created it leaves.
• No expiration. Static API keys and long-lived tokens routinely have no rotation policy, unlike a human password subject to a rotation or MFA re-enrollment cadence.
• Standing, over-scoped permissions. The path of least resistance during development is broad access; narrowing it later requires effort nobody schedules.

An AI agent with standing write access it doesn't need isn't a hypothetical risk — it's a service account with better marketing, and it inherits every problem service accounts already have.

What a Real Non-Human Identity Program Looks Like

• A complete inventory across cloud IAM, CI/CD systems, and any agent orchestration platform — you can't govern an identity you don't know exists.
• Mandatory ownership assignment at creation time, tied to a team or role rather than an individual who may leave.
• Short-lived credentials by default — favor workload identity federation and temporary STS tokens over long-lived static API keys wherever the platform supports it.
• Least-privilege scoping for agents specifically — an agent should hold only the permissions its defined task set requires, reviewed the way a new application's access would be, not granted admin-level scope for convenience.
• Inclusion in access reviews — non-human identities need the same certification cadence we describe in our access reviews piece, routed to the owning team rather than skipped because there's no obvious human reviewer.