CIAM.wiki

Non-human and agent identity

For most of CIAM’s history, “identity” meant a person: a customer who signs up, logs in, and consents. That assumption is breaking. The fastest-growing population of identities in a customer-facing system is now non-human: service accounts, API clients, workloads, and increasingly AI agents that act on a user’s behalf. As the Cloud Security Alliance puts it, identity is no longer just about people; it is about machines, workloads, APIs, and agents.

What counts as a non-human identity

A non-human identity (NHI) is any credential that authenticates something other than a person: an OAuth client, an API key, a service account, a workload token, or an autonomous agent. They already outnumber human accounts in most environments, and they are harder to govern. They rarely rotate, often hold standing privilege, and nobody offboards them when the integration that created them is retired. CSA’s State of Non-Human Identity Security survey found only 15% of organizations feel highly confident they can prevent an NHI-based attack, while 69% are concerned about them.

Why this lands in CIAM, not just IT

The CIAM angle is the agent acting for a customer. When a customer connects an AI assistant to your product, or your own app ships an agent that books, buys, or files on the user’s behalf, that agent needs an identity, a scoped token, and a consent trail tied back to the human it represents. That is a customer-identity problem: delegation, scoped authorization, and revocation are exactly the primitives a CIAM platform already owns for enterprise SSO and consent, now applied to a non-human actor. CSA’s Securing Non-Human Identities in the Age of AI Agents work makes the same connection: the hard part is governing what the agent is allowed to do once it holds a credential.

The governance gap

CSA calls unmanaged non-human identity the governance vacuum of the agentic era: agents acquire permissions at runtime, spawn sub-agents, and chain API calls, so one over-privileged token has a far larger blast radius than a static service account. For a CIAM buyer the risk is concrete. An agent issued a long-lived, broadly scoped token on behalf of a customer is a standing liability that no password policy or MFA prompt will catch, because no human is in the loop at use time.

What to ask a CIAM vendor

  • Can you issue scoped, short-lived tokens for machine clients and agents (OAuth client credentials, token exchange / RFC 8693), not just user sessions?
  • How does an agent act on behalf of a customer, with a clear delegation and consent record, and how is that consent revoked?
  • Can a customer or admin see and revoke every non-human credential tied to their account?
  • Do you support least-privilege scoping per agent, or is access all-or-nothing once granted?
  • Is there an audit trail that distinguishes the human, the agent, and the action taken?

Buyer takeaway

Non-human identity is moving from an IT housekeeping problem to a CIAM requirement, because the agent in the loop is now acting for your customer. You do not have to solve it today, but you should know whether a vendor’s roadmap treats agents and machine clients as first-class identities, with scoping, delegation, and revocation, or bolts them on as raw API keys. Ask in the demo; the gap between vendors here is widening fast.

Sources