Topic starter
25/08/2026 6:10 pm
TL;DR: AI agents create a new security problem because their permissions span training data, runtime data retrieval, external tools, and MCP connections, making legacy IAM, IGA, CSPM, and DSPM insufficient, according to Veza. The core issue is that least privilege now depends on mapping who or what can act on data across the full agentic lifecycle, not just managing static identities.
Editorial analysis by NHI Mgmt Group, based on content published by Veza: “Redefining Cybersecurity for the Agentic Era: Introducing AISPM”.
By the numbers:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
Key questions
Q: What breaks when security teams rely only on DSPM for AI agent governance?
A: DSPM shows where sensitive data exists, but it does not show how an agent moved that data, which tools it touched, or whether context was copied into a local store.
Q: Why do AI assistants create more risk than traditional service accounts?
A: AI assistants create more risk because they can be influenced by inputs, context, and hidden instructions after authentication succeeds.
Q: How do security teams know if an AI agent has too much access?
A: Look for agents that can reach multiple systems without task-specific limits, use persistent tokens, or touch high-value services such as email, chat, cloud consoles, and file stores.
Practitioner guidance
- Map effective permissions across the full agent lifecycle Trace access from training data through runtime retrieval, user inheritance, service accounts, and external tools so you can see the agent’s real blast radius.
- Inventory every agent, model, and MCP connection Build a complete asset list that includes shadow deployments, sanctioned models, and the tools or servers each agent can reach.
- Separate inherited access from direct agent access Distinguish what the human user granted from what the agent received through its own service accounts, keys, or JIT approvals.
Bottom line: AI agents create a governance problem that spans identity, data, and tool access at runtime, not just model training or account provisioning.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 19 hours ago by NHI Mgmt Group
25/08/2026 6:11 pm
Access graphs are becoming the governing layer for AI agent identity, not a supplemental reporting tool. The article shows that effective permissions for agents are distributed across users, service accounts, retrieval paths, cloud platforms, SaaS apps, and MCP endpoints. That makes access graphing the only practical way to answer the governance question that matters: who can take what action on what data. Practitioners should treat graph-based authorization as the baseline for AI identity control.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How do AI agents and MCP connections change governance requirements?
A: They extend classification from user content to delegated action. Agents can call tools at machine speed under inherited access, so teams need identity attribution, tool allow-lists, pre-execution checks, and audit trails. Without those controls, an agent can move sensitive data or trigger actions outside the intent of the human who launched it.
👉 Read our full editorial: AI agent identity governance needs an access graph to control risk
This post was modified 19 hours ago by NHI Mgmt Group