Why do AI agents complicate zero trust and least privilege controls?

AI agents complicate both models because they are autonomous, can chain actions, and may continue operating after the original context is gone. Zero trust still applies, but it must be enforced continuously across tools, identities, and token lifetimes instead of at login alone.

Why This Matters for Security Teams

AI agents are not just another workload with a different token format. They are goal-driven actors that can decide which tools to call, in what order, and how to recover when a path fails. That makes zero trust and least privilege harder because the access decision cannot be made once at login and assumed valid for the rest of the task. Current guidance from NIST SP 800-207 Zero Trust Architecture is still the right baseline, but agents force it to become continuous, contextual, and tied to workload identity rather than a human-style session.

This is also where NHI governance intersects with agentic AI risk. NHIMG research shows that 80% of organisations report AI agents have already acted beyond intended scope, while only 44% have any policies to manage them, a gap that explains why over-permissioning becomes the default. The same pattern appears in the OWASP NHI Top 10 and the broader NIST AI Risk Management Framework, both of which point to governance, traceability, and runtime control as foundational requirements.

In practice, many security teams encounter agent overreach only after a tool call, data access, or secret exposure has already happened, rather than through intentional design.

How It Works in Practice

For autonomous systems, the practical answer is not “more RBAC” but better runtime control. Static roles assume a stable job function, yet agents behave like dynamic orchestrators: they may chain prompts, invoke MCP-connected tools, retry with different parameters, or continue after the original user context has expired. That is why best practice is evolving toward intent-based authorisation, where the system evaluates what the agent is trying to do, what data or action is involved, and whether the current context justifies it.

In operational terms, that usually means combining workload identity with JIT credentials and short-lived secrets. An agent should prove what it is through cryptographic workload identity, such as SPIFFE/SPIRE or OIDC-backed service identity, then receive only the minimum scope needed for the task, for the shortest possible TTL. Secrets should be ephemeral, automatically revoked on completion, and separated by action class so a code-writing agent cannot inherit deploy privileges just because both tasks happen in the same workflow.

Policy enforcement also needs to move from pre-defined access rules to real-time evaluation. Teams are increasingly using policy-as-code patterns, including OPA or Cedar, to decide at request time whether a particular agent, on a particular task, under a particular risk posture, may proceed. That lines up with OWASP Top 10 for Agentic Applications 2026 and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasise action-level control and threat-aware orchestration.

• Issue credentials per task, not per session.
• Bind authorisation to intent, data sensitivity, and tool risk.
• Log every tool call and permission elevation for auditability.
• Revoke access automatically when the task ends or drifts from scope.

NHIMG coverage of the Guide to SPIFFE and SPIRE and the Analysis of Claude Code Security both reinforce the same pattern: the control point must sit at execution time, not just at login. These controls tend to break down when agents share long-lived service accounts across workflows because one compromise can persist across every tool the agent can reach.

Common Variations and Edge Cases

Tighter control often increases orchestration overhead, so organisations have to balance speed against the risk of uncontrolled autonomy. There is no universal standard for agent authorisation yet, which means implementations vary by environment. In regulated settings, the safest pattern is often narrow ZSP, strict JIT issuance, and step-up approval for high-impact actions. In experimental environments, teams may accept broader permissions temporarily, but only with aggressive logging and revocation.

One common edge case is multi-agent pipelines. A planning agent may be allowed to read tickets, while an execution agent can change infrastructure, but handing the planner’s context or secrets to the executor can accidentally collapse separation of duties. Another is long-running agents that survive beyond the original user session. If the user disappears, the authority should usually shrink, not persist. This is where static credentials become especially dangerous, because a credential with no useful expiry can outlive the risk context that justified it.

NHIMG’s report on agent behaviour and credential exposure, along with the OWASP Agentic Applications Top 10 and NIST Cybersecurity Framework 2.0, makes the practical point clear: the more autonomous the system, the more the control model must assume chaining, drift, and lateral movement. A useful rule of thumb is that any agent allowed to discover new tools should be treated as having a changing risk profile, not a fixed role.

That is why over-privileged agents are not just a policy issue. They are a design flaw that turns autonomy into persistence, and persistence into breach impact.

Related resources from NHI Mgmt Group

• Why do NHIs complicate zero trust and least privilege efforts?
• Why do AI agents complicate zero trust and least privilege models?
• Why do AI agents complicate zero trust and least privilege?
• Why do AI agents complicate zero trust and privileged access controls?