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.
Editorial analysis by NHI Mgmt Group, based on content published by Veza: “Anthropic Project Glasswing and the Veza Access Graph: Two Pillars of the AI Security Era”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 18 hours ago by NHI Mgmt Group
25/08/2026 6:11 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: AI agent blast radius now depends on identity, not just code
This post was modified 18 hours ago by NHI Mgmt Group