Agent authorization gaps in Fortune 500 IAM leadership models

At a glance

What this is: This analysis shows that Fortune 500 identity organisations have matured structurally, but still lack a clear owner for runtime authorization decisions for AI agents.

Why it matters: IAM teams now have to extend governance from human and NHI access administration to runtime decisioning for agents that act with valid credentials and changing context.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read PlainID's analysis of runtime authorization for AI agent access

Context

Fortune 500 identity teams have moved from operational back office roles to executive-level ownership, but the primary governance gap is now different: deciding what an AI agent may do at the moment it acts. The article centres on agent authorization in enterprise IAM, where authentication is no longer the hard part and runtime decisioning is.

That matters because AI agents do not behave like static service accounts or human users. They can retrieve data, call tools, and continue execution within one session, which means access control has to evaluate context and intent at runtime. In regulated enterprises, this is now an identity governance problem, not just an application design issue.

Key questions

Q: How should security teams govern AI agents that can change actions at runtime?

A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path. If the system can select tools or alter its sequence mid-session, a static access policy is not enough. The control objective becomes contextual verification of what the agent is doing, why it is doing it, and whether the data touched matches the approved purpose.

Q: Why do AI agents create a different access-risk profile than traditional applications?

A: AI agents can chain actions, call multiple tools, and change behaviour based on context, so one credential can enable more than one operational path. That means the risk is not just whether the agent authenticates, but how far it can move once inside. The key measure is privilege scope, not token count.

Q: What breaks when identity teams rely only on login-time authorization for agents?

A: Login-time authorization breaks because it assumes the risky decision happens once, before execution starts. Agents may make several meaningful decisions after that point, including which data to read and which tools to call. If those choices are not re-evaluated at runtime, the policy no longer matches the actual action.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Why runtime authorization differs from traditional IAM checks

Traditional IAM checks answer a mostly static question: is this identity allowed to access this resource under the policy assigned at provisioning or login time? Runtime authorization changes the mechanism. It evaluates the action as it happens, combining actor, context, data sensitivity, tool scope, and sometimes downstream response content. That matters for AI agents because they do not just request access once. They can chain retrieval, invocation, and response generation in a single flow. A valid credential proves identity, but it does not prove the next action is safe. The control point moves from authentication to continuous decisioning at the moment of use.

Practical implication: teams need policy enforcement at the point of tool call and data retrieval, not only at login or token issuance.

Why policy-based access becomes a control plane for agentic AI

Policy-based authorization lets identity teams express rules in a form that can be evaluated across apps, APIs, data, and agent tools. For agentic AI, that is valuable because the actor may span multiple systems in one workflow. A single policy language can bind human approval, NHI credentials, and agent actions together, which is materially different from managing each application separately. The architectural issue is not just centralisation. It is consistency. Without a common policy layer, every tool integration becomes its own exception path, and the agent inherits whatever access the most permissive component allows.

Practical implication: reduce fragmented authorization logic by pushing common policy decisions into a shared runtime control layer.

Why standing credentials are not enough for autonomous access decisions

Standing credentials establish who or what the actor is, but they do not bound what it should do after authentication. That is especially weak for agents, which can retrieve context, select tools, and act in ways that were not fully knowable at provisioning time. This creates a governance mismatch. Least privilege is usually defined before execution starts, yet the agent’s actual path emerges during execution. That is why runtime authorization matters more than ever for agentic AI: the decision must track changing intent, not only initial entitlement.

Practical implication: treat standing access as insufficient whenever an identity can alter its action path during a session.

Threat narrative

Attacker objective: The objective is to get an agent to use legitimate access to perform higher-risk actions or disclose data beyond the intended runtime boundary.

1. Entry occurs when an AI agent authenticates with legitimate credentials and starts a normal session.
2. Escalation happens when the agent retrieves additional context, calls tools, or follows a prompt path that expands its effective scope mid-session.
3. Impact follows when the agent executes actions or exposes data that were never explicitly intended at provisioning time.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

Identity has outgrown the helpdesk model, but runtime authorization remains the missing ownership layer. Fortune 500 IAM is now executive, specialised, and security-aligned, yet the article shows no existing charter cleanly owns what an AI agent may do at the moment it acts. That is a governance gap, not a tooling gap. The practical implication is that identity programmes must treat authorization as a runtime control plane, not a provisioning afterthought.

Policy-driven authorization becomes the relevant control pattern when the actor can change its action path mid-session. Human users and standard service accounts usually operate within more predictable intent boundaries, but agents can retrieve, decide, and call tools in sequence. That means entitlement at issuance time is no longer enough to describe risk. Practitioners should recognise that the access decision must move closer to the action itself.

Least privilege defined at onboarding is too static for agentic behaviour. The article’s core problem is not broad access alone, but the fact that an agent’s future behaviour is not fully knowable before it runs. That breaks the assumption that policy can be frozen in advance and still remain accurate. The implication is that identity governance has to account for runtime context, not just assigned roles.

Agent identity governance will converge with NHI governance, but not disappear into it. The article makes clear that AI agents authenticate with real credentials and should be governed as identities, yet their decisioning behaviour introduces a runtime layer older NHI models did not need to solve. The field will need both NHI controls and agent-specific authorization logic. Practitioners should stop treating agent access as a simple extension of service-account management.

Runtime authorization is the named gap this article exposes. That gap sits between legitimate authentication and safe action execution. It is a distinct control problem because the actor is trusted enough to enter the environment, but not necessarily trusted to choose its next move. The implication is that enterprises need a policy model that can evaluate action, context, and sensitivity together at execution time.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• For the baseline control model, the Ultimate Guide to NHIs shows that only 5.7% of organisations have full visibility into their service accounts.

What this signals

Runtime authorization is becoming the practical dividing line for identity maturity. When agents can select tools and continue execution within a session, the old boundary between IAM and application logic starts to blur. Organisations that still treat authorisation as a login event will struggle to explain agent behaviour to auditors, especially where sensitive data or regulated workflows are involved.

Ephemeral agent decisions create governance pressure that legacy review cycles do not capture. A control framework built around periodic access reviews will miss the fact that the meaningful decision may occur and disappear inside one execution path. That is why runtime policy evidence, not only entitlement recertification, will become part of identity assurance.

Identity programmes that already struggle with NHI visibility should expect agent governance to magnify the same problem. Our research shows that only 19.6% of professionals are strongly confident in managing non-human workload identities, and that confidence gap will matter more as agents enter the same control environment. The programme signal is clear: policy coverage, auditability, and ownership now need to extend from service accounts to agent actions.

For practitioners

• Define runtime authorization ownership Assign a clear owner for agent authorization decisions inside identity or security architecture, not just application teams. The owner should be accountable for policy design, enforcement points, audit evidence, and exception handling across tools, APIs, and data paths.
• Map every agent to a decision boundary Document where each agent can retrieve data, call tools, and trigger downstream actions, then identify the exact policy check that should occur before each step. This exposes where standing access is still too broad and where policy enforcement is missing.
• Separate authentication from authorization in agent design Treat successful login or token issuance as identity proof only. Require a second decision layer that evaluates the requested action, the context, and the data sensitivity at runtime before the agent proceeds.
• Bind human intent to agent action When an agent acts on behalf of a person, preserve the human principal in the decision record and policy context so the environment can explain why the action was permitted. This is critical for auditability in regulated sectors.
• Instrument policy decisions for audit replay Log the inputs, policy version, decision outcome, and tool target for each agent action. The goal is to make the access decision reconstructable during incident review and regulatory evidence collection.

Key takeaways

• The article exposes a governance gap, not a procurement gap: no existing IAM charter cleanly owns what an AI agent may do at runtime.
• Agentic access changes the control problem because valid credentials do not explain or constrain the next action an agent will take.
• Practitioners need runtime authorization, clear ownership, and audit-ready decisioning if they want agent access to be defensible in regulated environments.

Key terms

• 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.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.

What's in the full article

PlainID's full analysis covers the operational detail this post intentionally leaves for the source:

• How the runtime authorization policy model is applied across applications, APIs, data, and agent flows
• What the control points look like when an agent must be bound to a human principal at decision time
• How Zero Standing Privileges is enforced when agent actions are evaluated in flight
• Which integration paths exist for policy enforcement close to the system boundary

👉 The full PlainID post covers the agent policy model, enforcement points, and audit trail design.

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 IAM programme, it is worth exploring.