Agentic access control is outgrowing static IAM assumptions

At a glance

What this is: This article argues that least privilege becomes much harder for agents because their access needs emerge at runtime and can be manipulated after legitimate access is granted.

Why it matters: It matters because IAM, PAM, and NHI programmes built for predictable service accounts cannot safely govern agents that decide what to do, what to call, and when to act while holding standing privilege.

By the numbers:

• 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.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.

👉 Read Noma Security's analysis of agentic access control and least privilege

Context

Agents change the identity problem because access can no longer be assumed to be fixed at provisioning time. For human users and conventional service accounts, IAM teams can usually describe the expected access set in advance. For agents, the action path is assembled at runtime from task context, memory, retrieval, and tool choice, which makes static scoping much less reliable.

That is why agentic access control has become a governance issue, not just a tooling issue. The article frames the core failure mode as broad standing privilege granted so the agent can handle whatever comes up, which creates a larger attack surface than most human-operated workflows ever tolerate. In identity terms, the programme is no longer governing a predictable principal.

This is the same reason the topic sits at the intersection of NHI governance, runtime authorisation, and lifecycle control. If organisations cannot inventory agents, define task-scoped access, and separate decision from execution, they will keep applying service-account logic to systems that do not behave like service accounts.

Key questions

Q: How should security teams enforce least privilege for AI agent identities?

A: Start by treating every agent as an NHI with a dedicated identity, a tight permission boundary, and a named owner. Then enforce least privilege in policy, not just in dashboards, so unused access is removed and rare elevation is granted only through JIT workflows. The goal is to shrink blast radius before autonomy creates incident scale.

Q: Why do AI assistants create more risk than traditional service accounts?

A: AI assistants create more risk because they can be influenced by inputs, context, and hidden instructions after authentication succeeds. A traditional service account usually executes fixed logic, while an AI identity may summarize, retrieve, or act in ways that are harder to predict. That makes access scope and behavioral testing equally important.

Q: What do security teams get wrong about prompt injection defence?

A: They often assume better blocklists will solve the problem, but obfuscation simply changes the shape of the payload. Real defence requires examining meaning across the full interaction, including retrieved content and model responses. If the control cannot interpret intent, it will keep missing the attack class it is meant to stop.

Q: Who is accountable when an autonomous agent misuses access or exposes data?

A: Accountability should sit with the team that owns the agent lifecycle, policy, and runtime enforcement, not with the agent itself or with the model provider alone. If multiple groups share the control plane, they still need one named governance owner for recertification, monitoring, and incident escalation. Otherwise, the gap becomes a governance failure, not a technical one.

Technical breakdown

Why least privilege breaks when access is decided at runtime

Least privilege works best when the identity’s required permissions are known before execution begins. That assumption holds for many service accounts because their job is stable and enumerated in advance. Agents are different: the model chooses tools, data sources, and next actions dynamically based on the immediate task, which means the true access surface emerges during execution rather than at provisioning. When teams respond by granting broad access “just in case,” they trade uncertainty for standing privilege. That makes the identity easy to operate but hard to govern, because the effective privilege set becomes larger than the task actually requires.

Practical implication: Scope agent access to the task and session, not to the worst-case future possibility.

Confused deputy risk at machine speed

The confused deputy problem occurs when a legitimate, highly privileged system is tricked into using its access for an unintended purpose. In agentic systems, the trick often arrives through data. A retrieved document, email, or ticket can embed instructions that redirect the agent while it continues operating under valid credentials. Nothing appears broken in logs because the access is still authorised. The failure is intent separation: the system cannot reliably distinguish what it was asked to do from what the input is trying to make it do. That is why prompt injection and related instruction-hijacking patterns matter so much in access governance.

Practical implication: Put an external enforcement layer between the agent’s decision and the action it is about to take.

Task-scoped access is more precise than time-scoped access

JIT access is useful, but for agents it is only part of the control model. Time limits alone do not solve the problem if the agent can still use a broad permission set throughout the session. The stronger pattern is task-scoped access, where the credential is issued for a specific objective and expires when that objective ends. This narrows blast radius without assuming the agent’s future behaviour is known. It also aligns identity, authorisation, and accountability more cleanly because the permission exists for a defined purpose rather than as a persistent entitlement.

Practical implication: Issue credentials per task and expire them when the task is complete.

Threat narrative

Attacker objective: The attacker aims to turn legitimate agent access into unintended high-impact action without triggering obvious authentication failures.

1. Entry occurs when an agent is granted broad standing privilege so it can function across unpredictable tasks and tools.
2. Escalation happens when manipulated content or hidden instructions redirect the agent while it continues using legitimate credentials and authorised access.
3. Impact follows when the agent performs high-speed, high-scale actions that were technically allowed but operationally unintended, widening blast radius before human review can intervene.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Standing privilege is the governance failure that agentic systems expose first. The article shows that teams often compensate for runtime uncertainty by granting broad access upfront, then promise to tighten it later. That pattern fails because later is already too late once the agent can decide, retrieve, and act on its own. The implication is that identity governance must stop treating broad access as a temporary convenience.

Confused deputy risk becomes an authorisation problem, not just a prompt-injection problem. The core issue is that a valid identity can be steered into doing the wrong thing while still remaining inside its entitlement set. That breaks the assumption that authorised access is equivalent to intended access. Practitioners should read this as a control boundary failure across data, context, and action.

Agentic access is a named runtime governance gap, not a simple least-privilege tuning issue. Runtime governance gap: the distance between when access is granted and when an autonomous system decides how to use it. That gap widens when identity, tool choice, and execution timing are all dynamic. The implication is that policy written at provisioning time cannot fully describe the real risk envelope.

Identity standards built around bounded sessions and stable principals do not fully map to delegation chains. OAuth, OIDC, and SAML assume clearer ownership than many agent workflows can provide once sub-agents, retrieval, and external tool calls enter the picture. The article points to the accountability ambiguity that appears when multiple principals are represented inside one workflow. Practitioners should expect audit and responsibility models to become part of the access design itself.

Autonomy collapses the assumption that least privilege can be defined before intent is known. That assumption was designed for stable principals with predictable tasks. It fails when the actor decides which tools and data to reach at runtime, because the needed privilege surface is not knowable in advance. The implication is not just tighter controls, but a different model of governance that starts from execution behaviour rather than static entitlement.

From our research:

• 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.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, showing that the governance gap is already recognised at senior levels.
• That same survey found only 13% of organisations feel extremely prepared for agentic AI, a signal that access models and operating procedures still lag deployment speed.

What this signals

Runtime authorisation will become the differentiator in agent governance. Teams that only extend IAM policy files to agents will still miss the behavioural gap between allowed access and intended action. The practical shift is toward external enforcement, short-lived task scope, and tighter linkage between workflow ownership and credential issuance, especially where autonomous decisions can trigger real-world changes.

Agent inventory will become an operational control, not a discovery exercise. If teams cannot see every agent, every secret, and every reachable tool, they cannot meaningfully bound blast radius. That is why the inventory problem now sits alongside JIT access and offboarding in the same programme conversation, with the Ultimate Guide to NHIs serving as the baseline reference for machine identity governance.

Identity governance is starting to converge with agent safety controls. The article’s core point is that permissions alone do not protect against manipulated intent, so policy must increasingly account for decision-to-action pathways. For practitioners, the next maturity step is to connect identity review, tool governance, and runtime enforcement into one control model rather than treating them as separate projects.

For practitioners

• Inventory every agent and its reachable systems Build a complete register of formal agents, embedded automations, and shadow AI workflows. Record each credential, tool, data source, and external system the agent can reach so you can see the true access surface before authorising new deployments.
• Replace standing privilege with task-scoped JIT access Issue credentials for a specific session and objective, then expire them when the task ends. Avoid reusable API keys and broad always-on permissions that let an agent continue acting after the original purpose is complete.
• Separate decision from execution Place an external control layer between the agent’s output and the action it is about to take. That layer should evaluate intent, context, and permitted scope before the action runs, not after the event is logged.
• Review agent permissions through blast-radius analysis Test what a compromised or manipulated agent could do if it chose the worst allowed path within its current permissions. Use that analysis to reduce reachable systems, narrow tool access, and remove unnecessary write privileges.

Key takeaways

• Agentic systems break the old assumption that access can be fully described before execution begins.
• Broad standing privilege turns a small error or manipulation into a much larger security event at machine speed.
• Practitioners need task-scoped access, external enforcement, and full inventory visibility to govern agents safely.

Key terms

• Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Task-Scoped Access: Task-scoped access is permission granted for one defined purpose and removed once the task is complete or the session expires. For non-human identities, it reduces standing privilege and limits how long an attacker can exploit a stolen credential.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

What's in the full article

Noma Security's full article covers the operational detail this post intentionally leaves for the source:

• The article expands on the No Excessive CAP model and how to evaluate capabilities, autonomy, and permissions together.
• It explains the confused deputy pattern in agentic workflows with more detail on instruction-hijacking and hidden directives.
• It discusses how runtime enforcement and external control planes can sit between decision and execution in practice.
• It adds context from NIST and AWS submissions that is useful if you are building an implementation roadmap.

👉 The full Noma Security article adds the confused deputy discussion, NIST context, and deployment implications.

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 building or maturing an identity security programme, it is worth exploring.