AIMS and agent identity: why workload models are shifting

At a glance

What this is: This is Aembit’s analysis of an IETF Internet-Draft that frames AI agents as workload identities and proposes AIMS as a reference model for issuing identities, credentials, and scoped runtime access.

Why it matters: It matters because IAM teams now have to govern actors that act on behalf of users and systems, which breaks assumptions built around human sessions and static service identities.

Context

AIMS, or Agent Identity Management System, is a reference model for how AI agents can be identified, authenticated, and authorized when they act as programmatic actors rather than human users. The article argues that the familiar user-session model does not translate cleanly to agent-driven systems that call APIs, orchestrate workflows, and make decisions at runtime.

The governance gap is not about whether agents can authenticate at all, but about how identity, delegation, and authorization behave when an agent is treated like a workload. In that model, short-lived credentials, scoped tokens, and runtime policy evaluation become the centre of control rather than persistent access or human approval loops.

Key questions

Q: What breaks when AI agents are treated like standard human users?

A: You lose visibility into effective permissions, expected behaviour, and real blast radius. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

Q: Why do short-lived credentials matter more for agentic AI than for ordinary apps?

A: Agentic systems can request, use, and discard access inside a narrow runtime window, so long-lived credentials create unnecessary exposure between actions. Short-lived credentials reduce the time available for misuse and make revocation meaningful at task completion. They matter because the control problem is runtime access, not only initial authorisation.

Q: How do security teams know if agent authorization is actually working?

A: Authorization is working only if the agent can complete the intended task without gaining unnecessary reach. Good signals include short-lived credentials, task-scoped permissions, approval for sensitive changes, and clear logs linking each action to a user and an agent. If credentials are reused, privileges persist, or the agent can move between systems without reauthorization, the control is failing.

Q: How should security teams handle delegated access when AI agents act on behalf of customers?

A: Security teams should treat delegated access as a separate governance layer, not as a normal login session. Define what the agent can do, how much value it can move, which approvals are required, and how delegation is revoked. Without those boundaries, the agent inherits more authority than the customer intended and fraud risk expands quickly.

Technical breakdown

Why workload identity fits AI agents better than user identity

The draft frames agents as workload identities because they behave more like services or processes than people. A workload identity is a non-human identity that authenticates machine-to-machine and is governed through credential issuance, scope, and runtime policy rather than interactive login. That distinction matters because a human-centric model assumes a session, a user interface, and an operator making choices in real time. Agents can initiate actions, chain API calls, and delegate context without those assumptions. AIMS tries to align identity treatment with that behaviour instead of forcing agents into user patterns that create brittle exceptions.

Practical implication: treat agents as governed workload actors and design identity flows around scoped machine authentication, not human session design.

How AIMS composes identity, credentials, and runtime authorisation

AIMS is not a protocol. It is a reference model that connects the pieces needed for agent identity: issuance of an identity, proof that the agent is running in an expected state, delivery of a short-lived credential, and runtime evaluation of what the agent is allowed to do. The draft leans on existing mechanisms such as OAuth-style delegation, JWTs, certificates, and enforcement points like gateways or APIs. In effect, it describes an identity control plane for agents where rights are evaluated at the moment of use rather than assumed from provisioning time.

Practical implication: map each agent action to an issuance, proof, token, and enforcement step so access decisions are made in context.

Where delegated authority changes the control problem

The draft gives delegated authorization an explicit role because many agents act on behalf of a human or another system. That creates a different risk profile from a standalone service account. The identity stack now has to preserve who authorised the delegation, what the agent can do under that delegation, and when the authority should stop being valid. That is materially harder than simple credential management because the effective privilege boundary may change by task, user intent, or environment state. Once delegation is part of the design, identity becomes a dynamic policy problem, not just an inventory problem.

Practical implication: define delegation boundaries explicitly and tie every delegated action to a context-sensitive authorization rule.

Threat narrative

Attacker objective: The practical objective is to gain broad, reusable access through agent credentials that were never designed for dynamic delegation and cross-system action.

1. Entry occurs when agent implementations rely on long-lived API keys, shared credentials, or loosely defined identities that are easy to reuse across systems.
2. Credential exposure or overreach follows when those credentials are not scoped tightly enough for the agent’s runtime task and delegation context.
3. Escalation happens as the agent gains access to multiple systems through the same identity path, expanding its effective authority beyond the original request.
4. Impact is credential sprawl, fragmented trust, and hard-to-audit delegated access across agent-driven workflows.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

NHI Mgmt Group analysis

AIMS formalises the shift from session-centric IAM to workload-centric agent governance. Human identity models assume an interactive subject, while agents initiate actions, call APIs, and continue executing without the cues that IAM was built around. The article is important because it treats that mismatch as a design problem rather than a policy footnote. Practitioners should read AIMS as evidence that agent identity is now a first-class workload discipline.

Short-lived credentials and scoped tokens are necessary, but they do not solve the delegation problem by themselves. AIMS correctly points to familiar machine-identity mechanics, yet the hard part is whether the delegation remains valid for the action being taken at runtime. That means governance has to follow the agent’s context, not just the token format. Practitioners should evaluate whether their authorisation model can express task-bound delegation boundaries.

Runtime authorisation is the control boundary that matters most for agent identity. The draft’s strongest implication is that issuance alone is not enough when the actor can decide and re-evaluate mid-task. This is where workload identity and agent identity converge: access must be checked at the point of action, not only at enrolment. Practitioners should design for enforcement at the moment of use, not trust in static registration.

Human session assumptions collapse when the actor can act, delegate, and re-evaluate context autonomously. Human-centric IAM was designed for interactive approval loops and stable operators, not for agents that can chain actions inside a single workflow. That assumption fails when authority can be acquired, exercised, and passed along without a person in the loop. The implication is that identity governance must move from review-based thinking to runtime-control thinking for agentic systems.

Agent identity will converge on the same governance questions that shaped workload identity, but with higher delegation complexity. The article shows that the market is moving toward shared language around identities, credentials, and policy enforcement for agents. That convergence is useful because it reduces fragmentation, but it also raises the stakes for lifecycle, scope, and offboarding controls. Practitioners should expect AIMS-style models to influence how agent identity programmes are structured.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• According to PwC, 79% of organizations have already adopted AI agents to some degree.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Agent identity is moving from an edge case to a governance category of its own. IAM programmes that still treat agents as patched-on service accounts will miss the operational difference between static machine identities and actors that initiate work on behalf of users. The practical shift is toward runtime policy, delegated authority, and explicit lifecycle ownership for agent identities.

AIMS-style thinking pushes identity teams to align governance with the moment of action. That matters because access review processes are weakest when the subject can act and complete its task faster than the review cycle can observe it. The control boundary has to move upstream to issuance, delegation, and enforcement, or the review will always lag the real risk.

For practitioners

• Define agents as governed workload identities Classify each AI agent as a non-human identity and route it through the same inventory, ownership, and lifecycle controls used for other workload identities.
• Replace static credentials with short-lived, scoped access Issue credentials that expire quickly and are limited to a specific task, resource, and delegation context rather than reusing shared API keys.
• Move authorisation checks to runtime Evaluate the agent’s identity, environment, and requested action at the moment of use so policy decisions reflect current context.
• Map delegation boundaries explicitly Record when an agent is acting on behalf of a user or another system, and make the delegation scope part of the authorization decision.
• Test offboarding for agent identities Verify that agent credentials, tokens, and enforcement paths are revoked when the workflow, model, or operational purpose changes.

Key takeaways

• AI agent identity is no longer just an authentication problem, because the actor can take actions, call APIs, and delegate authority at runtime.
• The article’s core signal is that workload identity patterns are becoming the baseline for governing agents, not an optional architectural preference.
• Practitioners should focus on scoped credentials, runtime authorization, and explicit delegation boundaries if they want control to keep pace with agent behaviour.

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.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.