AI agent blast radius now depends on identity, not just code

At a glance

What this is: Veza argues that AI agent blast radius is now an identity problem, because agents with delegated permissions can expand impact across data, APIs, and other agents even when code flaws are found faster.

Why it matters: IAM, PAM, and NHI teams need to govern agent identity and effective access as a separate control plane, because code hardening does not contain runtime reach.

Context

AI agent blast radius is the amount of damage an agent can cause based on its effective permissions, not just the code it runs. The governance gap is that many programmes still treat application security and identity security as separate problems, even though autonomous agents can invoke tools, write code, and delegate actions across systems.

This article is about the control plane around AI agents: who or what they are authorised to access, what they can do on behalf of a user or workload, and how far that reach extends across other agents and enterprise resources. That is a classic identity governance problem, but one with autonomous behaviour layered on top of it.

The source uses Anthropic’s Project Glasswing as the trigger, but the operational question is broader: once discovery gets faster, what constrains the agent’s effective access when runtime decisions move faster than human review cycles?

Key questions

Q: What breaks when AI agents have broader access than their tasks require?

A: Over-privileged agents break segregation of duties, weaken auditability, and expand blast radius across transactions, data lookups, and workflow triggers. In banking, a single agent identity can act with more operational reach than any human reviewer can safely justify.

Q: Why do AI agents make least privilege harder to enforce?

A: AI agents can move across multiple services, make autonomous decisions, and trigger several machine-to-machine actions in one task. That creates more opportunities for privilege creep, overuse, and lateral movement. Least privilege is harder when the system must authorise not only who is acting, but what the agent is doing right now.

Q: What are the signs that agent-to-agent delegation is creating privilege drift?

A: Look for sub-agents acting with broader authority than the initiating user intended, especially when tokens pass downstream unchanged and audit logs show only the user. That pattern usually means scope attenuation is missing at one or more hops in the chain.

Q: How should teams govern AI agent identity across cloud platforms and production systems?

A: They should treat each agent as a governed identity with explicit access boundaries, session rules, and revocation points. The control objective is to keep production reach aligned to task scope across cloud platforms, because delegated agent access becomes dangerous when it is durable and diffuse.

Technical breakdown

Effective access determines AI agent blast radius

For AI agents, blast radius is defined by effective access, meaning the permissions actually usable at runtime across data, APIs, workloads, and downstream systems. A role or policy on paper is not enough if the agent can chain tools, inherit delegated access, or reach resources through another identity. That makes identity graph visibility critical because the security question becomes what the agent can do right now, not what it was intended to do at provisioning time.

Practical implication: model agent reach from effective access, not from static role names.

Agent-to-agent authorisation creates secondary blast radius

When one agent can invoke or hand off to another, the risk is no longer limited to the first identity that authenticated. Inter-agent authorisation creates a propagation path where a small permissions error can become a wider execution path through chained tools and delegated tasks. This is why runtime governance has to account for both direct permissions and the authority to cause action in adjacent agents.

Practical implication: inventory and constrain agent-to-agent delegation paths, not just user-to-agent approvals.

Least privilege for autonomous agents is a runtime control problem

Least privilege is harder for agents because intent can change during execution, especially when the agent is long-lived, tool-rich, and operating inside a persistent session. Static provisioning assumes the actor’s use case is known in advance, but agentic workflows can shift scope mid-task as new data, prompts, or tool outputs appear. The control challenge is therefore the gap between assigned permission and actual action scope.

Practical implication: enforce narrow, task-scoped permissions that match the session boundary and the tool set in use.

Threat narrative

Attacker objective: The objective is to turn delegated agent access into a larger operational blast radius that reaches data, infrastructure, or other agents beyond the original control boundary.

1. Entry occurs when an AI agent is granted delegated access to tools, APIs, or infrastructure with permissions broader than the immediate task requires.
2. Escalation happens when the agent can chain those permissions across resources or hand off to another agent, expanding the reachable trust boundary.
3. Impact follows when a compromised or misdirected agent can write code, invoke production actions, or expose sensitive data through its effective access.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.
• 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

AI agent governance now has an identity centre of gravity: the decisive security variable is no longer only whether a model can find a flaw, but what an agent can reach once it is authorised to act. That shifts control ownership from code-only security teams to identity governance, PAM, and cloud access owners. The practical conclusion is that agent identity must be treated as a first-class control object, not a secondary attribute of the application stack.

Effective access is the right unit of control for agentic systems: static role assignment hides the permissions an agent can actually exercise across resources and peer agents. The Access Graph idea in this article is directionally correct because effective permissions reveal the real blast radius. Practitioners should think in terms of reachable actions, not just assigned roles, because runtime reach is what determines containment.

Agent-to-agent delegation creates an access graph, not a single identity event: once one agent can hand off or invoke another, governance becomes relational. That means approval, traceability, and containment have to extend across the delegation chain, not stop at the first authenticated principal. For practitioners, the key question is which downstream identities inherit risk when the first agent is compromised or misled.

Least privilege for autonomous agents is not a static provisioning assumption: least privilege was designed for actors whose access profile is stable enough to define in advance. That assumption weakens when an autonomous agent selects tools and executes actions at runtime, because intent and scope can drift within the same session. The implication is that privilege must be governed against live behaviour, not only against pre-committed entitlements.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Effective access is now the practical unit of agent governance: programme owners need to know what agents can actually touch, not what the policy says they were meant to touch. That is a different operating model from traditional app security because runtime reach, delegated authority, and cross-agent inheritance all affect containment.

Agent blast radius will keep expanding unless identity controls move closer to execution: the more persistent and autonomous the session, the less useful static review cycles become. Teams should watch for long-lived agent sessions, multi-agent handoffs, and production permissions that outlast a task boundary.

For practitioners

• Map effective access for every agent Build an inventory of the actual resources, APIs, datasets, and downstream agents each AI agent can reach, then compare that reach to its declared purpose.
• Separate user approval from agent authority Document where human approval ends and where agent execution begins, especially for long-running sessions and delegated workflows that can continue without fresh review.
• Constrain agent-to-agent delegation paths Reduce the number of agents that can invoke, task, or inherit permissions from other agents, and identify where handoffs expand the blast radius.
• Treat production actions as task-scoped privilege Limit write, deploy, and infrastructure permissions to the smallest feasible session window, then revoke them when the task boundary ends.

Key takeaways

• AI agent security is no longer only a code-hardening problem because runtime permissions determine how far an agent can act once it is authorised.
• The practical evidence in the article is that vulnerability discovery is accelerating while governance of delegated access and agent-to-agent reach still lags.
• Containment depends on effective access, task-scoped privilege, and explicit delegation boundaries rather than on model capability alone.

Key terms

• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• Agent Blast Radius: Agent blast radius is the amount of damage an AI agent can cause if it is compromised, misconfigured, or behaves unexpectedly. It includes the systems, data, identities, and actions the agent can reach through its permissions, tool access, and network paths, and is reduced by least privilege, segmentation, and strong controls.
• Agent-to-Agent Delegation: Agent-to-agent delegation is the handoff of work from one AI agent to another, often across different tools or identity contexts. It expands the governance boundary because the original actor no longer controls every action, and inherited permissions can create risk that the first approval never covered.
• Session-scoped privilege: Access that exists only for the current task or execution window and is removed when the session ends. For autonomous or agentic systems, this reduces standing privilege but also shifts the burden to runtime controls, because the identity may not persist long enough for traditional review cycles.

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.