AI Identity & Criticality Tiers

AI Identity

I think about enterprise identity as three separate planes now, not one. People, AI agents, and APIs/service accounts each authenticate differently, fail differently, and need to be reviewed on a different clock. Most IAM programs were built around the first plane and are only now catching up to the fact that the other two have quietly become the larger population in most environments — machine and agent identities now routinely outnumber human accounts by a wide margin. A framework built for onboarding and offboarding employees doesn't hold up well once you point it at an autonomous agent that spins up, acts, and disappears in minutes.

Identity Plane Overview

Criticality Tier Model

Not every identity deserves the same scrutiny, so I sort all three planes into one shared tier system — a single risk ladder that a human account, an agent, and a service account can all sit on side by side. It's what lets a policy engine treat "how risky is this identity" as one question instead of three separate ones.

A person, an agent, and a service account can all land on the same rung — and the auth control tightens the same way regardless of which of the three planes got them there.

Design Architecture by Identity Plane

👤 People IAM — the plane we already know how to run

Human IAM is mature, but it still needs to be wired into the newer controls below.

• Passkeys over passwords — FIDO2/WebAuthn removes the credential-theft attack surface almost entirely, rather than just making passwords harder to guess.
• One federated identity provider — Entra ID, Okta, or Ping as the hub, with SCIM/OIDC/SAML handling provisioning and de-provisioning automatically instead of by ticket.
• PAM for anything tier T0/T1 — admins and security operators go through a privileged-access vault with recorded sessions and just-in-time elevation, not standing admin rights.
• Step-up auth driven by risk signals — an unfamiliar device, location, or login time should trigger re-authentication automatically rather than waiting for a human to notice.

🤖 AI Agent IAM — the plane the old playbook doesn't cover

Agents are autonomous and short-lived, and permissions can cascade across a chain of sub-agents in ways a static role model was never designed to track.

• Every agent has a named human sponsor — someone accountable for what it's allowed to do and how it behaves. An agent with no owner is a liability, full stop.
• Verifiable credentials instead of long-lived tokens — decentralized identifiers and short-lived, cryptographically verifiable credentials keep a traceable record through multi-agent delegation chains, which a static OAuth token can't provide.
• Govern the action, not just the access grant — a role-based permission list tells you what an agent is allowed to touch, not what sequence of actions it's actually attempting. Runtime policy needs to evaluate intent, not just static scope.
• Keep a bill of materials per agent — what it can reach, what it reads and writes, which tools it can invoke, which model it runs on, and what tier it's been assigned.
• Revocation has to be instant — an agent can act at machine speed, so a kill switch that runs on a nightly batch job is effectively useless.

How those controls typically scale by tier:

🔌 API & Non-Human Identity IAM — the plane nobody's watching

Service accounts and API keys are usually the largest identity population in an environment and, in my experience, the least reviewed — many outlive the project they were created for, and few teams have a real process for retiring them.

• No standing secrets — replace long-lived API keys with short-lived OAuth 2.1 tokens or workload identity federation (GitHub Actions OIDC, AWS IAM Roles Anywhere, and similar).
• CIEM as an ongoing discipline — keep scanning for service accounts with more access than they use, unused grants, and entitlements that have quietly piled up.
• Token exchange for delegated calls — when an agent calls an API on a user's behalf, RFC 8693 token exchange keeps both identities — the human and the agent — visible in the resulting token, so the audit trail doesn't lose the thread.
• Segment the network around agent-facing APIs — so a compromised agent can't use that foothold to reach systems it was never meant to touch.

Zero Trust Principles Across All Tiers

The same "verify, don't assume" posture should apply whether the identity is a person, an agent, or a service account.

• Verify continuously — network location or an existing session shouldn't count as proof of trust on their own.
• Grant the minimum, revoke it fast — access matches the task at hand and disappears the moment the task ends.
• Judge the sequence, not just the request — for agents especially, what matters is the pattern of actions it's taking, not whether any single call was technically permitted.
• Feed identity signals into detection — human and agent behavior baselines belong in the same SIEM/SOAR pipeline, so deviations trigger a response automatically.

Why the Old Standards Don't Cover Agents

OAuth 2.1, SAML, and OIDC assume one entity authenticating at a time, with coarse-grained, relatively long-lived permissions. That model doesn't have a way to represent a chain of delegation across several agents, doesn't handle credentials that need to expire in minutes rather than months, and was never designed for something acting on its own initiative at machine speed. It's less that these standards are broken, and more that they were solving a different problem than the one multi-agent systems now present.

The Cloud Security Alliance's MAESTRO framework, published in 2025, is one of the first serious attempts to model multi-agent threats directly — supply-chain risk in the identity tooling itself, one agent escalating privilege through another, and agents pursuing a subtly wrong goal in ways that abuse otherwise-valid access.

The job has shifted from proving who someone is to accounting for what an identity — human, agent, or machine — actually did, and why.