Runtime access control for AI agents: why over-permissioning persists

At a glance

What this is: PlainID says AI agents are routinely over-permissioned through shared accounts, broad retrieval, and tool access that outstrips their task scope.

Why it matters: IAM and security teams need to treat agent authorisation as a runtime control problem, because static provisioning cannot contain identities that change behaviour within a session.

By the numbers:

• Gartner puts the ratio of machine identities to human identities at 82 to 1.

👉 Read PlainID's analysis of runtime access control for AI agents

Context

Enterprise AI agents often inherit permissions from shared service accounts, broad API keys, or retrieval layers that do not verify the requester. The result is not simply excessive access at provisioning time, but access that accumulates across tool use, database queries, and downstream API calls.

For identity teams, the problem is that the access decision is made too early and too narrowly. Once an agent can change tools, data sources, or actions within one session, authorisation has to follow behaviour rather than rely on the permissions that were attached when the agent was first created.

The article focuses on AI agents as non-human identities because their risk comes from machine-to-machine access paths, not from human login friction or endpoint compromise. That makes this an authorisation and governance problem as much as a design problem.

Key questions

Q: What breaks when AI agents inherit access from users and service accounts?

A: The main failure is that inherited access can be broader than the agent’s actual task, so privilege becomes easier to reuse than to govern. Once an agent can chain tool calls across systems, the original approval no longer describes the full blast radius. Security teams need to treat inherited access as a live identity surface, not a one-time provisioning artifact.

Q: Why do AI agents increase the risk of overpermissioning?

A: AI agents increase that risk because teams often expand scopes to unblock early use cases, then keep those permissions because the original need is hard to prove or remove. The access model becomes broader over time, and the agent inherits more privilege than anyone intended.

Q: How do security teams detect when runtime authorisation is failing for agents?

A: Look for agent actions that succeed because a credential is broadly valid, not because the action was explicitly approved. Warning signs include alternate-token discovery, destructive tool calls outside the original task, and audit logs that show only credential use rather than a human-approved decision path.

Q: What is the difference between static policy and runtime control for AI agents?

A: Static policy states what the agent should be allowed to do, while runtime control determines what it can actually do at the moment of execution. For autonomous systems, that distinction matters because the security risk appears in live action, not just in configured permissions.

Technical breakdown

Shared service accounts turn agent scope into inherited privilege

When an AI agent is routed through a shared service account, the agent inherits whatever that account can do, not what the current task requires. That pattern is common because it avoids credential requests and engineering friction, but it destroys the link between identity and intended use. The access surface then includes databases, APIs, and application functions that were never evaluated against the agent's actual job. In governance terms, the identity becomes an ambient permission container rather than a purpose-bound executor.

Practical implication: Prune shared account usage and map every agent to the exact resources it genuinely needs.

Runtime authorisation is different from login-time authorisation

Traditional IAM is strong at authenticating an identity at the door, but agents need continuous decisions after entry. An agent can begin with a benign request and later pivot to database reads, tool calls, or chained actions that were never intended at login time. RBAC and even ABAC can miss that drift if they evaluate once per session. The technical shift is to policy enforcement at request time, with context carried through each retrieval, tool invocation, and API action.

Practical implication: Move authorisation checks into the execution path so each agent action is evaluated in context.

MCP expands tool reach faster than policy can keep up

Model Context Protocol makes tools easier for agents to discover and call, which is useful operationally but dangerous when discovery is not paired with strict authorisation. If every reachable tool is treated as an allowed tool, the infrastructure topology becomes the policy boundary. That means new tools can inherit broad access implicitly, even when nobody has reviewed the business purpose or data sensitivity. Category-based policy is stronger than per-tool exception handling because it can govern new tools as they appear.

Practical implication: Classify MCP tools by business function and bind policy to the category, not the individual tool name.

Threat narrative

Attacker objective: The attacker wants to turn an over-permissioned agent into a path to sensitive data, unauthorised actions, or both.

1. Entry begins when an AI agent is provisioned through a shared service account, inherited role, or overly broad API path that exceeds its actual task scope.
2. Credential or access abuse occurs when the agent can reach sensitive data sources, tools, or APIs without checking whether the current request is authorised for that context.
3. Escalation follows when the agent chains tool calls or retrieval steps, turning one permitted action into broader downstream access or an unauthorised operation.
4. Impact is exposure of data or execution of actions that no one would have approved had the full session path been reviewed in real time.

Breaches seen in the wild

• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Composite identity authorization is now a governance requirement, not an architectural nice-to-have. The article shows that an agent acting on behalf of a human cannot be governed by either identity alone. That intersection matters because a senior user's privileges can become an agent's unintended superpower, while the agent's own reach can exceed the user's intent. Practitioners should treat composite identity as the unit of authorisation for agent workflows.

Zero Standing Privilege is the correct mental model for autonomous execution paths. Static assignment assumes that access can be granted once and reviewed later, but agent behaviour is session-shaped and often transient. The model breaks when access persists long enough to be exploited but not long enough to be meaningfully reviewed. Practitioners should assume that any standing access granted to an agent is already a governance exception.

Ephemeral access governance is the more accurate control concept for agentic systems. The article's central insight is that agent permissions are not just excessive, they are temporally misaligned with use. That creates a governance gap where access exists before need, survives after need, and may never be revalidated against intent. Practitioners should rethink authorisation around moment-of-use decisions rather than static entitlements.

Runtime policy evaluation must replace the false comfort of provisioning controls. The article makes clear that discovery, retrieval, tool invocation, API execution, and output masking are separate control points. That means one control failure can no longer be assumed to protect the others. Practitioners should design for enforcement across the full flow, not only at account creation or login.

Machine identity sprawl is now the default condition of enterprise AI. With machine identities vastly outnumbering humans and agents often inheriting broad permissions, the governance problem is no longer exceptional. It is structural. That shifts the burden from proving whether agents need access to proving why they ever needed standing access at all. Practitioners should re-baseline authorisation reviews around non-human identity scale.

What this signals

Composite identity is the control boundary that agentic governance keeps missing: if the human, the agent, and downstream agents are authorised separately, policy can be bypassed by chaining behaviour. Access control has to evaluate the whole delegation path, not just the login event.

Runtime policy is the real checkpoint for agentic systems: provisioning-time controls cannot keep pace with agents that retrieve, classify, and act multiple times in one session. The governance task is to make every sensitive step independently authorisable before the action occurs.

For practitioners

• Map every agent to its effective privilege path Inventory the service accounts, API keys, databases, and tool categories each agent can reach today. The point is to expose inherited access that came from sprint-era shortcuts or reused identities, not to document the intended design on paper.
• Move authorisation to the point of use Evaluate each retrieval, tool call, and downstream API action at runtime with current context, not only at login. This is the only way to stop session drift from turning a benign request into an unauthorised action.
• Bind human and agent identities together Treat the human requester, the originating agent, and any downstream agent chain as a single access decision. If the intersection is not authorised, the request should fail even when one identity in the chain would otherwise pass.
• Classify MCP tools by business category Group tools by sensitive function, such as financial reporting or customer data access, so policy follows the category when new tools are added. That prevents tool discovery from becoming de facto authorisation.
• Remove standing access from ephemeral agents If an agent exists for a single task, it should not carry persistent privileges beyond that task. Use behaviour-based policy for short-lived identities and avoid static agent assumptions that outlast the session.

Key takeaways

• AI agents become risky when they inherit broad access from shared identities rather than being scoped to a specific task.
• The article shows that over-permissioning is not a fringe mistake but a structural pattern across retrieval, tool use, and API execution.
• The decisive control is runtime authorisation at the moment of use, because static provisioning cannot keep up with agent behaviour.

Key terms

• Composite Identity: An identity made up of more than one control relationship, typically a human owner, an AI agent, and the credentials or services the agent uses. It matters because accountability, access scope, and runtime behaviour all have to be governed together, not as separate problems.
• 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.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• MCP Tool Description: A MCP Tool Description is the structured definition of a tool that an AI agent can discover and call through the Model Context Protocol. It specifies the tool name, purpose, inputs, outputs, and constraints in machine-readable form, so the agent can invoke external capabilities safely and consistently during execution.

What's in the full article

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

• The five-stage Full-Flow AI Guardrails model, including input checks, retrieval filtering, tool invocation, API runtime authorisation, and output masking.
• Implementation guidance for composite identity authorization across a human requester, an agent, and downstream agent chains.
• Policy-based access control examples that show how to enforce decisions in under 60 seconds.
• The role of an authorization graph in auditing what an agent could see, touch, or trigger.

👉 PlainID's full article covers the five guardrails, composite identity authorization, and policy design details.

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