Identity for AI Agents: Non-Human IAM Guide

For a decade, identity and access management meant one thing: humans. A person logs in, completes MFA, receives a session, and acts within their roles until they log out. AI agents invert that model. The principals that now touch your most sensitive systems are non-human — they authenticate without a browser, fire thousands of calls a minute, spawn in parallel, and never log out. Identity for AI has to be rebuilt around those non-human principals first: ephemeral, narrowly scoped credentials that rotate automatically and contain the blast radius when one is compromised. Human IAM — SSO, MFA, SCIM, RBAC — does not go away; it becomes the layer that governs the people who provision and supervise the agents. This guide covers both, non-human identity first.

Non-human identity is not a single control — it is a lifecycle. Praesidia manages it end to end today: discovery of every agent as a first-class principal → JIT ephemeral credentials by default (long-lived static secrets are deprecated for new agents) → zero-downtime rotation with a grace window → per-region vaulting on a Vault Transit substrate with per-region BYOK KMS → single-agent revocation that contains blast radius to one agent. Each of those stages is shipped and live; the sections below explain the model and how Praesidia implements it.

Why AI Changes IAM

Traditional IAM was designed around a simple model: a human authenticates once per session, receives a set of roles, and acts within those roles until they log out. AI agents break almost every assumption in that model.

Non-interactive authentication. Agents cannot complete a browser-based OAuth flow or tap a TOTP app. Their credentials must be issued ahead of time, stored securely, and rotated programmatically.

High call volume and blast radius. A single workflow can trigger thousands of downstream API calls in seconds. A compromised agent credential therefore poses a larger blast radius than a compromised human credential: the agent never sleeps, never hesitates, and has no social cues that betray unusual behavior.

Opaque and delegated intent. When a human calls an API it is usually clear what they intended. When an agent calls the same API on behalf of a user, on behalf of a workflow, on behalf of another agent, the chain of delegation needs to be captured and auditable.

Ephemeral and parallel identity. A fleet of ten agents running in parallel may share a logical identity but need distinct runtime credentials so that one compromised instance does not poison the rest. Ephemeral, narrow credentials per task run are the right model; long-lived shared secrets are not.

These differences mean non-human identity is the new center of gravity, not an add-on. You still need SSO, directory sync, MFA, and RBAC — but now to govern the humans who configure and operate agents. The primary identity problem is the agents themselves, so that is where this guide starts.

Non-Human Identity: The Estate Around the Agents

Agents are the fastest-growing class of non-human identity (NHI) — but they arrive into estates already crowded with service accounts, API keys, OAuth clients, certificates, and workload identities, typically ten to fifty NHIs for every human identity. The chronic failures of that population are well documented: anonymity (nobody knows what a credential is for, so nobody revokes it), over-scope (broad grants that never narrow), and immortality (no expiry, no owner, no end). Agent identity programs that ignore the surrounding NHI estate inherit its habits.

The discipline that works is lifecycle management: every NHI provisioned with an owner, purpose, and review date; scoped to minimum permissions, preferably via short-lived token exchange; rotated automatically; monitored with attribution and inactivity detection; and decommissioned with verified revocation. The full playbook is in NHI credential lifecycle management, and the definitional grounding in the non-human identity glossary entry.

Machine vs Workload vs Agent Identity

Three terms in this space get conflated, and the distinctions carry architecture. Machine identity authenticates devices and hosts — certificates and hardware-backed keys securing the substrate. Workload identity authenticates running software units via platform attestation exchanged for short-lived credentials — the "no secrets in code" layer, built on the assumption that code behavior is deterministic. Agent identity exists because that assumption breaks: an agent's behavior is shaped by manipulable inputs, so identity must carry per-action authorization, delegation semantics, behavioral trust, and instant revocation — properties neither lower layer provides.

The three compose as a stack — the agent runs as a workload on a machine — and the common architectural mistake is letting agents borrow the workload layer's identity, which recreates shared-service-account problems one level up. The full comparison is in machine vs workload vs agent identity.

Continuous Authorization

The authorization model that matches agent reality is continuous: permissions re-evaluated at each action against current policy, current trust, and current task context, rather than checked once at session start. Long-running sessions, mid-run goal manipulation, and delegation chains all defeat point-in-time grants — the failure OWASP tracks as ASI03 (privilege abuse) in its Agentic Top 10. Continuous authorization makes revocation take effect on the next action, makes stale privilege fail closed, and pairs naturally with the scoped capability tokens and trust-gated dispatch described earlier in this guide. The mechanics and the latency-management patterns are covered in agent privilege abuse and continuous authorization, with the concept anchored in the continuous authorization glossary entry.

Agent Identity: Credentials for Non-Human Principals

An AI agent executing code, calling APIs, and reading sensitive data is a principal in your environment just as a human user is. It requires credentials, scopes, trust evaluation, and revocation paths no less rigorous than those you apply to people — and several properties human credentials do not require.

Client ID and Client Secret

The baseline agent identity model uses a client ID (a stable, non-secret identifier) and a client secret (a random, high-entropy value stored as a hash on the platform side). The secret is presented as a bearer credential; the platform verifies it against the stored hash using a timing-safe comparison.

The client secret must be rotatable without downtime. Praesidia rotates it through a grace window where both the old and new secret are accepted for a bounded overlap: you mint the new secret, roll it out to running instances, and the old secret is retired once the window closes — no hard cutover, no dropped requests. The secret lives in the agent's runtime environment — an environment variable or secrets manager — never in source code or version-controlled configuration.

Scoped Capability Tokens

For downstream system access, the preferred pattern is a capability token: a short-lived JWT issued by the control plane that encodes exactly what the agent is permitted to do for the current task. The token carries the issuing organization (iss), the intended audience — the downstream service (aud), the permitted scope, a short expiration (minutes, not hours), and the task run ID for audit correlation.

The downstream service validates the token signature and the aud claim before acting. If the token is intercepted, it cannot be used against a different service and expires quickly. This is how non-human identity works in Praesidia today: ephemeral, just-in-time credentials minted per task rather than long-lived secrets held for the life of the agent. It is the default, not an aspiration — new agents are provisioned JIT-first, and long-lived static credentials are deprecated as a default issuance mode. Narrow scopes, short lifetimes, and per-task issuance are what keep blast radius small as your fleet grows.

A2A (Agent-to-Agent) Authentication

When one agent delegates to another, the authentication chain needs to be explicit. The orchestrating agent should present its own identity plus evidence of the original user or workflow that initiated the chain. Without this, a compromised low-trust downstream agent can impersonate the orchestrator. OAuth 2.0 Token Exchange (RFC 8693) provides a vocabulary for this; the practical minimum is recording the full delegation chain in the audit log so that any action can be traced back to its origin.

Credential Vaulting and Per-Region BYOK

Agent secrets and the provider keys agents depend on have to live somewhere. Storing them in application config or a plaintext column is the failure mode that turns one leaked database into a fleet-wide compromise. Praesidia vaults credential material on a Vault Transit substrate — the encryption keys never leave the vault, and the platform sends plaintext in to be encrypted and ciphertext in to be decrypted rather than handling raw key material itself.

For regulated and multi-region deployments, vaulting is backed by per-region bring-your-own-key (BYOK) KMS: each region encrypts under a key you own and control in that region, so residency and key custody are honored at the storage layer, not just promised in a policy. Combined with per-task JIT issuance, this means the highest-value secrets spend the least time in existence and are protected by keys you hold even while they do.

Trust Scoring: Dynamic Authorization for Agents

Static credentials and roles are necessary but not sufficient. An agent that has been behaving erratically or triggering compliance violations should face additional scrutiny even if its credentials are technically valid. Trust scoring produces a continuous value that reflects the agent's current trustworthiness, feeding a dispatch gate that can allow, escalate, or block the next task.

Trust Score Components

A well-designed trust score aggregates multiple signals:

• Identity verification: is the credential valid, unexpired, and from an expected network location?
• Behavioral history: has this agent recently produced outputs that were flagged or violated guardrails?
• Compliance posture: is the agent running an approved version with current security attestations?
• Cryptographic attestations: signed third-party assessments contribute positive or negative score weight, verified against a registered trust root.

Each component is weighted and combined into a score (commonly 0–100) that maps to a trust level — Untrusted, Provisional, Standard, Elevated, or Trusted. Attestations carry an expiration so that stale evidence does not calcify the score.

Trust as a Dispatch Gate

The trust score is only useful if enforced at dispatch time. A mature architecture evaluates trust at three points: a connection-level minimum (agents below the threshold cannot use the connection), a policy-level gate for classes of operations, and an org-wide floor below which no agent receives tasks. All three gates evaluate the current score at dispatch time, not at credential issuance time, so that a trust collapse takes effect immediately.

Human Identity: Governing the People Who Manage Agents

Non-human identity is the headline, but it rests on a foundation of trustworthy human identity. Before an organization can trust its AI agents, it must have reliable, verified identity for the humans who provision, configure, and supervise those agents. Weak human authentication is the most common entry point for attacks on AI infrastructure — the agents are only as trustworthy as the operators who hold their keys.

Password-Based Login and Brute-Force Defense

Email-and-password login remains the baseline for many teams. The minimum bar for production use is bcrypt or Argon2 password hashing, per-account failed-attempt tracking backed by a fast store (Redis is the standard choice), exponential back-off or temporary lockout after a threshold of failures, and a reset flow that issues short-lived, single-use tokens delivered over a verified channel.

Equally important is a re-authentication gate for sensitive mutations. Changing an SSO configuration, rotating an API key, or modifying an organization-wide security policy should require a fresh credential confirmation even when the user already holds a valid session.

Multi-Factor Authentication

MFA is the single highest-ROI security control for human accounts. Time-based one-time passwords (TOTP) via an authenticator app are the practical minimum; FIDO2/WebAuthn passkeys are the phishing-resistant ceiling to aim for. The enrollment flow matters as much as the verification step: users who reach a sensitive action before completing enrollment should be routed through enrollment, not silently skipped. Organizations that mandate MFA across all members should be able to enforce that mandate at the platform level.

Session management rounds out the picture: active sessions should be enumerable by the user, revocable individually, and automatically expired according to the organization's configured timeout.

Per-Organization Security Policy

Enterprise deployments need security controls scoped to each tenant, not just global defaults:

• Session timeout: maximum lifetime of an issued JWT or session token for users in this org.
• Password complexity: minimum length, character classes, maximum age.
• Password history: prevent reuse of the last N passwords.
• MFA mandate: require MFA enrollment before granting access to any org resource.
• Account lockout: failed-attempt threshold and lockout duration specific to this org.

These controls must be enforced at authentication time, not merely advisory. A policy that is stored but not checked creates a false impression of security.

Single Sign-On: SAML and OIDC

For organizations with an existing identity provider — Okta, Microsoft Entra ID, Google Workspace, or any compliant IdP — single sign-on eliminates password management burden and centralizes authentication in the authoritative directory. This governs the humans who manage agents; it is not the mechanism by which agents themselves authenticate.

Protocol Choice

SAML 2.0 is the established enterprise standard. It uses XML-based assertions signed by the IdP and consumed by the service provider. SP-initiated POST binding is the most common flow: the SP generates an AuthnRequest, the browser navigates to the IdP, and the IdP POSTs a signed SAMLResponse to the SP's Assertion Consumer Service URL.

OIDC (OpenID Connect) is the modern successor. It runs over OAuth 2.0's Authorization Code flow and exchanges JWTs rather than XML. OIDC is simpler to implement, supports PKCE natively, and integrates better with mobile and SPA patterns. Both protocols converge on the same outcome: the SP receives a verified user identity from the IdP, JIT-provisions the user account if it does not yet exist, and issues its own session.

Security Depth for SSO

SSO is a high-value target — a compromised callback endpoint or forged assertion can bypass all authentication. The non-negotiable requirements are:

• State parameter validation: the OAuth state or SAML RelayState must be an HMAC-signed, single-use nonce bound to the originating request, consumed atomically to prevent replay.
• id_token verification: for OIDC, verify the signature against the IdP's JWKS endpoint, confirm iss, aud, and nonce. Accepting a userinfo response without a verified id_token removes the cryptographic binding.
• Assertion signature verification: for SAML, verify the XML digital signature against the stored IdP certificate. Never accept self-signed certs from the assertion itself.
• SSRF protection: every outbound HTTP call to an IdP-derived URL should pass through a guard that blocks private-range IPs, localhost, and metadata endpoints.
• Config encryption at rest: OIDC client secrets and SAML signing certificates should be stored encrypted (AES-256-GCM), with plaintext only in memory during an active flow.
• Sudo-gated writes: changing the SSO configuration should require re-authentication.

MFA in Federated Flows

A common gap: SSO is enabled, the IdP asserts successful authentication, and the platform issues a session — but the organization's MFA mandate is not applied because "the IdP handles it." This is only safe if you can verify that the IdP actually enforced MFA, typically via the amr claim. If you cannot verify that claim, apply your own MFA challenge after the IdP callback.

SCIM: Automated Directory Provisioning

SSO handles authentication. SCIM (System for Cross-domain Identity Management, RFC 7643/7644) handles the lifecycle: creating accounts when users join, updating attributes when they change roles, and deprovisioning access when they leave.

Without SCIM, deprovisioning is a manual process. Manual deprovisioning is slow, error-prone, and a leading cause of orphaned-account findings in access reviews. SCIM eliminates the gap by letting your IdP drive account state in near-real time.

How SCIM Works

Your IdP acts as the SCIM provisioner, sending standard HTTP requests to a /scim/v2 base URL using a bearer token:

• POST /Users — provision a new account.
• PUT /Users/:id or PATCH /Users/:id — update attributes or deactivate.
• DELETE /Users/:id — deprovision (revoke sessions and remove memberships).
• GET/POST/PUT/PATCH/DELETE /Groups — manage groups that map to teams or roles.

The bearer token should be stored as a hash with comparisons using a timing-safe equality function. Brute-force rate limiting on the SCIM endpoint is good practice even though the bearer token is long and random.

Group Mappings and Deprovision Safety

SCIM Groups are a powerful mechanism for role governance. When the IdP provisions a group — say, "Engineering Leads" — the platform maps that group membership to a platform role. Users added to the IdP group automatically receive the associated role; users removed from the group lose it.

Deprovisioning must be complete: remove all organization memberships, revoke all active sessions and refresh tokens, and deactivate the account if this was the user's only organizational membership. Partial deprovisioning — removing the membership but leaving an active refresh token — is a security gap.

SCIM Tenant Isolation

In a multi-tenant platform, a SCIM bearer token for Organization A must not be usable against Organization B's user records, even if the same user exists in both orgs. The bearer token must be bound to a specific organizationId, and every SCIM operation must verify that the target resource belongs to the authenticated org.

RBAC: Roles, Permissions, and Least Privilege

Authentication answers "who are you." Authorization answers "what are you allowed to do." Role-based access control (RBAC) is the dominant authorization model for multi-tenant platforms because it scales administrative burden logarithmically: you manage N roles instead of N×M user-permission pairs.

Built-In Roles

Most platforms ship a fixed role hierarchy to cover the common cases:

Built-in roles are a pragmatic starting point but are coarse: an "Owner" gets everything, which violates least privilege for operators who only need one or two elevated capabilities.

Custom Roles and Fine-Grained Permissions

Enterprise deployments need custom roles: named bundles of granular permissions that can be created and assigned independently of the built-in hierarchy. A useful permission model defines permissions as a centralized enum so every route guard references the same vocabulary, groups permissions by functional category for discoverability, and prevents privilege escalation — a user should not be able to create a custom role that exceeds their own permissions.

Team-Scoped Access and Effective Permission Resolution

Organization-wide roles are insufficient for most real deployments. Team roles — with member/owner/admin semantics scoped to a specific team — let you enforce data separation without creating separate organizations. Team memberships should be manageable both manually and automatically via SCIM group mappings.

When a user has multiple roles, the platform must aggregate effective permissions correctly in the guard layer, not in application logic, so it cannot be bypassed by a creative API call.

Credential Revocation and the Revocation Gap

Revocation is the closing bracket of any IAM system. Credentials that cannot be revoked create permanent liability — and for non-human principals that never sleep, an un-revocable credential is an open door.

Agent Credential Revocation

Agent credentials must be revocable immediately, and revocation has to be surgical: killing one compromised agent should not take the rest of the fleet offline. Praesidia supports single-agent revocation with blast-radius containment — invalidating one agent's client secret and all capability tokens issued under its identity takes effect on the next request, cancels its in-flight tasks, and leaves every other agent untouched. The blast radius of a compromised credential is one agent, not the whole fleet. This is also where short-lived, scoped credentials pay off: the shorter the lifetime, the smaller the window an attacker has even before an explicit revocation lands.

The JWT Revocation Problem

JWTs are stateless by design: any valid signature is accepted without a database lookup. The practical solutions are short expiration (access tokens with a 15-minute lifetime limit exploitation windows), a deny-list of revoked token identifiers (jti claim) checked in a fast store on every request, and stateful refresh token revocation — revoking the refresh token terminates the ability to obtain new access tokens while the short-lived access token expires naturally.

SCIM-Driven Revocation

The most reliable human revocation path is SCIM deprovision. When an employee leaves, the IdP sends a SCIM event, the platform revokes all sessions, and access ends within the SCIM sync interval — typically minutes. This is far better than the days-long lag of manual deprovisioning.

Audit Logging and Access Reviews

IAM controls are only as useful as your ability to verify that they are working. Audit logging and access reviews close the loop.

Every authentication event — success, failure, MFA challenge, SSO callback, password reset, session creation, revocation — should be appended to an immutable audit log with: UTC timestamp, actor identity, event type and outcome, IP address and user-agent, organization and resource scope, and a correlation ID for tracing multi-step flows.

For agent actions, extend this with the task run ID, the delegation chain, the trust score at dispatch time, and any guardrail evaluations.

Immutability matters: an audit log that can be silently altered is not an audit log. Practical mechanisms range from append-only database partitions to hash-chaining (each entry includes the hash of the prior entry), making tampering detectable.

Access reviews — confirming that each user's current roles are still appropriate — are easier when roles are derived from directory groups (SCIM-driven), the platform can export current access state in an auditable format, and custom roles carry a clear trail of creation, permissions, and assignments.

Compliance Alignment

The controls covered in this guide directly address all four frameworks. The audit log provides the continuous evidence auditors require for SOC 2 Type II; the agent identity and attestation mechanisms address the ISO 27001 supplier and cryptography controls; the trust scoring and delegation chain satisfy EU AI Act traceability requirements; and least-privilege capability tokens enable GDPR access minimization.

Common questions

What is the difference between a human IAM system and an AI agent identity system?

Human IAM is designed for interactive principals: a person authenticates via a browser, completes MFA, and receives a session lasting hours or days. Agent identity is designed for non-interactive, high-volume, ephemeral principals: credentials are issued programmatically, often per-task, with narrow scopes and short lifetimes. You need both layers — agent identity for the non-human principals doing the work, human IAM for the operators and administrators who deploy them.

Can I use my existing IdP (Okta, Entra, Google Workspace) to manage agent identities?

Your IdP can manage the human operators who configure and supervise agents. It is generally not the right tool for agent runtime credentials, because agents cannot complete interactive authentication flows. Agent credentials should be issued by the AI control plane, with the control plane itself authenticated to your IdP. Think of it as two layers: your IdP governs humans, the AI control plane governs agents, and SCIM connects them at the user provisioning layer.

How should I handle credential rotation for AI agents without downtime?

The standard pattern is a grace window: issue the new credential, accept both old and new for a bounded overlap period (minutes to hours, depending on your agent restart cadence), then invalidate the old credential once all running instances have picked up the new one. This is exactly how Praesidia rotates agent client secrets today — zero-downtime, no hard cutover. Better still, most rotation leaves the operator's hands entirely: because new agents are issued short-lived, just-in-time credentials per task by default, "rotation" happens automatically as tokens expire.

What does "least privilege" mean for an AI agent?

For an AI agent, least privilege means credentials permit only the specific API calls, data scopes, and downstream system connections required for its declared function. Capability tokens that encode a specific scope and aud are the mechanism; the trust score and policy gates are the enforcement layer.

How do I revoke access for an AI agent immediately after an incident?

Praesidia supports single-agent revocation: revoking one agent's client secret and its capability tokens takes effect on the next request and cancels its in-flight tasks, while every other agent keeps running. The blast radius is contained to the one compromised identity. The revocation event is captured in the audit log with a timestamp so the incident timeline is complete.

How does SCIM deprovisioning interact with AI agent access?

SCIM deprovisioning revokes the human user's sessions, memberships, and any personally-held API keys or agent configurations. If the departing user was the sole owner of agent credentials, those credentials should be transferred or revoked as part of the offboarding workflow. SCIM handles the user's own access; the platform's agent management layer handles the downstream effect on any agents owned or configured by that user.

Putting It Together: A Non-Human-First IAM Architecture

A complete identity architecture for an AI-enabled organization is built non-human-identity-first, with the human IAM stack supporting it. Five layers, with the agents at the center:

1. Non-human identity: client credentials, capability tokens, and A2A authentication give each agent a verified, scoped, revocable identity. New agents default to short-lived, per-task credentials that rotate automatically, vaulted on a Vault Transit substrate with per-region BYOK; long-lived shared secrets are deprecated as a default and treated as the anti-pattern.

2. Trust scoring and dispatch gating: dynamic trust evaluation closes the gap between static authorization and runtime reality. An agent that misbehaves faces reduced trust and blocked dispatch before the next task runs, regardless of whether its credentials have been manually revoked.

3. Directory and federation: your IdP is the source of truth for the humans who provision and supervise agents. SAML or OIDC federates login; SCIM keeps the platform synchronized with the authoritative directory.

4. Human authentication and session management: MFA, per-org security policy, session enumeration, and revocation give operators and administrators confident, auditable access.

5. Authorization: RBAC with team-scoped access and granular permissions governs what each human can do within the platform. Least privilege is the design principle; the permission catalogue and access reviews are the maintenance mechanism.

The weakest link in most implementations is the transition between the human and non-human layers — where human authorization decisions flow down into agent credentials and scopes. Automating that flow, keeping it auditable, and making revocation immediate are the engineering work that distinguishes a mature AI IAM stack from a collection of point solutions.

To explore how Praesidia approaches these layers in a multi-tenant control plane — with a first-class, individually revocable identity for every agent, JIT ephemeral credentials by default, zero-downtime rotation, per-region vaulting, and single-agent blast-radius containment all shipped today — see the platform documentation or explore AI agent security patterns and identity and access practices. For compliance alignment, the AI governance and compliance category covers SOC 2, ISO 27001, and EU AI Act in depth. For cost and budget controls that interact with agent identity, see AI FinOps. For platform operations and deployment patterns, see platform operations and AI strategy. To evaluate your current posture, the AI readiness assessment is a good starting point. Browse the full FAQ for quick answers, or get started directly at app.praesidia.ai.