Why do AI agents complicate zero trust and least privilege?

Why Traditional Zero Trust Fails When the Actor Is an AI Agent

zero trust assumes every request must be verified, but AI agents change the threat model because the authenticated actor is not the same as the human intent behind it. An agent can hold valid credentials, call approved tools, and still execute a sequence that is unsafe, overbroad, or simply outside the user’s legitimate authority. That is why agentic systems complicate both zero trust architecture and least privilege.

The gap shows up quickly in real deployments. NHIMG research in the The 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than they would give a human employee doing the same job. That is not a policy gap alone; it is a signal that static access models do not map cleanly to autonomous, goal-driven behaviour. The risk is even clearer when compared with the guidance in OWASP Agentic AI Top 10 and NIST SP 800-207 Zero Trust Architecture, both of which require context-aware controls that many agent deployments still lack.

In practice, many security teams encounter agent overreach only after a workflow has already chained through tools, data stores, and APIs in ways nobody explicitly approved.

How It Works in Practice

The practical answer is not to give agents broad roles and hope monitoring will catch misuse. Best practice is evolving toward intent-based authorisation, workload identity, and just-in-time credentialing. An agent should prove what it is, what task it is attempting, and why the current request is allowed. That means moving from static RBAC to real-time policy evaluation at the moment of each action, using policy-as-code and strong identity signals.

In mature designs, the human request starts a bounded task, but the agent does not inherit open-ended access. Instead, the platform issues short-lived secrets or ephemeral tokens only for the specific action needed. This is where workload identity becomes critical: a cryptographic identity such as SPIFFE/SPIRE can describe the agent itself, while runtime policy determines whether the requested operation matches the approved intent. NHIMG’s Guide to SPIFFE and SPIRE and OWASP NHI Top 10 both reflect this shift toward identity-aware control planes.

• Issue JIT credentials per task, not long-lived secrets that survive the workflow.
• Bind access to workload identity, not just user approval or a shared service account.
• Evaluate policy at request time, because the next action may be different from the last one.
• Log tool calls and data access separately so the agent’s chain of actions can be audited.

This approach aligns with CSA MAESTRO agentic AI threat modeling framework and NIST AI Risk Management Framework, which both emphasise governance, measurement, and operational controls around AI behaviour. These controls tend to break down when agents are allowed to share credentials across multi-step workflows because privilege inheritance becomes invisible and revocation loses precision.

Common Variations and Edge Cases

Tighter control often increases operational overhead, so organisations have to balance safety against workflow friction. That tradeoff is real, especially when multiple agents cooperate, call external APIs, or act across several business domains at once. There is no universal standard for every agent pattern yet, but current guidance suggests that the more autonomous the system, the shorter the credential lifetime and the narrower the action scope should be.

One edge case is human-in-the-loop systems that look supervised but still make autonomous sub-decisions. In those environments, a human approval step does not automatically make downstream tool use safe. Another common failure mode is “confidently wrong” automation, where the agent remains authenticated while the underlying plan is flawed. NHIMG research and vendor reporting on AI LLM hijack breach and Anthropic — first AI-orchestrated cyber espionage campaign report show how quickly tool chaining can become a security issue once an agent is able to re-plan around controls.

The practical takeaway is simple: zero trust for agents must validate identity, intent, and action sequence, not just the login event. When static credentials, shared workflows, or broad platform permissions remain in place, least privilege becomes a label rather than an enforcement model.

Related resources from NHI Mgmt Group

• Why do AI agents complicate zero trust and least privilege models?
• When is it crucial to implement least-privilege access for AI agents?
• Should organisations prioritize visibility or least privilege first for AI agents?
• Why do NHIs complicate zero trust and least privilege efforts?