Why do AI agents complicate zero trust architecture for IAM teams?

Why This Matters for Security Teams

AI agents are not just another workload behind the IAM stack. They can decide, chain tools, and trigger downstream actions without a human in the loop, which means the risk surface shifts from login-time authentication to runtime authority. That breaks assumptions behind classic ZTA and RBAC, where access is often granted based on a known role rather than a live intent. NIST’s NIST AI Risk Management Framework and NIST SP 800-207 Zero Trust Architecture both reinforce the need for continuous evaluation, but agentic systems make that requirement operationally harder.

NHIMG research shows why teams are feeling the pressure now: in the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already performed actions beyond intended scope. That is not a theoretical policy gap; it is a control failure at the moment of action. The practical issue is that agents can appear trustworthy at authentication and still behave unpredictably once they receive context, tools, and secrets. In practice, many security teams encounter the first sign of failure only after an agent has already accessed data or executed a tool call, rather than through intentional policy testing.

How It Works in Practice

The security model has to move from static entitlement to intent-based authorisation. Instead of asking only, “Who is the agent?” teams also need to ask, “What is it trying to do right now, with which tool, against which data, under which policy conditions?” That is where per-action checks become essential. Current guidance suggests combining policy-as-code with runtime context, so approvals can be evaluated on every request rather than inherited from a broad role. The OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework both point toward this runtime-centric model.

For IAM teams, the most workable pattern is usually:

• Use workload identity as the base primitive, not a long-lived shared secret. SPIFFE/SPIRE-style identity is useful because it ties authorisation to the workload instance rather than an ambient credential.
• Issue Guide to SPIFFE and SPIRE style identities and short-lived credentials for each task, then revoke them when the task ends.
• Apply JIT credential provisioning so secrets, API keys, and tokens exist only for the minimum execution window.
• Evaluate policy at request time with tool, data, and destination context, not just with RBAC membership.

This is especially important where agents can invoke MCP-connected tools, retrieve secrets, or pivot across systems. NHIMG’s OWASP NHI Top 10 and Top 10 NHI Issues both reinforce that standing privilege and static secrets are the wrong default for autonomous systems. These controls tend to break down when agents operate across multiple SaaS tools and internal APIs because the policy engine loses visibility into the full chain of action.

Common Variations and Edge Cases

Tighter authorisation often increases latency, policy complexity, and operational overhead, so organisations have to balance control strength against automation speed. There is no universal standard for this yet, especially in multi-agent workflows where one agent delegates to another or where a planner agent hands off to a tool-executing agent. Best practice is evolving, but the direction is clear: the more autonomous the system, the less safe it is to rely on standing access or long-lived secrets.

Some teams try to treat agents like service accounts with broader RBAC and a shared vault token. That approach is convenient, but it weakens ZTA because the access decision no longer reflects actual intent. A better pattern is to pair short-lived secrets with explicit task scopes, then verify both identity and purpose at each hop. The Ultimate Guide to NHIs — 2025 Outlook and Predictions and AI LLM hijack breach coverage both highlight how quickly credential abuse can turn agentic automation into lateral movement. NIST’s NIST Cybersecurity Framework 2.0 is still useful here, but it needs to be translated into runtime controls, not only governance language.

Where this gets hardest is in environments that mix human approvals, autonomous execution, and hidden tool chains. That is usually where agent behaviour becomes non-deterministic enough that pre-defined access rules stop matching reality.

Related resources from NHI Mgmt Group

• Why do AI agents complicate zero trust architecture assumptions?
• Why do AI agents complicate zero trust architecture in SaaS?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• How should security teams manage permissions for AI agents?