Notifications
Clear all
Topic starter
06/06/2026 1:32 am
TL;DR: Agentic workflows are exposing a mismatch between enterprise data security controls and non-human runtime behaviour, according to Cyera’s analysis. The core problem is that IAM, DSPM, DLP, ITDR, and CASB were designed around human identities and static data states, while agents act continuously, across tools and APIs, with permissions that outlive the assumptions those controls were built on.
NHIMG editorial — based on content published by Cyera: AI Agents are breaking data security, here's how to fix it
Questions worth separating out
Q: How should security teams govern AI agents that can call tools and access data on their own?
A: Treat each agent as a governed identity with a defined purpose, effective permissions, and a measured blast radius.
Q: Why do AI agents complicate IAM and data security controls?
A: Because the core controls were built for human sessions and file-centric data movement, while agents act continuously, inherit permissions, and reason over data in context.
Q: What breaks when AI agents are treated like standard human users?
A: You lose visibility into effective permissions, expected behaviour, and real blast radius.
Practitioner guidance
- Inventory agent identities continuously Track every native, self-hosted, endpoint, and browser-based agent through platform APIs, network telemetry, OAuth signals, and endpoint mapping.
- Define effective permissions and purpose for each agent Record what each agent was built to do, what tools it can call, and which datasets it can actually reach.
- Enforce policy at the tool-call layer Block or redact actions before execution when a tool call would violate data residency, access scope, or content handling rules.
What's in the full article
Cyera's full article covers the operational detail this post intentionally leaves for the source:
- Native discovery methods across Copilot Studio, Agentforce, Bedrock Agents, and other agent platforms
- Examples of policy enforcement inside the loop for blocking tool calls and redacting sensitive context
- Validation workflow details for red-teaming agents with prompt injections and out-of-policy actions
- The article's data-graph approach for tying an agent to sensitive data and effective permissions
👉 Read Cyera's analysis of how AI agents are breaking data security controls →
AI agent governance is breaking human-built security assumptions?
Explore further
06/06/2026 2:42 am
Human-centric IAM assumptions are collapsing under agentic runtime behaviour. SSO, MFA, roles, and provisioning were designed for identities that authenticate, act within bounded human workflows, and stop. Agents are faster, more persistent, and more distributed than the controls that were built to govern them. That means the problem is not only coverage, but premise: the control stack assumes a person is behind every meaningful action. Practitioners should treat agent identity as a separate governance surface, not a variant of user IAM.
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.
- 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 agents are breaking data security controls built for humans
