Notifications
Clear all
Topic starter
25/08/2026 6:10 pm
TL;DR: Anthropic’s Project Glasswing found a 27-year-old OpenBSD bug and a 16-year-old FFmpeg flaw that older automated tools had missed, Veza reports, underscoring how vulnerability discovery is accelerating while agent identity, delegated access, and cross-agent authorization remain under-governed. The real control question is no longer only what code is vulnerable, but what an AI agent can reach, invoke, and hand off at runtime.
NHIMG editorial — based on content published by Veza: AI agent blast radius and least privilege in the AI era
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, redentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Veza's analysis of AI agent blast radius and least privilege →
AI agent blast radius and least privilege: are controls keeping up?
Explore further
25/08/2026 6:11 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent blast radius now depends on identity, not just code
