Agent identity needs runtime permissions, not just authentication

At a glance

What this is: This article argues that agent identity is an execution-governance problem, because authentication alone cannot control what an autonomous software actor does after session start.

Why it matters: IAM, IGA, and PAM teams need to treat AI agents as runtime principals whose permissions must be bound to intent, context, and action, not just issued once at login.

Context

Agent identity is a governance problem when the subject can interpret goals, select tools, and continue executing after initial authentication. In that model, the security question is not whether the actor can log in, but whether each action remains authorised as the task evolves.

Traditional non-human identity approaches assume relatively stable behaviour and predictable privilege use. The article argues that this assumption breaks for agents, because a single authenticated session can branch into multiple tool calls, higher-risk actions, and scope drift that static access models do not anticipate.

Key questions

Q: How should security teams govern agent identities differently from service accounts?

A: Security teams should treat agent identities as a separate governance class when the software can choose tools, initiate actions, or continue work without a human approval gate. Service accounts usually follow predefined access paths, while agents need runtime constraints, delegated authority limits, and stronger accountability for each action path.

Q: Why do autonomous agents create more risk than traditional application accounts?

A: Autonomous agents create more risk because they can change scope while they are running. A traditional application account usually follows a stable pattern, but an agent can chain tools, expand into new systems, and act faster than a human can intervene. That makes runtime authorization, not just provisioning, the core control problem.

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: What is the difference between machine identity and AI agent identity?

A: Machine identity is the broader technical identity used by software systems to authenticate and authorize access. AI agent identity is a subtype that also needs constraints on tool use, action scope, and rollback because the agent can make decisions and trigger downstream actions. Agent identity therefore needs tighter behavioural controls than a standard workload identity.

Technical breakdown

Why agent identity changes the authorization model

Agent identity differs from classic machine identity because the actor can make runtime choices about sequence, tools, and timing. That means the control point moves from proving who the principal is to deciding whether each action still fits the declared intent and current context. A session can start cleanly and still become unsafe if the agent pivots to a new tool, a new resource, or a new business objective. Identity proofing is therefore necessary, but it is not sufficient for control.

Practical implication: treat authentication as the start of governance, not the end of it.

Why DIDs and verifiable credentials are foundations, not enforcement

Decentralized identifiers and verifiable credentials give an agent a cryptographic identity and better provenance, which improves trust in who issued what. But they do not automatically answer whether a specific write, transfer, or delegation is allowed at the moment the action is requested. That gap matters because the agent’s plan can change mid-session, while the credential remains technically valid. In other words, strong identity issuance does not equal safe execution policy.

Practical implication: pair identity credentials with live policy decisions for every sensitive action.

Why inventory alone cannot govern agent execution

An AI control tower or asset inventory can tell teams what agents, prompts, models, and MCP servers exist, and who owns them. That is important governance memory, but it is not an enforcement layer. Runtime authorization must still sit in front of the tool call, because inventory cannot stop an approved agent from making an unapproved request. The architectural split is between visibility and execution control, and the latter is the decisive control for agentic systems.

Practical implication: use discovery to map the estate, then enforce policy at the point of execution.

Threat narrative

Attacker objective: The objective is to get a legitimate-looking agent session to perform actions outside the scope that the organisation meant to authorize.

1. Entry occurs when an autonomous actor is granted a valid identity and begins a session with trusted credentials and an initial scope.
2. Escalation occurs when the agent branches into new tools, new resources, or higher-risk actions that were not fully predictable at issuance time.
3. Impact occurs when a sensitive action is executed under the original trust context even though the current intent or risk posture has changed.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

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

Runtime authorization is now the control plane for agent identity. Authentication answers who the actor is, but autonomous behaviour determines what that actor can do after login. That shifts the governance problem from issuance to execution, and identity teams that stay focused on session start will miss the actual risk boundary. Practitioners should reframe agent governance around action-time policy.

Identity proofing alone does not constrain agent intent drift. A DID or verifiable credential can prove provenance and support auditability, but it does not stop a model-driven actor from changing tool choice or task scope mid-session. The broken assumption is that the privilege decision made at enrolment remains valid throughout execution. Practitioners need to treat intent as a live governance variable, not a static entitlement.

Agent identity exposes a runtime authorization gap that classic NHI models were not built to close. Service accounts are generally provisioned for stable, bounded behaviour; agents are adaptive and can chain actions without predictable human pacing. That means least privilege cannot be treated as a one-time setup exercise. Practitioners should expect the decisive control to move from account creation to per-action enforcement.

Asset inventory without policy enforcement produces governance theatre. AI control towers and similar discovery layers help teams know what exists, who owns it, and what lifecycle state it is in. But they do not prevent over-scope writes, cross-tenant access, or wrong-tool execution once a session is underway. The practical lesson is that visibility and enforcement must be designed as separate planes.

Runtime permissioning is the named concept this category now needs. Agent identity should be understood as a governed execution surface where permissions are minted for the current action, not assumed for the whole session. That concept matters because it captures the operational reality of autonomous actors better than static identity language does. Practitioners should align governance, logging, and approval flows to the action layer.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime permissioning will become the practical boundary for agent governance. Organisations that keep treating agent identity as an onboarding problem will end up with controls that look complete on paper but fail at execution time. The more autonomous the actor, the more policy has to move from provisioning into the live decision path.

Permission drift is the operational signal teams should watch. If an agent can expand from low-risk reads into writes or cross-tenant actions without a fresh decision, the programme is relying on trust that is no longer current. That is where identity governance has to stop being about who the agent is and start being about what the agent is allowed to do right now.

19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey. That gap shows how quickly agent identity can outrun existing governance models when teams assume the old NHI playbook is enough.

For practitioners

• Define action-time policy boundaries for agents Classify which agent actions are low, medium, and high risk, then require a live policy decision before any sensitive write, delegation, or cross-tenant action.
• Bind delegation to declared intent Require each agent session to carry a machine-verifiable intent, resource scope, and human delegator so permissions cannot drift into disguised standing access.
• Separate visibility from enforcement Use discovery and inventory to map agents, MCP servers, and owners, but place an enforcement point in front of every tool call.
• Make revocation continuous Design the control path so permissions can contract or fail closed when context changes, approval expires, or trust signals degrade.
• Set step-up controls for high-risk writes Require stricter checks and explicit approval for policy changes, financial writes, and other irreversible actions rather than authorising the full session.

Key takeaways

• Agent identity is not just a new label for software accounts. It changes the governance problem because the actor can decide and re-decide at runtime.
• Static access models do not hold up well when an authenticated agent can branch into new tools, new scopes, or higher-risk actions mid-session.
• The decisive control is per-action authorization, backed by continuous revocation, clear delegation context, and enforcement in front of the tool call.

Key terms

• 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.
• 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.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.

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.