Agent identity security needs runtime authorization, not just auth

At a glance

What this is: This is an analysis of agent identity security showing that authentication alone is insufficient when AI systems can take real actions across tools and data.

Why it matters: It matters because IAM, PAM, and governance teams need to bind delegation, intent, and session scope to agent actions before autonomous or human-approved workflows can create larger blast radius.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 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.

👉 Read PermitIO's analysis of agent identity security and runtime authorization

Context

Agent identity security is the discipline of proving which runtime is acting, who delegated authority to it, what workflow it is executing, and whether each action stays within the declared purpose. The problem is that modern AI agents can consume untrusted text and still exercise real permissions across tools, data stores, and business systems.

Traditional workload identity answers only part of the question. A cryptographic identity can confirm that the request came from the expected runtime, but it does not prove the agent is still doing the approved task, for the right tenant, with the right scope and intent.

That gap creates a governance problem for IAM, PAM, and lifecycle teams: the control plane has to evaluate delegation and purpose at runtime, not only at deployment or review time.

Key questions

Q: How should security teams implement agent identity controls in AI workflows?

A: Start by binding each agent action to a signed delegation envelope that includes the human owner, task, tenant, session, purpose, and expiry. Then enforce policy at every tool boundary so the runtime identity, scope, and intent are checked before execution. Workload identity is necessary, but it is not enough on its own.

Q: Why do AI agents make authorization harder than normal service accounts?

A: AI agents can change context mid-session, chain tools, and act on untrusted text that looks like instruction. That means the same runtime can move from a safe task to an unsafe one without any change in authentication. Authorization has to follow delegation and purpose, not just the process identity.

Q: What breaks when prompt text is treated like identity?

A: Prompt text is editable input, not a credential or a signed delegation. If security teams treat instructions in the prompt as proof of authority, prompt injection can turn untrusted content into real actions. The result is confused-deputy behaviour, where a legitimate agent uses valid permissions on behalf of the attacker.

Q: How do teams stop AI agent actions from exceeding task scope?

A: Use short-lived, resource-specific credentials and require policy checks at the gateway, tool adapter, and credential broker. If the task changes, the resource changes, or the purpose changes, the system should force a new authorization decision instead of reusing inherited access.

Technical breakdown

Workload identity proves the runtime, not the action

Workload identity establishes that a process, container, pod, or hosted runtime is the expected software entity. Standards such as SPIFFE and token-based federation are useful because they let downstream systems verify the caller cryptographically. But that proof stops at authentication. An authenticated agent can still be misused, over-scoped, or manipulated by prompt injection. In other words, the runtime may be genuine while the action is still illegitimate. That distinction matters because AI agents often operate across multiple tools, contexts, and tasks inside a single session.

Practical implication: require runtime authentication plus task-scoped authorization before any tool call is permitted.

Delegation context is part of the principal

For agents, the principal is not just the software runtime. It also includes the delegating human, the task, the tenant, the session, and the declared purpose. This is why a plain service account model is too weak for agentic workflows. The same authenticated runtime can legitimately act for one user and dangerously act for another if delegation is not bound to the request. Policy therefore needs structured claims that survive every hop, rather than prompt text that can be edited by untrusted content.

Practical implication: encode delegator, task, tenant, and purpose as enforceable claims in every agent action envelope.

Authorization has to be evaluated per action and per hop

Agents do not behave like single request, single response systems. They chain steps, accumulate context, and hand work to other services or agents. That means the authorization decision must be repeated at each enforcement boundary, not cached at workflow start. Token exchange and resource scoping are especially relevant because they allow narrower credentials to be issued as the task progresses. Without that, delegation chains silently expand blast radius and make downstream systems trust inherited authority that was never meant to persist.

Practical implication: place policy checks at the gateway, tool adapter, and credential broker, not only at the orchestrator.

NHI Mgmt Group analysis

Agent identity security is really a runtime authorization problem, not an authentication problem. The article shows why a valid workload identity still leaves the action question unanswered, because the same runtime can be steered by injected instructions or broad tool scope. That is the key governance shift for identity teams: proof of runtime is not proof of legitimacy.

Delegation context is part of the principal, and treating it as optional collapses accountability. Once agents act on behalf of a human, tenant, task, and purpose, a standalone service account becomes structurally incomplete. The field needs to stop describing agent identity as software identity plus policy and start treating delegation as part of the identity itself.

Intent drift is the named failure mode this post exposes. Purpose was designed for stable, human-paced authorization decisions. That assumption fails when an agent can re-plan mid-session, inherit new context, and execute a different tool path before any human review occurs. The implication is that identity governance must stop assuming a fixed intent window.

Shared service accounts are liability multipliers in agentic systems. When multiple humans or workflows share the same runtime identity, the delegation chain becomes opaque and the audit trail loses business meaning. That weakens both incident reconstruction and access accountability, which makes lifecycle governance part of the security control surface, not an administrative afterthought.

Runtime policy must outrank model output whenever the two diverge. The article makes clear that the model can propose actions, but policy has to decide whether those actions match task scope, consent, and resource constraints. That is the boundary between experimental AI usage and governable agentic identity.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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.
• That blind spot makes runtime delegation controls the next governance priority, and the broader framework view is laid out in OWASP Top 10 for Agentic Applications.

What this signals

Intent drift is becoming the practical limit of agent governance. As workflows become more multi-step, the programme question shifts from whether an agent can authenticate to whether every action still matches the original delegated purpose across the full session.

The next control battleground is enforcement close to execution. Teams that rely on orchestration-only checks will miss direct API calls, while teams that only think in terms of workload identity will miss delegation and consent drift. That is why runtime policy, token downscoping, and auditability have to move together.

With 98% of companies planning to deploy more AI agents within the next 12 months, the problem is not adoption pace but governance lag. Identity teams should prepare for broader policy coverage, not broader trust, and use the OWASP Top 10 for Agentic Applications as a threat-model baseline.

For practitioners

• Bind delegation to every agent task Create signed identity envelopes that carry delegator, tenant, task, session, purpose, and expiry, then require those claims on every tool invocation.
• Downscope credentials at each hop Exchange broad credentials for short-lived, resource-specific tokens as work moves from planner to retriever to tool adapter, so no downstream service inherits more authority than it needs.
• Separate data from authority in policy design Treat emails, documents, retrieved web pages, and tool output as inputs to reasoning only. Do not let untrusted content grant new rights, broaden scope, or alter the declared purpose.
• Log authority, not just API calls Record the delegator, workload identity, policy version, declared intent, prior access, and downstream delegation chain so investigators can reconstruct why each action was allowed or denied.
• Place enforcement at every execution boundary Check policy in the orchestrator, gateway, MCP or tool adapter, and credential broker so a direct API call cannot bypass the control plane.

Key takeaways

• AI agent identity security fails when teams stop at workload authentication and ignore delegated purpose.
• Runtime scope, intent, and session context are now the controls that determine whether an agent action is legitimate.
• Identity governance for agents has to shift from static approval to per-action enforcement and auditability.

Key terms

• Agentic Identity: The combined identity of an AI agent includes the runtime, the delegating human, the task, the tenant, the session, and the declared purpose. It is broader than a workload identity because it captures why the software is acting, not only which process is acting.
• Delegation Envelope: A delegation envelope is a structured set of claims that travels with an agent action and defines who delegated authority, what task is being executed, which resources are in scope, and when that authority expires. It turns intent into policy data instead of editable prompt text.
• Intent Drift: Intent drift is the failure mode where an agent begins one task and then shifts to a different purpose, resource set, or tool path without fresh authorization. In practice, it is the point where a previously valid action becomes misaligned with the approved business context.
• Confused Deputy: A confused deputy is a system with legitimate authority that is tricked into using that authority on behalf of an untrusted party. In agentic systems, the risk appears when untrusted content influences a powerful agent and the agent performs actions outside the original delegation.

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 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 Security: Authentication, Authorization, and Trust in AI Systems. Read the original.