Notifications
Clear all
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.
NHIMG editorial — based on content published by Veza: AI agents are transforming enterprise productivity and creating new security threats
By the numbers:
- According to the 2024 Verizon DBIR, stolen credentials remain a top breach vector across modern environments.
- Industry reports cited in the article say agent identities often outnumber human identities by a factor of 45 to 1 or more.
Questions worth separating out
Q: How should security teams manage permissions for AI agents?
A: Security teams should regularly assess and update the permissions granted to AI agents to ensure they align with their intended scope.
Q: Why do AI agents create new access risk for enterprises?
A: AI agents create access risk because they can operate with delegated authority while processing untrusted inputs.
Q: What breaks when CSPM and DSPM are used alone for AI security?
A: They can identify misconfigurations and sensitive data, but they do not tell you which agent can act on that data or which tool chain can reach it.
Practitioner guidance
- Inventory every agent and connector with identity context Build a complete inventory of models, agents, service accounts, data sources, and MCP connections, then record which identity each one uses and what data it can reach.
- Compute effective permissions before deployment Do not rely on declared roles or static entitlements.
- Treat MCP servers as governed privilege paths Require approval, ownership, and revocation for every MCP connection, and validate whether the server can expose tools or context beyond the intended task scope.
What's in the full article
Veza's full article covers the operational detail this post intentionally leaves for the source:
- How the access graph is structured across identity providers, cloud platforms, SaaS apps, and data systems
- The article’s full discussion of AI Security Posture Management as a governance model for agentic workflows
- Specific examples of how runtime permissions and data lineage are queried in practice
- The article’s framing of shadow AI discovery and model compliance as an operational workflow
👉 Read Veza's analysis of AI agent identity governance and access graphs →
AI agent identity risk and the access graph gap teams are missing?
Explore further
25/08/2026 6:11 pm
AI agent identity is now a blended governance problem, not a single-control problem. The article shows that agents can operate with inherited human permissions, standalone service accounts, and external tool access in the same workflow. That means least privilege must be evaluated across identity, data, and execution paths together. Practitioners should treat agent governance as an access-model problem, not a standalone AI tooling issue.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?
A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.
👉 Read our full editorial: AI agent identity governance needs an access graph to control risk
