Executive Summary
- Cloning human credentials for AI agents breaks non-repudiation and enterprise audit trails.
- Static service accounts grant overly broad wildcard access across internal microservices.
- Non-Human Identity (NHI) establishes first-class machine credentials tied to specific agent tasks.
- Cryptographic delegation tokens (OIDC / OAuth On-Behalf-Of) preserve the human delegator chain.
- Automated credential expiration ensures compromised agent processes cannot access systems post-task.
The enterprise identity impasse in the agent era
In traditional enterprise IAM (Identity and Access Management), identity falls into two buckets: Human Users (authenticated via Okta, SSO, and MFA) and Service Accounts (static API keys and machine certificates used by automated cron jobs).
Autonomous AI agents break this dichotomy. An agent is neither a human (it cannot respond to interactive MFA push notifications mid-execution) nor a simple cron job (it reasons probabilistically and decides which tools to invoke dynamically).
When engineering teams force agents into legacy IAM buckets, they either clone human session tokens (destroying auditability) or hand the agent superuser service keys (creating extreme security blast radiuses).
The third identity class
Autonomous agents represent a third fundamental class of enterprise identity: Non-Human Identities (NHIs) that act with delegated human authority but require machine-enforced operational constraints.
Why human cloning and service accounts fail
Cloning a human user's session cookie for an agent has catastrophic consequences for compliance. In the event of an erroneous trade or data deletion, the audit log records that 'Alice in Accounting' executed the command, making it impossible to determine whether Alice or an autonomous prompt loop was responsible.
Conversely, assigning a static service account key means the agent operates with identical permissions across all tasks, violating the principle of least privilege.
Non-Human Identity (NHI) solves both problems by issuing ephemeral, task-bound credentials that explicitly record both the human delegator and the agent actor.
Ephemeral agent delegation token TypeScript schema
Below is a TypeScript interface defining an OAuth 2.0 Token Exchange payload for an autonomous agent acting on behalf of a human user.
Structuring On-Behalf-Of (OBO) delegation chains
When Sarah Lin asks an agent to optimize database indexes, the system initiates an OAuth 2.0 Token Exchange (RFC 8693).
The identity provider mints an ephemeral JWT where `sub` is the Agent ID and `act` (the actor claim) records Sarah Lin. When the agent calls the Postgres MCP tool, the database verifies that Sarah possesses authorization to view the schema, while the gateway verifies that the agent is restricted to read-only tools.
This preserves complete cryptographic non-repudiation while preventing lateral privilege escalation.
Lifecycle management, key rotation, and automated revocation
Agent credentials must never be stored on disk. They reside exclusively in memory or secure enclaves (such as HashiCorp Vault or AWS Secrets Manager).
As soon as the agent's task state transitions to `COMPLETED` or `FAILED`, the control plane emits a revocation event to the gateway, invalidating the JWT instantly.
If an agent shows signs of plan drift or abnormal tool calls, the security system revokes the specific NHI token without affecting other running workloads.
Agent IAM readiness checklist
Assess your organization's AI identity architecture against these foundational controls.
Agent identity readiness checklist
1Identity Modeling
- Every autonomous agent has a unique Non-Human Identity (NHI) record
- Human session cookies are never cloned or shared with agent runtimes
- Static service account keys are eliminated in favor of ephemeral tokens
2Delegation & Lifecycles
- On-Behalf-Of (OBO) tokens record both the human principal and agent actor
- Token TTLs are constrained to less than 30 minutes
- Task completion triggers automated cryptographic token invalidation