Rethinking identity for AI agents and other non-human identities

When a non-human identity such as an AI agent calls your systems, authentication and identity shift from human prompts to machine-centric interactions. 

Non-human identities (NHIs) such as service accounts, workloads, bots, and agents authenticate by relying on policy and attestation rather than MFA credentials and demand short-lived, traceable credentials with full governance. 

AI agents authenticate without people in the loop, often using their own identities, short-lived tokens, and policy decisions made in real time. As AI agents and automation become first-class participants across enterprise systems, identity must shift from MFA to machine-centric verification.

TL;DR

• MFA is not the solution for bots. NHIs are authenticated via non-interactive flows (e.g., OAuth 2.0 client credentials, workload identities) and governed by policy, not push codes.
• Retire static secrets. Prefer federation and short-lived credentials (STS, managed identities, workload identity federation) to minimize blast radius and remove key management toil. 
• Prove software identity. Use attestation + mTLS (SPIFFE/SPIRE) so services prove what they are: code origin and runtime, not just that they hold a token. 
• Govern the lifecycle. Zero Trust requires least privilege, continuous policy, logging, ownership, rotation, and de-provisioning for all identities (human and machine). 

Govern the lifecycle: ownership, least privilege, logging, and de-provisioning

Authentication is just the starting point of identity use. It covers everything from join/move/leave to real-time policy and evidence.

Zero Trust requires per-request authorization, dynamic policy, and continuous monitoring across all identities. For NHIs, that means: assign an owner; scope to least privilege; log every action; set expiries; rotate credentials; and de-provision when projects end. CISA’s ZT Maturity Model and NIST SP 800-207 both frame identity as continuous and policy-driven, not a one-time gate. 

Operational controls to standardize

• Ownership and metadata: owner, purpose, data sensitivity, environment.
• Policy and scopes: minimal roles, JIT elevation where feasible, and per-session decisions. 
• Evidence and audit: API, token, and policy-decision logs tied to NHI identity; automated revocation on risk.

Why MFA doesn’t fit non-human identities

Before deciding “how” to secure bots and agents, clarify “who” is authenticating, and how that differs from a person.

Human MFA assumes an interactive user. NHIs authenticate non-interactively using app credentials or workload identities; applying human prompts (OTP, push, SMS) breaks automation and doesn’t add assurance about software provenance. 

Major platforms explicitly support these app/workload flows (e.g., OAuth 2.0 client credentials for app-only access, and Entra Workload Identities to govern service principals). Zero Trust still applies, but the controls are policy, scope, and attestation, not MFA challenges. 

What this means in practice

• Use app-only flows (client credentials, mTLS) when no human is present. 
• Govern access with scopes/roles and Conditional Access equivalents for workloads (risk, attributes, environment), not human prompts. 
• When an agent acts for a human, issue delegated access tokens via OAuth; APIs are called with access tokens, not ID tokens. (Architectural pattern aligned with Zero Trust session-by-session decisions.) 

Replace static secrets with federation and short-lived credentials

Static keys linger in code and infra, are hard to rotate, and create high-value secrets. Cloud providers offer first-class alternatives: AWS STS for temporary credentials; IAM Roles Anywhere for external workloads to obtain temporary AWS creds via X.509 trust; and Microsoft Entra Workload Identity Federation and Managed Identities to eliminate secret management and mint tokens at runtime. 

These patterns shrink the blast radius and map cleanly to Zero Trust’s “never trust, always verify.” 

What good looks like

• Prefer AssumeRole/STS or managed identities over stored keys. Automate rotation by design because credentials are short-lived. 
• If workloads run outside your primary cloud, use Roles Anywhere (cert-based) or workload federation; add runtime attestation if you need to prove environment integrity. 
• Tag every NHI with owner, purpose, and expiry; deny tokens beyond task scope. (Supports future de-provisioning and audit.)

Prove software identity with attestation, mTLS, and SPIFFE

Short-lived tokens limit time-based risk; proving what is holding the token tackles identity risk at its root.

SPIFFE/SPIRE establish cryptographic workload identity via SVIDs and deliver short-lived, automatically rotatedX.509 credentials for mTLS between services. SPIRE performs node and workload attestation so identities reflect runtime properties (where and how the workload runs). Combined with policy (which service can talk to which), this gives you machine-native assurance far beyond “token possession.” 

Implementation notes

• Use SPIRE or equivalent to issue SVIDs; terminate TLS only where necessary to preserve end-to-end identity. 
• Bind authorization decisions to attested identities plus request context (namespace, image digest, node labels).

In a nutshell

Securing non-human identities means swapping human prompts for automation-native identity: app/workload flows, short-lived credentials, workload attestation + mTLS, and full lifecycle governance. Done well, this reduces standing privilege, shrinks the blast radius, and produces audit-ready evidence that each machine action was both trusted and policy-compliant, exactly what modern Zero Trust guidance prescribes. 

‍