TL;DR: Traditional security tools cannot secure AI agents because they were designed around user-centric identity, event-based visibility, and fixed data paths, according to Zenity and Gartner’s April 2026 evaluation. The governance problem is structural, because agent behavior, layered identities, and runtime intent invalidate assumptions that legacy IAM and detection stacks rely on.
Editorial analysis by NHI Mgmt Group, based on content published by Zenity: “Why Purpose-Built Architecture Wins in AI Agent Governance”.
Key questions
A: A useful DLP audit checklist should cover the full data path, not just one control layer.
Q: Why do traditional IAM and SIEM controls miss SaaS lateral movement?
A: Traditional IAM and SIEM tools are usually optimized for human login events, endpoint telemetry, and isolated application logs.
Q: What are the signs that an AI governance programme is too shallow?
A: A shallow programme usually shows up when teams rely on accuracy alone, lack clear metrics for fairness or explainability, and cannot verify how models behave under stress.
Practitioner guidance
- Define the agent identity surface Inventory every place an agent can hold, inherit, or embed identity, including static secrets, session credentials, tool identities, and agent-to-agent links.
- Separate agent estates by operating model Classify SaaS-managed, home-grown, and device-based agents separately so discovery, policy, and response controls match where each type actually lives and acts.
- Move detection from events to intent Require stateful analysis that can compare observed action sequences with the task the agent was expected to perform, rather than relying on isolated alerts.
Bottom line: AI agent governance cannot be solved by retrofitting controls that were designed for human sessions and fixed data paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
AI agent governance fails when identity is treated as a credential problem instead of a runtime behaviour problem. Agents inherit access, chain tools, and act across multiple identity layers, so the control question is no longer who logged in. It is what the agent can decide to do with the access it already has. The implication is that authorisation must move closer to execution, not remain anchored only in provisioning.
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.
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
A question worth separating out:
Q: What should teams do when user permissions change during an active agent task?
A: Treat permission checks as real-time, not session-scoped. If a user is demoted, revoked, or offboarded while an agent is still working, the next token exchange must reflect the new state immediately. Cached authorisation creates stale access and defeats the purpose of delegated control.
👉 Read our full editorial: AI agent governance needs purpose-built architecture, not retrofits