Why do AI agents complicate zero-trust access decisions?

AI agents complicate zero-trust because they can change intent mid-session, chain allowed actions, and retry after denial. Zero trust assumes continuous verification, but agents make the request path dynamic. Security teams should re-check identity, context, and object sensitivity at each step rather than relying on the first approval.

Why AI Agents Break Assumptions Behind Zero Trust

Zero-trust access works best when the requester has a stable purpose, a known role, and a predictable sequence of actions. AI agents do not behave that way. They can shift intent mid-session, chain tools in ways that were not explicit at approval time, and retry after a denial with slightly different parameters. That makes the access decision itself a moving target, especially when the agent holds OWASP Agentic Applications Top 10 style risk patterns such as tool misuse and overbroad autonomy.

Security teams often still map agents to static RBAC roles, but RBAC only answers who should generally have access, not whether this exact action is safe right now. Current guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture points toward continuous verification, but agents make that verification more difficult because the request path is dynamic, not linear.

The practical risk is that the first approval becomes a proxy for everything that follows, even when the agent later pivots into a different task or touches a more sensitive object. In practice, many security teams encounter excessive agent access only after sensitive data has already been queried, copied, or re-shared, rather than through intentional approval design.

How to Re-check Identity, Intent, and Context at Every Step

For AI agents, zero trust needs to become step-aware rather than session-aware. That usually means evaluating identity, context, object sensitivity, and requested tool use at the moment of action, not only at login or initial token issuance. A useful pattern is to combine workload identity with short-lived credentials so the agent proves what it is, then receives only the minimum access needed for that task. The Guide to SPIFFE and SPIRE is a strong reference point for workload identity, while CSA MAESTRO agentic AI threat modeling framework helps teams think about agent behaviour, tool chains, and trust boundaries.

Operationally, teams should prefer intent-based or context-aware authorisation over broad standing access. That means policy decisions can ask: What is the agent trying to do? Which object is being touched? Is the current context consistent with the approved task? Is this a JIT credential that should expire after the next action? Best practice is evolving here, but the direction is clear: access should be continuously re-authorised, not inherited from the first allow decision.

• Issue ephemeral secrets per task rather than long-lived static credentials.
• Bind authorisation to the specific workload identity and the current request context.
• Re-evaluate policy when the agent changes tool, data domain, or destination.
• Log every step so security teams can audit retries, escalations, and chained actions.

NHIMG research shows why this matters: in the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope, and only 52% could fully track and audit the data those agents accessed. These controls tend to break down when agents are allowed to reuse broad tokens across multiple downstream tools because the original approval no longer matches the later action.

Where the Model Breaks Down in Real Deployments

Tighter control often increases latency and operational overhead, requiring organisations to balance safety against automation speed. That tradeoff becomes most visible in multi-agent pipelines, long-running workflows, and systems that rely on LLM-driven retries. There is no universal standard for how many re-checks are enough yet, but current guidance suggests favouring policy evaluation at each high-risk transition rather than treating the entire run as one trusted session.

Edge cases matter. A planning agent may only need read access at first, then suddenly need to create tickets, query customer records, or trigger code deployment. If those privileges are granted through a single standing token, the agent can chain permissible actions into an outcome that was never reviewed as a whole. That is why OWASP Agentic AI Top 10 guidance increasingly overlaps with NHI governance, because the real issue is not only identity but also delegated capability.

The same pattern appears in organisations that depend on one-time approval but do not revoke credentials quickly enough. The better model is dynamic and short-lived: use JIT credentials, rotate secrets aggressively, and make revocation automatic when the task ends or the agent deviates from the approved intent. For broader NHI context, Ultimate Guide to NHIs and the Top 10 NHI Issues both reinforce the same point: standing privilege and static secrets are a poor fit for autonomous software.

In practice, the hardest failures show up where agents can retry silently, chain tools across trust boundaries, or inherit permissions from upstream orchestration. That is where zero trust must move from “approve the agent” to “approve the exact action, right now.”

Related resources from NHI Mgmt Group

• Why do AI agents complicate zero trust in identity and access management?
• When is it crucial to implement least-privilege access for AI agents?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?