Blog · AI Governance

AI Agent Identity Management for IAM: 3 Controls, Agentless Proof

AETHER Pulse·14 October 2026·10 min read

AI Agent Identity Management for IAM: 3 Controls, Agentless Proof

Analyst reviewing agent identity audit evidence

Treat AI agents as first-class principals, not static service accounts. Effective AI agent identity management rests on cryptographic per-instance identities, sender-constrained tokens, scoped delegated grants, and immutable audit records. Start with three controls: proof-of-possession tokens such as DPoP, scope attenuation with just-in-time credentials, and signed audit evidence. Build on OAuth 2.0, OIDC, and SPIFFE, then adopt emerging protocols incrementally.


TL;DR:

  • Give every running agent a stable instance ID, link it to an accountable human or system, and record runtime attestation when credentials are issued.
  • Use DPoP or similar proof of possession, with fresh session keys and expiring credentials rather than persistent API keys or bearer tokens.
  • At each delegation hop, narrow scopes, keep credentials behind a server endpoint, automate revocation across descendant grants, and retain delegation records.
  • Store consent, scopes, instance IDs, timestamps, and full delegation chains in hash linked logs, with signed receipts auditors can verify offline.
  • Use a verified agent registry to block delegation when an agent record is missing, expired, or does not list the requested capability.

Table of Contents

What an agent identity must prove

A service account proves that a credential is valid. An agent identity has to prove more: where the agent came from, which instance is acting, and on whose authority. OWASP's agentic security experts make the same split, noting that non-human identities authenticate a credential, while agent identity is a cryptographic, provenance-bearing framework that governs behavior at the time of each action.

Agents are ephemeral. One model may spawn multiple instances, each potentially delegating to sub-agents. Capture these fields for every instance:

  • agent_instance_id: a stable identifier for the running instance
  • agent_platform and agent_model: what the agent runs on and what it is
  • controller or principal linkage: the human or system accountable for it
  • attestation evidence: proof of runtime integrity at issuance

Use a stable instance identifier rather than a key thumbprint. Keys rotate, and a thumbprint that changes with them fractures your audit trail. A stable identifier can help an investigator follow an agent through its activity even when its keys rotate.

Secure discovery and naming for agents

Before an orchestrator hands work to another agent, it should verify who that agent is and what it claims it can do. OWASP's Agent Name Service proposes a DNS-inspired, PKI-backed registry that maps human-readable names to verifiable endpoints and capability metadata, independent of any single agent protocol.

The ANS approach includes formalized registration and renewal processes. An enterprise can use an ANS-style registry to support controlled agent discovery. The specification also describes formalized registration and renewal processes alongside structured agent metadata.

Discovery first matters because it removes blind delegation. A policy decision point can refuse to route a task to an agent whose record is missing, expired, or lacks the declared capability. Teams building registration flows can also review practical notes on agent self-registration APIs and token handling.

Authentication and attestation mechanisms

Authentication for agents should answer two questions: is this runtime what it claims to be, and can the token be stolen and replayed? SPIFFE is among the identity standards NIST identifies as relevant to software agents. NIST's concept paper explicitly lists OAuth, OIDC, SPIFFE, and SCIM among the identity standards to apply to software agents.

Next, surface the instance in the token. The OAuth Client Instance Assertion profile lets a platform mint per-instance identifiers that appear as agent_instance_id, so a resource server can attribute each action to a specific instance rather than a shared client.

Then bind tokens to keys. DPoP and similar proof-of-possession mechanisms constrain a token to its holder. NIST practitioners advise avoiding long-lived API keys and bearer tokens for agents in favor of dynamic, tightly scoped, sender-constrained tokens. Sender-constrained tokens bind token use to a key, helping limit the risk of a stolen token.

Three controls for verifying agent identity

Authorization and delegation without losing control

Agents delegate. A planner agent calls a research agent, which calls a data agent, and authority must narrow at every hop. The draft Credential Delegation Protocol defines operation-bound delegation tokens, credential wrapping, and tamper-evident delegation receipts that make this containable.

Three patterns do most of the work:

  1. Scope attenuation. A sub-agent can receive a narrower set of scopes than its parent.
  2. Credential wrapping. Agents exercise capabilities through a server-side endpoint, so raw credentials stay in the vault and never enter the agent's context.
  3. Delegation records. Keep records of delegation links so the chain can be reviewed.

Delegation protocols can support revocation that propagates to descendant grants. The DAAP draft describes the same multi-agent delegation with cascade revocation, paired with human-consent grants and signed JWT grant tokens. For cross-domain cases, IETF work on authorization information sharing addresses how agents prove identity to resource servers without pre-established central trust.

Lifecycle, provisioning, and revocation

Credential sprawl is the quiet failure mode of agent deployments. The fix is to issue credentials only when needed and let them expire by default.

Issue just-in-time credentials with short TTLs and a fresh per-session key pair, using Ed25519 or P-256 so identifiers such as DIDs can be derived deterministically. Rotate keys without changing agent_instance_id. That single rule keeps the audit trail continuous while the cryptographic material turns over. Set a refresh-token policy that supports revocation and helps detect replay.

Define revocation as a service level, not a hope. Set a target for how quickly a revoked parent grant must propagate to every descendant, and automate it. Any delay between revocation and enforcement can leave an exposure that an attacker or a misbehaving agent could exploit. Test the propagation regularly, not only at design time.

Auditability and tamper-evident evidence

An audit record for an agent action should let a stranger reconstruct what happened without trusting your database. Capture immutable consent and grant records containing the subject ID, agent DID, agent_instance_id, scopes, the full delegation chain, timestamps, and human consent fields.

Structure the log so tampering is detectable. DAAP specifies hash-chained, append-only audit trails, where each entry commits to the previous one, so altering history breaks every later hash. Combine that with signed delegation receipts and an auditor can verify the record offline.

Design evidence artifacts for deterministic referencing: the same inputs should always produce the same artifact identifier. Include provenance metadata such as attestation references, key IDs, and signed hashes. For regulated firms, the practical question is what you can log without touching customer data. Our guidance on AI logging for compliance teams covers metadata-level evidence, and our post on identity graphs and audit replay shows how to reconstruct activity from OAuth metadata.

Auditability and tamper-evident evidence — overview diagram

Policy and governance controls

Identity signals only matter if a policy engine consumes them. Feed agent attributes and runtime context into your policy decision point, and use attribute-based or policy-based access control with engines such as OPA or Cedar as the backend where they fit. Useful attributes include instance ID, attestation status, delegation depth, and the registry record's capability list.

Add operational guardrails that bound the damage to a wrong decision: budget limits, rate limits, and segregation of duties. Treat fully autonomous agents as high-risk principals by default, and relax that only with evidence.

For high-risk operations, require a human in the loop. The consent screen should display the agent's name, its developer, and the exact scopes requested, and the resulting consent record should follow a defined retention policy. The CSA's agentic IAM framework combines DIDs, Verifiable Credentials, and Zero Trust principles with a unified session and policy enforcement layer. For control design, see our walkthrough of deterministic controls for AI.

A prioritized implementation checklist

Work in two horizons, starting with what you can ship without new infrastructure.

  • Build an agent inventory as an identity graph, capturing metadata and provenance for every agent, including unsanctioned ones.
  • Short term: enable proof-of-possession tokens, instrument attestation, and put a credential-exercise endpoint in front of agents.
  • Medium term: deploy an ANS-style registry, adopt delegation receipts and signed chains, and integrate PDPs with credential vaults.
  • Run red-team exercises against revocation and delegation-splicing, and document results for auditors.
  • Record assumptions, retention periods, and owners so evidence survives staff turnover.

Pro Tip: Pilot on one agent workflow first, and measure how long a full revocation takes from trigger to enforcement before you scale.

For phased planning, our oversight plan turns these steps into a schedule.

Standards and resources to reference

The guidance above sits on a small set of authoritative materials. NIST's NCCoE concept paper proposes a demonstration project to produce implementation-oriented guidance on applying identity standards to software agents. NIST's own commentary urges teams to use existing patterns like SPIFFE and OAuth 2.0 now, while moving toward granular patterns such as Rich Authorization Requests.

OWASP's Agentic Security work and the ANS specification cover discovery. The IETF drafts on Client Instance Assertion, credential delegation, and DAAP cover token framing, receipts, and revocation. The CSA framework and W3C DIDs and Verifiable Credentials supply the decentralized identity layer. Several of these are working drafts, so pin versions in your design documents and revisit them as they mature. For vocabulary, a concise AI agent security primer helps non-specialist stakeholders.

A pragmatic path for regulated firms

In regulated environments, I would put audit-ready evidence ahead of everything else. A perfectly designed delegation protocol is worth little if you cannot show an examiner what your agents did. Metadata-first, non-invasive telemetry gets you there without a risky integration project.

Start small: attestation and sender-constrained tokens on one workflow, then PDP integration and delegation receipts. Write down your assumptions and retention rules, and rehearse revocation and incident scenarios until they are routine.

— Eleye

Agentless evidence for teams that need audit-ready proof

If you need an inventory and evidence trail without touching production data, we built AETHER Pulse for that. It connects through read-only OAuth metadata, builds your AI agent identity graph, and produces tamper-evident, signed evidence packs. Request a demo or a readiness audit, or read how agentless governance works.

Aetherpulse

FAQ

What are the 5 types of AI agents?

The classic taxonomy lists simple reflex, model-based reflex, goal-based, utility-based, and learning agents. For identity management the more useful split is by autonomy and delegation: whether an agent acts for one user, spawns sub-agents, or acts independently. Higher autonomy means a higher-risk principal.

What is IAM?

Identity and access management is the discipline of verifying who or what is requesting access and deciding what they may do. For AI agents it extends to per-instance identities, delegated scopes, and audit records tied to each action.

How do I have an AI agent?

You build or deploy one on an agent platform, then register it as its own principal rather than reusing a shared service account. Give it an instance identity, scoped short-lived credentials, and an accountable owner before it touches production systems.

What is AI agent security?

It is the set of controls that keep autonomous agents within their intended authority: cryptographic identity, sender-constrained tokens, scoped delegation, revocation, and tamper-evident logging. The goal is that every agent action can be attributed, limited, and reversed.

Sources

Recommended

Working on Article 26 readiness, deployer-side governance evidence, or AI agent risk at a regulated firm? We'd value 15 minutes of your perspective.

Start a conversation