TL;DR: Zero Trust for AI agents has to move beyond login because agents read prompts, choose tools, call APIs, and trigger workflows after authentication, according to Cato Networks. Identity checks alone do not govern action quality when runtime context decides whether the next step is safe or harmful.
NHIMG editorial — based on content published by Cato Networks: Zero Trust for AI Agents Starts After Login
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 17 minutes, redentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that can produce unsafe outputs after login?
A: Security teams should govern AI agents with two separate controls: identity access and behavioural assurance.
Q: Why do AI agents complicate zero trust and IAM assumptions?
A: AI agents complicate zero trust because they are authenticated entities that can operate continuously, yet they do not behave like a human user whose activity naturally limits exposure.
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 every active agent workflow List where each agent runs, what it touches, who owns it, and which identity or token it uses.
- Classify autonomy before granting control Group each agent as observing, advising, acting with approval, or acting autonomously.
- Treat prompts and tool calls as governed inputs Validate prompt context, tool-call parameters, and retrieved data before execution, especially for write, delete, export, spend, or external API actions.
What's in the full article
Cato Networks' full post covers the operational detail this analysis intentionally leaves for the source:
- The practical autonomy ladder used to map observing, advising, approval-based, and autonomous agents to control depth.
- The runtime visibility approach for prompts, tool calls, data movement, and workflow steps across agent activity.
- The workflow-by-workflow inventory method for classifying owner, access scope, approval points, logs, and rollback paths.
- The architecture view for placing inspection next to user, application, network, SaaS, and security telemetry.
👉 Read Cato Networks' analysis of Zero Trust controls for AI agents →
AI agent runtime controls: are your safeguards keeping up?
Explore further
Login-centric Zero Trust is incomplete once the actor can decide after authentication. The older model assumes the access decision is the main security event. For AI agents, the decision that matters happens after login, when the actor selects a tool, interprets context, and chooses the next action. Practitioners should treat runtime action as the new governance boundary.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, which means runtime governance has to assume broad blast radius until proven otherwise.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: Zero Trust for AI agents starts after login