Notifications
Clear all
Topic starter
04/06/2026 6:50 pm
TL;DR: An IETF Internet-Draft on AI agent authentication introduces AIMS, a reference model that treats agents as workload identities using short-lived credentials, scoped tokens, and runtime authorization, according to Aembit. The real shift is that IAM assumptions built for human sessions and static service identities no longer fit actors that act, delegate, and re-evaluate context at runtime.
NHIMG editorial — based on content published by Aembit: AI agents are starting to look less like tools and more like participants
Questions worth separating out
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.
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.
Q: What breaks when agents use long-lived API keys or shared credentials?
A: Ownership, accountability, and blast radius all become harder to contain.
Practitioner guidance
- Define agents as workload identities Model every agent as a distinct non-human identity with its own lifecycle, ownership, and access boundary.
- Scope credentials to specific actions Issue short-lived credentials that are tied to a narrow action set and a single execution context.
- Evaluate delegation at every hop Require policy checks whenever an agent acts on behalf of a user or passes authority to another system.
What's in the full article
Aembit's full post covers the operational detail this post intentionally leaves for the source:
- The draft's component-level AIMS model for identity issuance, attestation, credential presentation, and enforcement points
- The specific standards the article connects to agent delegation, including OAuth, JWTs, certificates, and workload identity
- The practical limitations the author calls out around runtime policy, multi-agent delegation, and operational complexity
- The article's view on why existing identity building blocks may converge into a shared agent identity pattern
👉 Read Aembit's analysis of AI agent identity and AIMS →
AIMS for AI agents: are your controls keeping up?
Explore further
04/06/2026 7:04 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AIMS and agent identity: why workload models are shifting
