Agent identity security needs runtime authorization, not just auth

At a glance

What this is: This is a deep-dive on agent identity security that says workload identity alone is not enough, because AI agents need runtime authorization tied to delegated purpose, task scope, tenant, and session.

Why it matters: It matters because IAM and PAM teams now have to govern actions, not just logins or service principals, as AI agents can browse, call APIs, and write back into systems.

Context

AI agent identity security is the problem of proving not only that an agent runtime exists, but also that each action is authorized for the delegated task, tenant, and purpose. In practice, this is where traditional workload identity stops short, because a signed runtime can still be steered into the wrong action by prompt injection, scope drift, or overbroad tooling.

The article argues that AI agents turn authorization into a runtime decision problem rather than a static credential problem. For identity programmes, that means the control question shifts from “is this process authentic?” to “is this specific action legitimate under the current delegation and policy state?”

Key questions

Q: What breaks when workload identity is treated as enough for AI agents?

A: Authentication alone breaks the moment a trusted agent can choose among multiple tools or actions. The real gap is authorization: the system knows who the agent is, but not whether it should read, write, escalate, or chain into another service for the current task. That is why identity proofing without policy control leaves a dangerous gap.

Q: Why do AI agents create more authorization risk than static service accounts?

A: AI agents can vary their access needs by task, context, and timing inside the same workflow, which makes static entitlement assumptions weaker. If the control model assumes access is stable, it will either overgrant by default or block legitimate work. That is why fine-grained, real-time evaluation matters.

Q: What signals show that an AI agent is operating outside its intended purpose?

A: Look for mismatches across identity, data, model behaviour, posture, and environment. A clean authorization trail is not enough if the agent starts touching unrelated data, follows injected instructions, drifts from its known configuration, or continues acting in a way that does not fit the task.

Q: How should teams respond when an AI agent can read, browse, and write back into systems?

A: Treat every tool invocation as a governed authorization event, not a passive API call. Use short-lived, purpose-bound tokens, validate the full delegation context, and deny actions that are not explicitly consistent with the current task and resource constraints.

Technical breakdown

Why workload identity is necessary but not sufficient

Workload identity proves that a process is the expected runtime, usually through cryptographic attestation such as SPIFFE-style identities. That solves impersonation of the runtime, but it does not say whether the runtime is acting within the delegated task, tenant, or purpose. An AI agent can be authenticated and still misuse valid access if the action is outside the approved scope. The security gap is not identity proofing alone, but the absence of runtime authorization that evaluates context, delegation, and intent before each tool call.

Practical implication: Treat workload identity as the starting point and enforce separate policy checks for every agent action.

How delegated intent becomes an authorization claim

The article’s core distinction is between the runtime and the reason. An agentic identity needs structured claims for delegator, session, task, tenant, resource constraints, allowed tools, and expiry, rather than free-text prompts or vague workflow labels. That turns intent into an enforceable policy attribute, not a suggestion buried in model context. Once intent is machine-readable, policy can compare the requested action against the declared purpose and reject scope drift before execution. Without that, prompt injection can repurpose a legitimate agent into an attacker-controlled deputy.

Practical implication: Bind each agent task to signed, structured intent claims and deny any action that falls outside them.

Why prompt injection becomes an authority problem

Prompt injection is dangerous because it confuses data with authority. Untrusted content in emails, documents, web pages, or tool outputs can shape an agent’s next step, and the agent may then act using real permissions. That is a classic confused deputy pattern, but with higher blast radius because agents can chain reads, writes, API calls, and outbound requests. The control failure is not merely bad text handling. It is the lack of separation between what the model sees and what the policy engine is allowed to approve.

Practical implication: Put a policy decision point between model output and tool execution so untrusted text never grants authority.

Threat narrative

Attacker objective: The attacker wants a legitimate agent to perform an action that the user never properly delegated, such as exposing data, changing records, or moving across tenant boundaries.

1. Entry happens when untrusted text reaches the agent through prompts, retrieved documents, emails, or tool output and changes the next action the model proposes.
2. Credential and access abuse follows when the runtime uses legitimate workload identity and delegated permissions to call tools or APIs outside the intended task.
3. Impact occurs when the agent performs an unauthorized read, write, or export that expands blast radius through real business systems.

Breaches seen in the wild

• 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.
• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

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, not workload identity, is the control boundary that matters for AI agents. A signed runtime tells you which process is speaking, but it does not tell you whether the action matches the delegated task, tenant, or purpose. That assumption breaks as soon as the actor can choose tools and timing at runtime. The implication is that agent governance has to move from proving identity once to evaluating legitimacy on every action.

Prompt text is not an identity primitive. Treating system prompts or natural-language instructions as authorization creates a policy layer that attackers can edit through retrieved content and indirect injection. The model may be the reasoning engine, but it is never the source of authority. Practitioners should treat this as an authority-confusion problem, not a content-filtering problem.

Delegation chains create blast radius unless every hop downscopes authority. When one agent hands work to another, the original permissions can easily be inherited too broadly, and accountability becomes opaque. That is why token exchange, resource scoping, and purpose binding matter together. The practitioner takeaway is that no agent-to-agent hop should inherit more authority than the next step actually needs.

Agentic identity is a new named concept because it combines the principal, the task, and the reason. The article’s strongest insight is that an AI agent is not just software with credentials; it is a delegated actor whose legitimacy depends on context. That reframes identity security for AI from authentication hygiene to runtime governance, and it gives security teams a concrete model for policy design.

Policy must be boring, deterministic, and closer to enforcement than the model is. Agents are probabilistic and context-sensitive, but authorization cannot be. The separation of model, policy, and credential issuance is what keeps an authenticated agent from becoming a confused deputy. Security teams should design for denial by default when the runtime envelope and the requested action do not align.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Identity Guide

What this signals

Agentic identity is becoming the missing governance layer between authentication and action. As agents move from read-only assistants to systems that can browse, call APIs, and write records, the practical question is no longer whether the runtime is genuine. It is whether the runtime is still acting within the authority that was actually delegated.

Purpose-bound control is the real control plane for AI agents. Runtime authorization has to travel with the task, not the model session, because prompt injection and orchestration drift both exploit the gap between trusted runtime and untrusted intent. That makes action-level policy, not text filtering, the security boundary that identity teams have to own.

For practitioners

• Define an agentic identity envelope Capture delegator, tenant, task, session, purpose, tool scope, resource constraints, and expiry as signed claims for every agent run.
• Separate model output from authority Place a policy decision point between model proposals and tool execution so untrusted text cannot authorise downstream actions.
• Downscope every agent-to-agent hop Use token exchange and narrow resource-scoped tokens for each delegated step instead of allowing inherited broad access.
• Interrogate the full identity envelope at enforcement points Require each boundary to validate who delegated the task, what purpose is claimed, what has already been accessed, and whether the next action fits the scope.

Key takeaways

• AI agents expose a governance gap that workload identity alone cannot close, because a valid runtime can still perform an invalid action.
• The article’s central control idea is runtime authorization bound to delegator, task, tenant, session, and purpose, not just to a software principal.
• For IAM and PAM teams, the practical shift is from authenticating the agent to governing each action it attempts to take.

Key terms

• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• 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.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads, causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.