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

At a glance

What this is: The article argues that faster vulnerability discovery must be matched by identity governance for AI agents, because blast radius now depends on delegated permissions as much as code quality.

Why it matters: IAM, PAM, and NHI teams need to govern agent identities, effective access, and agent-to-agent authorization before autonomous systems expand the attack surface beyond what code scanning can constrain.

By the numbers:

• Anthropic recently found a 27-year-old vulnerability in OpenBSD and a 16-year-old flaw in FFmpeg that traditional automated tools had missed.
• 17 minutes

👉 Read Veza's analysis of AI agent blast radius and least privilege

Context

AI agent blast radius is the amount of damage a model-driven system can cause through the permissions it holds, the resources it can reach, and the other identities it can influence. The article’s central point is that vulnerability discovery is improving faster than governance for agent identity, delegated access, and cross-agent authorization.

That matters because AI agents are no longer just code running in a pipeline. When they can invoke APIs, write code, manage infrastructure, and interact with other agents, existing IAM assumptions about stable operators, pre-declared intent, and simple access paths start to break down.

Key questions

Q: What breaks when AI agents are given broad standing access?

A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

Q: Why do AI agents complicate privilege governance?

A: AI agents complicate privilege governance because they can request access, use tools, and execute actions faster than human review cycles. That creates a larger attack surface for over-permissioning and misuse. Teams need continuous monitoring and strict task scoping so an agent cannot retain access beyond the approved workflow.

Q: How do security teams measure whether agent blast radius is too large?

A: Teams should measure the number of reachable resources, the depth of delegation, and the presence of write permissions across production systems. If a single agent can move across identity, data, and infrastructure layers without a containment point, the blast radius is already too wide.

Q: Who is accountable when an AI agent causes a security incident?

A: Accountability should sit with the business owner, the system owner, and the security function together, because agent behaviour crosses operational boundaries. Organisations need a defined owner for approval, monitoring, and retirement, plus audit evidence that shows what the agent accessed and why.

Technical breakdown

Why effective access matters more than role names for AI agents

A role tells you what was assigned at provisioning time, but effective access shows what an agent can actually do across connected systems after inheritance, delegation, and service integrations are applied. In AI environments, that distinction matters because an agent may hold indirect access through cloud roles, app permissions, or API tokens that the original role assignment does not make obvious. Access graph models are useful here because they expose the real reach of the identity, not the label attached to it.

Practical implication: inventory effective access for every AI agent and compare it with intended task scope, not with the role title alone.

Agent-to-agent authorization is a separate control problem

When one agent can trigger, delegate to, or coordinate with another agent, the security boundary is no longer just human-to-system access. The system now has identity relationships between machines that can amplify a small permission mistake into a broader chain of action. That requires explicit authorization logic for agent-to-agent calls, including which identities may delegate, which can be re-used, and which must be blocked from recursive invocation.

Practical implication: treat agent-to-agent paths as separate trust relationships and review them independently from user-to-agent access.

Blast radius is driven by delegated privilege, not by model capability alone

A powerful model does not create risk by itself. Risk appears when the model is embedded in an execution environment with real credentials, production permissions, and tool access that can affect data or infrastructure. That makes least privilege an identity design problem for the agent runtime, not merely a model-safety issue. The more persistent and connected the agent session, the more important it becomes to limit the set of resources and actions it can touch.

Practical implication: constrain each agent session to the minimum resources, tools, and write paths required for the task.

Threat narrative

Attacker objective: The objective is to turn a single agent compromise or misuse event into broad access to code, data, and production systems through delegated permissions.

1. Entry occurs when an AI agent is given delegated access to code, APIs, or infrastructure without a tightly bounded identity model. Escalation begins when that agent can reuse broad permissions across sessions or hand tasks to other agents.
2. Impact follows when a compromised or misdirected agent can reach multiple resources, coordinate tool use, and widen the blast radius beyond the original task boundary.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is the control plane for AI agents, not a supporting control. The article is right to treat vulnerability discovery and agent governance as separate problems, because a secure codebase does not limit what an agent can do once it has delegated permissions. For IAM and PAM teams, the decisive issue is whether the agent’s effective access is narrow enough to contain error, abuse, or compromise.

Agent blast radius is a governance metric, not just a security metric. Traditional vulnerability tooling measures exposure in code, but AI systems create exposure through action scope, data reach, and delegation depth. That means security teams should measure how far an agent can move across resources, other agents, and production systems before any control interrupts it.

Least privilege for AI agents must be evaluated at runtime, not at provisioning. The article describes persistent, coordinated agents that act across cloud platforms and toolchains, which means static role assignment cannot fully describe operational reach. Security programmes that stop at assigned permissions will miss the permissions that matter most: the ones that are effective during execution.

Effective access is the named concept practitioners need for the AI era. Effective access means the real permissions an agent can exercise after inheritance, delegation, and tool orchestration are considered. That concept matters because the blast radius of an agent is defined by what it can actually reach, not by what its documented role claims it should reach. Practitioners should govern the reachable identity, not the nominal one.

Autonomous agent identity governance exposes an assumption collapse in current IAM models. Least privilege was designed for access that is stable long enough to be reviewed and certified. That assumption fails when an autonomous agent can acquire, use, and propagate permissions during a session while chaining tools and other agents. The implication is that governance must be built around runtime reach and delegation paths, not only periodic entitlement review.

From our research:

• 27-year-old and 16-year-old vulnerabilities can still evade traditional automation, according to The State of Secrets in AppSec.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Agentic systems need a governed access map, not just a vulnerability map, so the next step is to study Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Effective access will become the deciding control metric for AI programmes. As agent runtimes become more persistent and connected, entitlement reviews that only look at assigned roles will miss the permissions that actually shape blast radius. Security teams should shift toward access graphs, runtime authorisation checks, and explicit delegation boundaries, because that is where real exposure accumulates.

With 43% of security professionals already concerned that AI systems may learn and reproduce sensitive information patterns from codebases, the governance challenge is no longer limited to model behaviour. It extends to the access paths that let agents reach code, secrets, and production resources in the first place.

Agent identity governance is converging with NHI lifecycle management. The same lifecycle questions that apply to service accounts now apply to AI agents, but with a wider trust boundary because agents can select actions dynamically. Teams should align their agent programmes with the NHI Lifecycle Management Guide and the broader access model in the Ultimate Guide to NHIs.

For practitioners

• Map effective access for every AI agent Build an inventory that shows the actual permissions each agent can exercise across cloud, application, and data systems. Compare that map with intended task scope so inherited and delegated access does not hide the real blast radius.
• Separate agent-to-agent trust from user-to-agent trust Define which agents may invoke, delegate to, or reuse other agents, and review those paths as distinct trust relationships. Block recursive or unbounded delegation unless there is a documented business need and a narrow authorization boundary.
• Bind agent sessions to task-scoped privileges Use short-lived, task-specific privileges for agent runtimes and revoke anything that outlives the session or task context. This keeps a compromised session from inheriting standing access into later actions.
• Measure blast radius as a control objective Track how many resources, systems, and downstream agents a single agent can reach before containment triggers. Use that measure to prioritise remediation for the widest-reaching identities first.
• Review production write paths separately Identify every agent that can write code, change infrastructure, or modify data, then restrict those permissions to explicit approvals or tightly bounded workflows. Read access is not the same as operational write authority.

Key takeaways

• AI agents change the security problem from code exposure to governed reach, because delegated permissions determine the blast radius after deployment.
• Vulnerability discovery can improve dramatically while identity controls lag behind, leaving effective access as the weakest link in the control stack.
• Practitioners should manage agent identity, delegation, and runtime privileges as first-class governance objects, not as incidental settings attached to a model.

Key terms

• Agent Identity Blast Radius: Agent identity blast radius is the amount of damage an autonomous agent can cause if its credentials, permissions, or decision logic are abused. The larger the blast radius, the more a single compromised agent can affect data, systems, and downstream workflows across the enterprise.
• 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 Authorization: Agent authorization is the decision process that determines whether a software agent may take a specific action at runtime. It evaluates context, delegated authority, and resource sensitivity at the moment of execution, not only at login or provisioning time.
• Delegated Privilege: Delegated privilege is access granted to a tool or system so it can perform actions without direct human intervention. The risk rises when delegation is broad, hidden, or hard to revoke, because the delegated actor can continue operating after trust has changed.

What's in the full article

Veza's full analysis covers the operational detail this post intentionally leaves for the source:

• How the Access Graph models effective access across cloud, app, and data layers for AI agents
• The specific way Veza distinguishes role assignment from effective permissions in agentic environments
• Examples of AI platforms named in the article, including AWS Bedrock, Azure AI Foundry, and GCP Vertex AI
• The vendor's framing of the “Agent Access Permissions Graph” as an identity model for autonomous systems

👉 The full Veza article covers agent identity, effective access, and the Access Graph model in more operational detail.

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.