Agent identity needs runtime permissions, not just authentication

At a glance

What this is: This analysis argues that agent identity is necessary for authentication, but runtime authorization is the control that determines whether an AI agent may actually act.

Why it matters: It matters because IAM, PAM, and NHI programmes must govern action-time decisions for agents, not just issue credentials at session start.

👉 Read PermitIO's analysis of agent identity and runtime permissions

Context

Agent identity is a form of non-human identity, but it behaves differently from a service account. The core problem is not whether the actor can authenticate, but whether it can be allowed to execute a specific action at the moment it tries to do so.

Traditional machine identity controls assume stable workloads and predictable privilege use. That assumption breaks when an AI agent can interpret goals, choose tools, and sequence work dynamically, which is why enterprise teams need to treat identity as an execution-governance problem rather than a login problem.

That shift also changes how teams should think about governance planes. Inventory, provenance, and credential issuance still matter, but they are only foundations unless they are paired with runtime policy enforcement for each tool call and each sensitive action.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern agentic systems with per-action authorization, not just with identity issuance. Each sensitive tool call needs a live policy decision that considers intent, resource, context, and trust tier. Without that control, an authenticated agent can still cross the line from approved assistance into unauthorized execution.

Q: Why do agent identities complicate zero standing privilege programmes?

A: Agent identities complicate zero standing privilege because their access needs can change during a single workflow. A static entitlement model assumes the required privilege is known in advance, but agentic behaviour can branch, retry, and expand scope. The practical answer is to mint narrow permissions just in time and retract them as soon as the task state changes.

Q: What breaks when runtime authorization is missing for AI agents?

A: What breaks is the separation between identity proof and permission to act. An agent can authenticate successfully, use valid credentials, and still perform the wrong tool call or an over-scope action if no action-time gate exists. That is how identity passes while damage still happens.

Q: Who should be accountable when an agent makes a high-risk decision?

A: Accountability should sit with the governance chain that approved the agent, the intent, and the scope, not with the agent alone. High-risk actions need a traceable delegation record that links the human approver, the allowed action, and the policy version in force when the step was taken.

Technical breakdown

Why agent identity is not the same as machine identity

Machine identity normally maps to a deterministic workload with relatively stable boundaries, while agent identity maps to a context-sensitive actor that can select tools and alter its next step based on prior results. That difference matters because privilege can no longer be reasoned about only at provisioning time. The control model shifts from broad entitlements to action-time decisions, where the exact tool, resource, and context determine whether execution is allowed. A service account may be over-privileged, but an agent can also be over-directed in the moment. Practical implication: treat agent permissions as task-scoped and enforce policy at the moment of execution, not only at account creation.

Practical implication: move from static entitlement design to per-action authorization for agentic systems.

DIDs and verifiable credentials provide trust roots, not runtime control

Decentralized identity and verifiable credentials give an agent a cryptographic root of trust, provenance, and revocation semantics. That improves issuer accountability and makes identity artifacts more auditable than ad hoc keys, but it does not answer whether a specific tool call should be approved right now. Runtime context can change after credentials are issued, especially when an agent branches mid-task or combines tools in a new sequence. The architectural gap is between proof of identity and permission to act. Practical implication: use DID and verifiable credentials as the authentication layer, then add live authorization checks for every sensitive action.

Practical implication: do not mistake strong identity proof for complete access governance.

MCP inventory is visibility, not enforcement

AI control towers and MCP server inventories help teams discover what exists, who owns it, and where it fits in the governance lifecycle. That visibility is necessary because unmanaged assets cannot be governed, but it does not stop an agent from attempting a high-impact write operation. Inventory answers the question of presence. Enforcement answers the question of permission. For agentic systems, those must be separate control planes. Practical implication: pair discovery and ownership workflows with a gateway policy layer that blocks or releases tool execution in real time.

Practical implication: separate asset governance from runtime enforcement so discovery does not become a false sense of control.

Threat narrative

Attacker objective: The attacker objective is to turn a legitimate agent session into an uncontrolled execution path that produces high-impact actions under valid identity.

1. Entry occurs when an agent is granted valid identity and access to tools, but the access model assumes the actor will remain within its original task boundaries.
2. Escalation happens when the agent selects additional tools or combines actions in a way that exceeds the intent originally approved by the delegator.
3. Impact follows when a sensitive write, cross-tenant action, or policy change is executed without a fresh runtime decision gate.

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

Agent identity has moved the control point from authentication to execution governance. The decisive question is no longer whether the agent can be trusted to log in, but whether each action should be allowed at the moment it is attempted. That shift collapses the value of identity-only thinking and elevates runtime authorization as the primary control for agentic systems. Practitioners should treat every tool call as a policy decision, not an inherited entitlement.

Zero standing permissions must now be applied to agent behaviour, not just to human administration. Agent sessions create a new form of standing access when broad tool scopes persist across a workflow. The more an agent can branch, retry, or chain actions, the more durable privilege becomes a hidden liability. Identity governance must therefore assume that task scope can drift during execution and that access should contract as soon as context changes.

Runtime authorization per action is the named control gap this architecture exposes. The old governance assumption was that identity issuance plus static RBAC could safely bound software actors. That assumption fails when an agent interprets goals and chooses tools mid-session because the privilege requirement is not knowable in full at provisioning time. The implication is that access models built for deterministic workloads need to be rethought around live decisions, not predeclared roles.

Delegated access needs an accountability chain, not just a credential. When an agent acts on behalf of a human, the critical control object is the binding between principal, intent, scope, and trust tier. Without that binding, delegated access becomes disguised standing access with weak audit value. The governance task is to make the delegator, the declared purpose, and the allowed action inseparable in policy logic.

The market is converging on enforcement as the missing layer in agent security. Discovery, provenance, and identity issuance are necessary, but they do not close the gap between knowing an agent exists and controlling what it can do. This is where NHI governance, PAM discipline, and agentic AI controls are starting to overlap. Practitioners should expect tooling strategies to shift toward policy enforcement at the gateway, not just identity registration.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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, according to AI Agents: The New Attack Surface report.
• For teams building the next control layer, OWASP Agentic AI Top 10 is the right starting point for mapping tool-use, authority, and execution risk.

What this signals

Runtime authorization is becoming the real control plane for agentic identity. Teams that stop at inventory and credential issuance will keep finding that authentication succeeded while execution still went wrong. The programme shift is toward policy decisions at the moment of tool use, especially where sensitive writes, tenant boundaries, or approval workflows are involved.

Agent identity changes how privilege creep should be measured. The question is no longer only how many credentials exist, but how much execution power remains available after the workflow starts. That means governance teams need to track permission contraction, approval binding, and revocation latency as operational metrics, not afterthoughts.

Ephemeral access debt: this is the accumulating risk created when agents receive short-lived access that is still too broad, too fast, or too hard to revoke at runtime. As agent adoption grows, programmes should expect more policy logic to move into gateways, and more identity evidence to be tied directly to action-time decisions.

For practitioners

• Map every agentic workflow to a runtime decision point Identify where the agent can choose tools, retry actions, or branch into new tasks, then insert a policy check before each sensitive step. The goal is to make action-time approval explicit for writes, cross-tenant calls, and privileged operations.
• Separate discovery from enforcement Keep AI asset inventory, ownership, and lifecycle records, but do not confuse them with execution control. A discovery catalogue is useful only when a gateway or policy engine can deny the tool call before the agent executes it.
• Bind delegated access to human intent and trust tier Record the human principal, agent principal, declared intent, approved resource, and trust classification in one machine-verifiable envelope. That prevents blanket delegation from becoming durable standing access across long-running tasks.
• Design for rapid revocation and permission contraction When context changes, permissions should shrink immediately from write to read, from broad tool access to a narrow subset, or from allowed to denied. Revocation needs to live in the runtime path, not in an admin console workflow that lags execution.

Key takeaways

• Agent identity is not enough on its own because authentication does not stop an agent from selecting the wrong tool or taking an over-scope action.
• The scale of the governance gap is already visible, with most organisations saying agent governance matters but fewer than half having policies in place.
• Teams should shift from credential-centric controls to runtime authorization, delegated intent binding, and immediate revocation in the execution path.

Key terms

• Agent Identity: An agent identity is the identity used by a software actor that can interpret goals and choose actions during runtime. It is not just a login credential for a workload. In practice, it must be governed as an execution-capable principal with task scope, intent binding, and live authorization checks.
• Runtime Authorization: Runtime authorization is the decision made at the moment an action is attempted, rather than when access is first issued. For agentic systems, it is the control that determines whether a specific tool call, write action, or delegation step is allowed under the current context.
• Zero Standing Permissions: Zero standing permissions means an actor holds no durable broad privileges between tasks. Access is issued only when needed, scoped tightly to the action, and removed or contracted when the task ends or the context changes. For agents, this is a behavioural control as much as an access model.
• Delegated Intent: Delegated intent is the machine-verifiable statement of what a human authorised an agent to do, for which purpose, and within which scope. It becomes a governance boundary when linked to the principal, the resource, the trust level, and the policy version active at the time of execution.

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 PermitIO: Agent Identity Is Not Enough: From DIDs and AI Control Towers to Runtime Permissions. Read the original.