Zero Trust for AI agents starts after login

At a glance

What this is: This is a Zero Trust analysis of AI agent governance that argues login is only the start, because the real control problem appears when an agent decides what to do next.

Why it matters: It matters because IAM, PAM, and NHI teams must now govern runtime actions, not just authenticated identities, across agents, service accounts, and human approval paths.

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

👉 Read Cato Networks' analysis of Zero Trust controls for AI agents

Context

Zero Trust for AI agents is a runtime governance problem, not just an authentication problem. Once an agent has logged in, the security question shifts from who it is to what it is about to do, which tool it will call, and whether the action still fits the business context.

That shift matters for IAM and NHI programmes because agents inherit many of the same structural weaknesses as service accounts, but with added judgment and tool selection. The right control boundary is no longer the login event alone, but the sequence of prompt, context, policy, and action that follows.

For teams already working through machine identity governance, the article sits squarely in the same problem space as workload identity and runtime authorization. The security model has to follow the action, not stop at the credential.

Key questions

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. Authentication, SSO, RBAC, and provisioning decide who can use the system. Automated red-teaming and monitoring decide whether the system behaves safely once it is used. Both are required because a correctly authenticated agent can still generate unsafe, misleading, or policy-breaking outcomes.

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. IAM teams must therefore verify context, scope, and action, not just identity at login time.

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. Human-centric controls can misclassify normal agent activity as compromise, or miss policy violations that happen entirely within legitimate access. The failure is not only technical, it is governance design that assumes a person is always behind the action.

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.

Technical breakdown

Why login is not enough for AI agent governance

Authentication proves that an agent or associated identity was allowed in. It does not prove that the next step is appropriate, because modern agents can read context, choose tools, and initiate work after the initial access decision. That creates a mismatch between identity assurance and action assurance. In NHI terms, the credential is only the entry condition; the risk emerges when runtime behavior determines which systems get touched next. Zero Trust therefore needs continuous evaluation of the action path, not just the login event.

Practical implication: inspect prompts, tool calls, and data movement as part of the policy decision, not as post-incident telemetry.

How autonomy changes the access model

Autonomy changes the control problem because an agent that can act with less human intervention needs tighter scoping at the action level. An observing agent can be treated differently from an acting agent, and an acting autonomously agent needs stronger guardrails, approval paths, and rollback mechanisms. This is not just least privilege in a new label. It is privilege shaped by runtime behavior, where the same identity may need different control treatments depending on the action being attempted and the business impact of that action.

Practical implication: classify agent autonomy before assigning permissions, approval points, and audit requirements.

Why audit trails must include the work itself

A useful audit trail for AI agents has to show the prompt, response, tool call, data touched, and workflow step. Without those elements, investigators can see that an agent existed but not whether it behaved safely. This is the same failure pattern seen in machine identity governance, where logs often surface only after something breaks. For agents, the evidence has to be available while the work is happening, because runtime misuse can be both fast and contextual.

Practical implication: make auditability a runtime control requirement, not a forensic afterthought.

NHI Mgmt Group analysis

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.

AI agents inherit the machine identity problem, but they do not behave like static machine identities. Service accounts generally follow code, while agents interpret goals and can vary their action path. That means the old assumptions around stable behavior, predictable execution, and review after the fact become weaker. The implication is that access models must distinguish between fixed execution and runtime judgment.

Autonomy decides how much control you need, not just how much access you grant. An observing agent, an advising agent, and an acting agent all require different guardrails. This aligns with Zero Trust and NIST AI Risk Management Framework thinking, but the key point is structural: control must scale with the agent's decision authority. Practitioners should map autonomy to policy depth before production use.

Runtime visibility is now a governance requirement, not a nice-to-have telemetry layer. If security cannot see the prompt, tool choice, data movement, and workflow step, then it cannot explain or contain unexpected agent behavior. That makes audit trails part of the control plane. Teams should assume that action-level evidence is essential for identity governance across AI agents and NHIs.

Zero Trust for agents will converge with NHI governance, not replace it. The same programme that governs service accounts, tokens, and certificates must now absorb agents that inherit those identities or act through them. The field is moving toward a shared runtime control model across machine and autonomous identities. Practitioners should expect identity governance to become more action-aware across the board.

From our research:

• 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.
• That same visibility gap is why the Ultimate Guide to NHIs is a useful baseline for teams mapping agents, service accounts, and token ownership together.

What this signals

Runtime governance will become the differentiator in identity programmes that now have to cover both machine and autonomous actors. Teams that still treat login, certification, and audit as separate layers will miss the point that the real decision happens in the action path. The practical shift is toward policy that can inspect prompts, tool usage, and workflow steps before business impact occurs.

With 97% of NHIs carrying excessive privileges, per the Ultimate Guide to NHIs, the case for action-level controls is no longer hypothetical. Agents magnify the same privilege problem because they can combine access paths dynamically at runtime. IAM and PAM programmes should expect stronger demand for approval boundaries, scoped actions, and rollback-ready workflows.

Identity blast radius: the control surface is shifting from the credential to the consequence of the next action. That means security teams should watch for governance models that can explain not just who acted, but what systems were touched and whether the action was still justified in context.

For practitioners

• Inventory every active agent workflow List where each agent runs, what it touches, who owns it, and which identity or token it uses. Separate coding agents, SaaS-managed agents, internal custom agents, and third-party connected agents so the control model reflects actual runtime exposure.
• Classify autonomy before granting control Group each agent as observing, advising, acting with approval, or acting autonomously. Tie that class to data access, tool scope, approver roles, and rollback requirements so policy depth rises with decision authority.
• 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. The policy check should happen in the runtime path, not after the workflow finishes.
• Build audit trails that explain the action path Record prompts, responses, tool calls, data touched, policy decisions, and workflow steps in one investigative view. Use that evidence to stop the next action, not just reconstruct the last one.
• Start with one production-bound workflow Pick a single workflow that is already in use or close to production, then map identity, autonomy, access, approvals, logs, and rollback. That exposes the control gaps without forcing a broad programme redesign on day one.

Key takeaways

• Zero Trust for AI agents has to govern runtime action, because login alone does not explain what an agent will do next.
• AI agents amplify the familiar machine identity problem by adding judgment, tool choice, and context-sensitive execution.
• Identity programmes now need action-level visibility, autonomy-based controls, and audit trails that can explain the full work sequence.

Key terms

• Runtime Agent Governance: The continuous enforcement of identity, access, and behaviour policies on AI agents during execution — detecting when agents deviate from expected behaviour or attempt to access data beyond their remit.
• Autonomy Level: A measure of how independently an AI agent can decide, select tools, and execute actions. In practice, autonomy level determines how much approval, monitoring, and rollback capability the organisation needs before the agent is allowed to touch business systems.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.

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.

👉 Cato Networks' full post covers agent autonomy levels, runtime guardrails, and audit-path design in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.