Why do AI agents complicate zero trust architecture in practice?

Why Traditional Zero Trust Friction Spikes with AI Agents

AI agents complicate zero trust because they are not static users. An agent can authenticate correctly, pass initial policy checks, and still become risky seconds later if its goal changes, its tool chain expands, or it is prompted into a new action path. Zero trust assumes continuous verification, but agents force security teams to verify not only who or what is calling, but also what the system is trying to do right now.

This is why static RBAC and perimeter-era assumptions fail in practice. An agent may be authorised for one task, then chain prompts, APIs, and plugins into another action that was never anticipated at provisioning time. Current guidance from the NIST SP 800-207 Zero Trust Architecture and the OWASP Agentic AI Top 10 both points toward runtime verification, but best practice is still evolving for fully autonomous systems.

NHIMG research shows this is not theoretical: in the OWASP NHI Top 10 coverage, agentic systems are treated as a distinct exposure because behaviour can diverge after trust is granted. In practice, many security teams encounter agent-driven overreach only after unauthorised tool use has already happened, rather than through intentional access design.

How Zero Trust Has to Work for Autonomous Agents

For AI agents, zero trust needs to move from identity-first gating to action-first control. The practical model is: issue a workload identity to the agent, bind it to a specific runtime, and then evaluate every sensitive request against task context, data sensitivity, and policy. That means an agent should not inherit broad standing access just because it is “trusted” once at login.

Where possible, use JIT credential provisioning and short-lived secrets so an agent receives credentials only for the task at hand and loses them when the task ends. That is materially different from human workflows, because an autonomous agent may retry actions, split work across tools, or continue operating after the original intent has drifted. Guide to SPIFFE and SPIRE is useful here because workload identity gives cryptographic proof of what the agent is, while policy engines decide what it may do at that moment.

Operationally, teams should combine intent-based authorisation, policy-as-code, and step-up approval for high-risk actions. The CSA MAESTRO agentic AI threat modeling framework aligns well with this approach, and the NIST AI Risk Management Framework reinforces governance, measurement, and human accountability. The right question is not “is the agent authenticated?” but “is this specific action safe, necessary, and still within the approved intent?”

• Use workload identity rather than long-lived shared secrets.
• Issue credentials per task, not per environment.
• Evaluate access at request time, not only at session start.
• Require richer approval for data exfiltration, privilege changes, or external side effects.

These controls tend to break down when agents are given broad connector access to production SaaS, cloud APIs, and internal knowledge bases because tool chaining can outrun manual approval paths.

Where the Edge Cases and Failure Modes Show Up

Tighter control often increases latency and operational overhead, so organisations have to balance agent velocity against blast-radius reduction. That tradeoff is real, especially when the agent supports business workflows that expect near-instant responses.

One common edge case is the “mostly trusted” internal agent. Teams may relax controls because the agent runs inside the network, but that is exactly where zero trust should be strictest. Another is multi-agent orchestration, where one agent inherits context from another and silently accumulates authority. There is no universal standard for this yet, so current guidance suggests treating each agent as a separate workload with its own identity, policy envelope, and audit trail.

NHIMG’s AI LLM hijack breach analysis and the Top 10 NHI Issues both reinforce the same practical lesson: if a secret, token, or connector can be reused after the original task is complete, the zero trust model is already weakened. External threat guidance from the MITRE ATLAS adversarial AI threat matrix is helpful for mapping how agents are manipulated, while the NIST Cybersecurity Framework 2.0 remains useful for tracking governance, detect, and respond capabilities.

In practice, the hardest failures appear when autonomous agents are allowed to persist across tasks with cached credentials, because that turns a temporary decision into standing privilege.

Related resources from NHI Mgmt Group

• Why do AI agents complicate zero trust architecture for IAM teams?
• Why do AI agents complicate zero trust architecture assumptions?
• Why do AI agents complicate zero trust architecture in SaaS?
• Why do AI access keys complicate zero trust architecture?