AI agent identity models expose the limits of traditional IAM

At a glance

What this is: 1Password maps production AI agents into delegated, bounded, and autonomous authority models and shows why each requires different identity controls.

Why it matters: IAM, NHI, and human identity programmes all need separate governance patterns for AI agents because delegation, scope drift, and runtime escalation change how access should be issued, traced, and revoked.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read 1Password's analysis of AI agent authority models and identity controls

Context

AI agent identity is the discipline of deciding how software that acts with variable intent, tool use, and access needs should be authenticated, authorised, audited, and revoked. The article’s central claim is that a single identity architecture cannot safely govern all agent behaviours because delegated, bounded, and autonomous systems create different trust boundaries and different failure modes.

That matters to identity teams because the controls that work for humans and predictable workloads do not automatically hold for agents that can change scope mid-task, spawn sub-agents, or retain access longer than the task that justified it. NHI governance has to move from static provisioning assumptions to runtime authority models, especially where production access, auditability, and revocation are involved.

Key questions

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

A: They should require a traceable delegation chain, short-lived scoped tokens, and an auditable link between the human principal and the agent’s actions. If the agent can act for a person, the identity system must prove whose authority it has, what scope was granted, and when that scope ended. Without that chain, the actions are not governable as delegated identity.

Q: Why do autonomous agents create more identity risk than ordinary automation?

A: Autonomous agents can change access needs while the task is running, which means least privilege cannot be fully decided at provisioning time. That runtime behaviour creates scope drift, sub-agent delegation, and revocation challenges that simple workflow automation does not create. Identity teams have to govern the session as a changing authorization event, not a fixed job definition.

Q: What breaks when bounded agents are given broad standing credentials?

A: The blast radius expands from one workflow run to every system those credentials can reach. If the credential is compromised, reused, or inherited by a misbehaving process, the agent is no longer confined to its intended scope. The correct control is per-run, short-lived access tied to the exact workload boundary, with separate policies for non-production and production.

Q: Who should be accountable when an AI agent crosses its authorized boundary?

A: Accountability should follow the authority model. For delegated agents, the human principal owns the delegation subject; for bounded agents, the workflow owner owns the scope; for autonomous agents, the organisation must own the runtime policy and revocation model. If accountability is only recorded after the fact, the identity programme has already lost the chain.

Technical breakdown

Delegated authority and traceable human delegation

Delegated agents act on behalf of a named human, so the core technical problem is not just issuing access but preserving the delegation chain. The article frames this through token exchange, workload identity, and attestation: the agent must prove both what it is and whose authority it carries. In practice, that means the identity system has to bind actions back to the human principal and keep the delegation auditable across local and remote runtimes. Service-account-style logging does not satisfy that requirement because it erases the delegation subject.

Practical implication: build delegation-aware identity flows that preserve subject, scope, and action history end to end.

Bounded authority, scope enforcement, and blast radius

Bounded agents act for a system or workflow rather than a human, so the technical issue shifts to strict scope enforcement. These workloads often receive wider permissions than a single run needs, which turns credential compromise into blast radius expansion. The article’s architecture discussion points to short-lived workload identity, per-run credentialing, and platform-backed issuance as the mechanism that keeps automation from becoming persistent access. This is the classic NHI problem, but with agent runtimes the cost of overscoping rises because workflows are continuous and highly connected.

Practical implication: bind each automation run to a short-lived identity and separate dev, test, and production scopes.

Autonomous authority and runtime escalation

Autonomous agents are different because the access problem changes while the task is in flight. The article describes agents that start with one scope, then request additional access mid-execution, sometimes spawning sub-agents or crossing systems the initiator did not explicitly plan for. That means pre-provisioned least privilege is no longer the whole control story. The technical requirement becomes just-in-time privilege escalation with tamper-evident authorization history, plus revocation cascades that can terminate downstream activity when the top-level session changes.

Practical implication: design for runtime escalation and downstream revocation, not for static approval at session start.

Threat narrative

Attacker objective: The objective is to turn legitimate agent authority into broader system reach, allowing unauthorised actions, data access, or credential exposure without breaking the initial trust chain.

1. Entry occurs when a local agent session or remote workflow is granted legitimate initial access under delegated, bounded, or autonomous authority.
2. Escalation occurs when the agent’s scope expands mid-task, often after prompt injection, task drift, or a new runtime request for broader access.
3. Impact occurs when over-broad or persistent credentials let the agent reach systems, data, or sub-agents beyond the original authorization boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

AI agent identity governance breaks when access is assumed to be stable long enough to review. That assumption was designed for humans and predictable workloads, where privileges can be certified after the fact. It fails when an agent can expand scope mid-task, spawn sub-agents, or complete a sensitive action before any review cycle sees it. The implication is not just better controls, but a different governance model for runtime authority.

Delegated, bounded, and autonomous authority are not product labels. They are different identity problems. Delegated authority requires traceability back to a human principal, bounded authority requires strict scope confinement, and autonomous authority requires handling escalation as part of execution rather than as an exception. This is why one identity architecture cannot fully govern all agents. Practitioners should classify the authority model first, then map controls to the behaviour that model creates.

Ephemeral access alone is not enough when the agent can re-plan while running. The article shows that the risk is not merely long-lived credentials, but the combination of runtime decision-making and access that persists across task boundaries. That creates identity blast radius: the maximum harm becomes whatever the agent can still touch when its intent changes. Teams should treat scope drift as a primary governance signal, not an edge case.

Local and remote execution environments change the attestation problem in ways most IAM programmes still underweight. On local systems, the issue is whether the calling process is really the agent; in remote managed runtimes, the issue is whether the platform can enforce task-scoped identity without turning into standing privilege. That means governance has to cover provenance, execution context, and revocation together. Practitioners should align authority models with the runtime they actually deploy.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records.
• For a broader breach lens, read 52 NHI Breaches Analysis for recurring control failures across machine identity incidents.

What this signals

Identity blast radius is the concept practitioners should watch here: once an agent can widen scope during execution, the governance question becomes how far it can reach before policy catches up. That shifts programmes toward runtime authorization, continuous evaluation, and tighter separation between development and production trust domains.

The likely next step for many organisations is not adding more rules, but reducing the number of places where agent authority can silently persist. When delegated, bounded, and autonomous models are treated as the same problem, access reviews become too blunt to be useful. Teams should align agent runtime, revocation, and audit design to the actual authority model in use.

The broader market signal is that AI agent governance is converging with NHI governance, not replacing it. That makes identity lifecycle controls, ephemeral credentials, and delegation traceability the core programme issues rather than niche implementation details.

For practitioners

• Define authority models before issuing access Classify each agent as delegated, bounded, or autonomous, then assign identity policies based on that authority chain instead of on the tool or workload name. Use separate rules for human delegation, workflow authority, and self-directed runtime escalation.
• Separate development and production trust domains Block any agent, local or remote, from carrying the same credentials across development and production. Require distinct workload identities, distinct approval paths, and explicit re-authorization before production-scope actions.
• Make session revocation propagate across downstream systems Use continuous access evaluation so a revoked human session, changed policy, or security event terminates active agent access across every relying party the agent has touched. Do not wait for token expiry to cut off access.
• Treat scope drift as a monitoring signal Instrument agents to detect when task scope expands from the original authorization boundary, especially when they request broader access mid-session. Escalation requests should be visible in audit logs and reviewed as a control failure, not a normal operating event.

Key takeaways

• AI agent identity cannot be governed with one generic IAM pattern because delegated, bounded, and autonomous agents create different authority chains.
• The strongest evidence in the article is that runtime scope drift, not just credential persistence, is what turns agent access into a security problem.
• Identity teams should classify the authority model first, then design traceability, revocation, and production separation around that model.

Key terms

• Delegated Authority: A delegated authority model means an agent acts on behalf of a named human and must inherit only the permissions that human explicitly approved. The identity system must preserve the delegation chain, so every action can be traced back to the principal, scope, and runtime context that authorised it.
• Bounded Authority: A bounded authority model gives an agent access because it belongs to a workflow or system, not because it represents a person. Its permissions should be limited to the exact operational boundary of the run, with short-lived credentials and separate policies for each environment it can touch.
• Autonomous Authority: An autonomous authority model describes an agent that can adapt its actions and access needs while pursuing a goal with minimal or no human oversight. In identity governance, that means access cannot be treated as a fixed provisioning decision, because the agent may escalate, delegate, or re-plan during execution.
• Scope Drift: Scope drift is the gradual or sudden expansion of access beyond what the original task required. For agents, it often appears mid-session when the system requests more data, more tools, or a production boundary that was not part of the initial approval, turning a controlled workflow into a broader risk.

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 responsible for identity security strategy or programme governance, it is worth exploring.

This post draws on content published by 1Password: AI agent authority models and the identity controls needed to secure them. Read the original.