AIMS and agent identity: why workload models are shifting

At a glance

What this is: An IETF draft frames AI agents as workload identities and proposes AIMS as a reference model for issuing credentials, evaluating authorization, and handling delegation.

Why it matters: IAM teams need to understand this shift because agent governance will sit between NHI controls, workload identity design, and future access models for autonomous systems.

👉 Read Aembit's analysis of AI agent identity and AIMS

Context

AI agent identity is becoming an IAM problem, not just an application design choice. The draft starts from a simple reality: agents are acting, calling APIs, and taking decisions in ways that do not map cleanly to user-centric identity.

That matters because existing governance models assume a stable human session or a conventional service account lifecycle. For teams already using workload identity patterns, the draft is a signal that agent access will likely converge on those controls rather than inventing a wholly separate identity stack.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Treat the agent as a non-human identity with its own lifecycle, ownership, and access policy. Then require scoped delegation, short-lived credentials, and authorization checks at each sensitive action. If the agent can pass context to another system, re-evaluate the permission before the next hop rather than assuming the original user approval still applies.

Q: Why do AI agents complicate existing IAM and NHI controls?

A: They complicate control design because they can select actions at runtime, call multiple APIs, and move authority across systems without a human session boundary. That breaks assumptions built into static entitlements and traditional service account management. Governance has to account for delegated action, changing context, and auditability across the full execution chain.

Q: What breaks when agents use long-lived API keys or shared credentials?

A: Ownership, accountability, and blast radius all become harder to contain. A shared credential hides which actor actually performed an action, while a long-lived key can outlast the task, the environment, or the policy context that justified it. That creates access that is difficult to revoke, difficult to audit, and easy to overuse.

Q: What is the difference between agent authentication and agent authorization?

A: Authentication proves the agent has a valid identity and credential. Authorization decides whether that identity can perform a specific action in a specific context, such as a particular API call, environment, or user delegation. For agents, authorization is usually the harder problem because the actor’s intent and scope can change during execution.

Technical breakdown

Agents as workload identities

The draft frames agents less like users and more like workloads. That means the identity subject is a software actor that authenticates programmatically, carries machine credentials, and requests access based on runtime context rather than a browser session or MFA ceremony. In practice, this is closer to service identity and container identity than to human IAM. The important design choice is that the agent is not granted implicit trust because it can reason or plan; it still needs a verifiable identity, scoped credentials, and an enforcement point that can evaluate each request.

Practical implication: Treat agent identity as workload identity first, then layer authorization and delegation on top of that model.

AIMS as an identity stack, not a single protocol

AIMS is presented as a reference model for the full control plane around agent identity. It covers issuance of identity, proof of runtime state, credential presentation, authorization evaluation, and enforcement at APIs or gateways. The draft leans on existing building blocks such as OAuth delegation, JWTs, certificates, and workload identity patterns rather than inventing a new protocol family. That is a deliberate architectural signal: the problem is not a lack of primitives, but a lack of consistent composition for a new class of actor.

Practical implication: Map your agent controls across issuance, attestation, token use, and enforcement instead of treating authentication as the whole problem.

Delegation chains and dynamic authorization

The draft acknowledges that the hardest part is not initial login, but delegated authority across changing context. An agent may act for a user, then pass context to another agent, and each hop can widen or distort the original permission boundary. That creates policy questions about runtime trust, environmental conditions, and action scope. The core governance issue is that authorization may need to be re-evaluated repeatedly as the chain expands. This is where existing static IAM assumptions start to strain, especially when multiple systems must trust the same delegation signal.

Practical implication: Design policy checks for every delegation hop and every sensitive action, not just for the first token issuance.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent identity governance is converging on workload identity, not human IAM. The draft is most useful because it rejects the idea that agents should be forced into user-shaped controls. Agents authenticate as software actors, use machine credentials, and participate in programmatic authorization flows, which places them squarely in NHI territory. That means the governance problem is not a new category of identity, but a new workload class that must inherit the discipline of short-lived credentials, scoped access, and explicit enforcement. Practitioners should read this as a signal that agent controls will be judged against workload identity expectations, not human login patterns.

Implicit trust in agent behaviour is the model that breaks first. Long-lived API keys, shared credentials, and loosely defined identities work only when the actor’s behaviour is bounded and predictable. The draft shows why that assumption is collapsing: agents can call multiple APIs, choose actions at runtime, and pass authority through delegation chains. The implication is not simply to add more controls, but to recognise that static identity assumptions no longer describe the actor. Practitioners need to stop treating agent access as an extension of service account management and start treating it as a separate governance boundary.

Context-aware authorization will become the differentiator between usable and unsafe agent systems. The draft leaves runtime policy intentionally open, and that is the right place to be unresolved. Authorization for agents will depend on actor state, execution environment, delegated user context, and action sensitivity, all of which can shift during a session. That makes access decisions more dynamic than traditional entitlement checks. The practitioner conclusion is that policy engines will need to evaluate not just who the agent is, but what it is trying to do, under what conditions, and on whose behalf.

Multi-agent delegation is the emerging failure mode worth naming now. Once agents can pass context to each other, accountability becomes harder to trace and authority can drift away from the original intent. That is not a niche edge case, it is the natural extension of agent-to-agent orchestration. The governance lesson is that every added delegation hop increases the chance that access and responsibility diverge. Teams should treat delegated authority chains as a first-class audit and policy problem, not as implementation detail.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap connects directly to the OWASP Agentic Applications Top 10, which is the right next framework for governing tool use and delegation risk.

What this signals

Identity blast radius: when agents can call tools, inherit context, and pass authority forward, the control problem shifts from login assurance to containment of action scope. That makes runtime policy evaluation and delegation tracking more important than any single authentication event.

With 80% of organisations already seeing agent behaviour exceed intended scope, the governance gap is no longer theoretical. Teams that are extending IAM controls to agents should focus on where access is granted, how it is re-evaluated, and which systems can still prove who or what acted.

For practitioners building agent programmes, the next step is to align workload identity, Zero Trust enforcement, and audit trails around action boundaries. The useful question is not whether the agent authenticated, but whether the system can explain and constrain what happened next.

For practitioners

• Define agents as workload identities Model every agent as a distinct non-human identity with its own lifecycle, ownership, and access boundary. Do not inherit user accounts, shared service credentials, or generic application identities for agent behaviour.
• Scope credentials to specific actions Issue short-lived credentials that are tied to a narrow action set and a single execution context. Avoid credentials that remain valid across unrelated tasks, environments, or delegation chains.
• Evaluate delegation at every hop Require policy checks whenever an agent acts on behalf of a user or passes authority to another system. Audit which APIs, tools, and downstream systems receive delegated context without re-authorisation.
• Separate runtime state from identity issuance Use attestation, environment checks, and policy evaluation as separate controls rather than assuming identity issuance alone proves trustworthiness. This helps prevent over-trusting an agent simply because it obtained a token.

Key takeaways

• AI agents are becoming workload identities, which means their governance belongs in NHI and workload access design rather than human IAM patterns.
• Runtime delegation and scoped authorization matter more than initial authentication because agent behaviour can change after a token is issued.
• Practitioners should build controls around action boundaries, hop-by-hop reauthorization, and short-lived credentials to keep agent scope auditable.

Key terms

• Agent Identity Management System: AIMS is a reference model for how an AI agent receives identity, proves its runtime state, presents credentials, and gets authorization to act. It is not a product or a protocol. In practice, it describes the control stack needed to govern agent actions as a software identity with delegated authority.
• Delegated authorization: Delegated authorization is the act of allowing one identity to perform actions on behalf of another identity, usually with scope limits. For AI agents, it becomes harder because the delegation can move through multiple systems and contexts. Practitioners need to preserve traceability and re-check authority at each hop.
• Workload identity: Workload identity is the identity assigned to a non-human runtime such as a service, process, container, or agent. It is designed for machine-to-machine authentication and policy enforcement, not human interaction. For agent systems, it provides the closest mature model for access governance and credential handling.
• Runtime authorization: Runtime authorization is the decision to allow or deny an action at the moment it is requested, based on current context. For agents, this matters because intent, environment, and delegated scope can change during execution. It is a stronger governance pattern than relying on a one-time login or token issuance.

Deepen your knowledge

AI agent identity and delegated authorization are core topics in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents that act on behalf of users or other systems, it is worth exploring.

This post draws on content published by Aembit: AI agents are starting to look less like tools and more like participants. Read the original.