AI agent identities expose the limits of traditional IAM

At a glance

What this is: This is an analysis of how non-deterministic AI agents strain traditional identity and access models because they can act near credentials, code, and production systems without predictable behavior.

Why it matters: It matters because IAM, NHI governance, and human access processes all assume a more stable principal than an AI agent that can change actions at runtime.

By the numbers:

• 73% of employees are encouraged to use AI for some part of their workload.
• 37% say they only follow company AI policies most of the time.

👉 Read 1Password's analysis of AI agent identity risk and runtime access

Context

AI agent identity risk is a governance problem, not just an engineering one. When software can choose actions at runtime, use tools, and operate near credentials and production systems, traditional access models built for predictable principals start to lose their assumptions about control and accountability.

That gap matters across NHI, autonomous, and human identity programmes because the same organisation may be governing developers, service credentials, and agentic systems through different rules that no longer fit together cleanly. The result is policy drift, overbroad access, and weak attribution when access decisions happen at machine speed.

Key questions

Q: How should security teams implement least privilege for AI agents that change behaviour at runtime?

A: Security teams should define access around task profiles, not assumed user stories, and keep grants as narrow as the current workflow allows. For AI agents, least privilege has to be paired with runtime attribution and escalation paths, because the access needed in one run may not match the next. The goal is to bound exposure while preserving operational continuity.

Q: Why do AI agents complicate existing IAM and access review processes?

A: AI agents complicate IAM because access review assumes a stable principal with durable entitlements that can be certified later. Agents can acquire, use, and release access in ways that are too dynamic for periodic review alone. That means teams need runtime controls, event logging, and approval flows that operate at the moment of action, not after the fact.

Q: What breaks when external content can influence an AI agent’s tool use?

A: What breaks is the boundary between information processing and delegated execution. If an agent treats untrusted content as operator intent, it can make privileged tool calls based on hostile instructions. Teams should separate content ingestion from action authorization and review every privileged action that follows external input.

Q: How do organisations know whether AI agent governance is actually working?

A: Governance is working when teams can show which actions were allowed, which were used, and which were escalated with named approval. If access is granted but usage is opaque, the programme has only created the appearance of control. The clearest signal is complete attribution across the full access lifecycle.

Technical breakdown

Why non-deterministic agents break static least privilege

Least privilege works when the principal’s required access can be defined in advance and kept relatively stable. Non-deterministic agents do not behave that way. They may choose different tools, call different services, or need different data paths depending on the live task, input, or environment. That means static grants are either too narrow and cause failures, or too broad and expand blast radius. The deeper issue is not just policy tuning. It is that the access model assumes a predictable actor, while the agent’s behaviour is contingent and runtime-driven.

Practical implication: define access by task profile and runtime boundary, not by a one-time assumption about what the agent will need.

Prompt injection and tool misuse are control-plane failures

Agents that process external content can be manipulated through instructions embedded in emails, documents, or tool responses. The security problem is similar to classic injection attacks: untrusted input crosses into a context that can influence execution. In agentic systems, that becomes more dangerous because the agent may treat hostile content as legitimate operator intent and act on it automatically. The missing control is not just filtering input. It is separating what the agent was asked to do from what it merely observed, then constraining which actions the observed data can trigger.

Practical implication: isolate untrusted content from action-bearing contexts and audit every tool invocation that follows external input.

Runtime credential delivery changes the identity boundary

Traditional IAM often assumes credentials are provisioned ahead of use and then managed through long-lived entitlements. Agentic workflows push in the opposite direction. Credentials may need to appear only at runtime, remain in memory, and disappear when the task ends. That changes the identity boundary from a persistent account to an ephemeral access event. It also makes attribution more important, because security teams need to know what was granted, what was actually used, and where escalation occurred. Without that visibility, agent activity becomes hard to govern or explain after the fact.

Practical implication: move sensitive credentials out of persistent storage and require full event attribution for every agent access path.

NHI Mgmt Group analysis

Least privilege designed for stable principals fails when the actor is non-deterministic. That model assumes the required access set can be defined up front and remains valid long enough to govern. The article’s core point is that agents can behave differently across runs, so the privilege profile is not static enough for conventional provisioning logic. The implication is that identity governance must stop treating agent access as a fixed grant and start treating it as a runtime state with bounded scope.

Prompt injection becomes an identity issue when an agent can turn untrusted content into delegated action. This is not just an application-security flaw. It is a control failure in the decision path between input, interpretation, and execution. When an agent can follow hostile instructions while appearing to act within policy, accountability shifts from the user to the governance boundary that failed to separate intent from data. Practitioners should treat this as a failure of delegation design, not merely content filtering.

Standing access is the wrong default for agents that should only touch secrets at the moment of need. The article reinforces a zero-start access model, with credentials delivered at runtime and traceable per event. That approach aligns with NHI governance more cleanly than pre-provisioned entitlements because it narrows exposure and improves attribution. The practitioner takeaway is that access orchestration for agents has to be designed around ephemeral use, not persistent possession.

Agent identity creates a new governance gap between policy, usage, and escalation. Teams can grant access, but that does not mean the agent used only what was intended or that unexpected needs were routed correctly. The hard part is documenting the full chain from grant to use to approval, because that is where the control story either holds or collapses. Practitioners need a model where escalation is explicit, auditable, and tied to named approvers.

AI agent identity is now the point where human IAM, NHI controls, and autonomous behaviour converge. That convergence is where most programmes will feel the strain first, because each discipline currently assumes a different kind of actor. The post shows that security teams cannot govern agent access by borrowing only human access review habits or only machine credential patterns. The field needs a blended governance model that recognizes behaviour, attribution, and runtime scope together.

From our research:

• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope, 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.
• For a broader control lens, see OWASP Agentic Applications Top 10 for the identity and tool-use risks that show up when agents act outside expected scope.

What this signals

Agent identity governance is moving from entitlement review to runtime control. The practical shift is from asking who should have access to asking when an agent is allowed to obtain it, use it, and relinquish it. That change is already visible in environments where policy is expressed as code and credentials are delivered only at the point of need.

With 48% of organisations unable to track and audit what their AI agents access, the compliance problem is already a visibility problem, not a future model question, according to AI Agents: The New Attack Surface report. Teams that do not build event-level attribution now will struggle to explain agent actions later.

Ephemeral credential trust debt: as more workflows depend on runtime-delivered access, organisations accumulate a new form of governance debt when they cannot prove what was granted versus what was actually used. That gap will matter most where agents sit close to secrets, source code, and production systems.

For practitioners

• Map agent tasks to runtime access profiles Define the smallest practical access set for each agent workflow, then grant it at the moment of use rather than preloading broad entitlements. Review where the agent actually consumed access versus what it was expected to need.
• Separate untrusted input from execution triggers Block external content from directly influencing tool calls unless the action is explicitly approved or policy-evaluated. Log every transition from observed data to a privileged action.
• Require full attribution for agent access events Track what was granted, what was used, and which identity or approver authorized any escalation. Use those records for review, not just for incident response.
• Move secrets out of persistent storage paths Deliver credentials only when the agent needs them, keep them in memory where possible, and prevent writes to disk or source history. This reduces the lifetime of exposed secrets and makes misuse easier to detect.

Key takeaways

• AI agents change identity governance because their access needs are runtime-dependent, not fixed at provisioning time.
• 1Password’s data shows policy adoption is lagging behaviour, with 73% encouraged to use AI but only 37% following policy most of the time.
• Practitioners should move toward task-scoped access, full attribution, and ephemeral credential delivery before agent sprawl makes the control gap larger.

Key terms

• Non-deterministic Agent: An AI system whose next action is not reliably predictable from prior runs because it can choose different steps, tools, or paths at runtime. In identity governance, this matters because access decisions cannot safely rely on a fixed behavioural pattern or a static entitlement profile.
• Runtime Access Profile: A task-scoped description of the access an agent is allowed to obtain during execution rather than a permanent entitlement set. It is useful when the same principal may need different permissions across runs and when credential exposure should be limited to the moment of use.
• Ephemeral Credential Delivery: A pattern in which credentials are issued only when required and are kept out of durable storage such as disk or source history. For agentic systems, this reduces secret persistence, narrows blast radius, and gives security teams a cleaner attribution trail for each access event.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by 1Password: analysis of AI agent identity risk and runtime access. Read the original.