Why do AI agents complicate zero trust and IAM assumptions?

Why Traditional IAM Fails for Autonomous AI Agents

AI agents are not just another service account with a different label. They are goal-driven workloads that can chain tools, retry actions, and make new requests long after initial authentication. That means static RBAC and one-time login checks miss the real question: what is the agent trying to do right now, and should it be allowed to do it?

This is where zero trust and IAM assumptions start to bend. Zero trust, as described in NIST SP 800-207 Zero Trust Architecture, depends on continuous verification, but many implementations still rely on pre-set roles and broad standing permissions. For agents, that creates an attack surface that expands with every tool, connector, and token they can reach. NHIMG’s OWASP NHI Top 10 guidance is useful here because it frames agentic risk as an identity and authorisation problem, not just a model safety problem.

In practice, many security teams encounter over-permissioned agent behaviour only after the agent has already accessed data, invoked a tool, or triggered a downstream action that was never intended.

How It Works in Practice

The practical response is to move from static entitlement thinking to runtime decision-making. Instead of asking whether an agent has a role, ask whether a specific action is justified in the current context. That can mean policy-as-code checks, intent-based authorisation, and per-request evaluation before an agent can read a record, call an API, or open a network path. Current guidance suggests this should be treated as a control plane problem, not a one-time provisioning task.

For agentic systems, JIT credentialing matters because long-lived secrets are too easy to reuse, forward, or steal. Short-lived tokens, ephemeral secrets, and automatic revocation reduce the window of abuse when an agent becomes confused, compromised, or simply overconfident. NHIMG research such as AI LLM hijack breach and Guide to SPIFFE and SPIRE is relevant because it reinforces the identity primitive required for workloads: cryptographic proof of what the agent is, not just a password or API key.

• Use workload identity to bind the agent to a verifiable runtime identity.
• Issue JIT credentials per task with tight TTL and automatic revocation.
• Evaluate intent, data sensitivity, and destination at request time.
• Separate tool access from data access so one granted action does not imply broad trust.

For standards alignment, pair this with the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10. These controls tend to break down when agents operate across many SaaS tools and legacy systems because authorisation context is lost between hops.

Common Variations and Edge Cases

Tighter runtime authorisation often increases operational overhead, requiring organisations to balance security gain against policy complexity and debugging friction. There is no universal standard for this yet, especially for multi-agent pipelines where one agent delegates to another and the full chain of intent becomes harder to prove.

One common edge case is a semi-autonomous agent that needs occasional human approval. In that model, the safest pattern is to treat the human as a control point, not a permanent entitlement grant. Another is when an agent must retain state across sessions. Best practice is evolving, but that state should not mean standing privilege; it should mean bounded continuity with refreshed tokens and explicit scope checks.

NHIMG’s Moltbook AI agent keys breach underscores how quickly exposed secrets can be abused, while the Top 10 NHI Issues page helps frame the broader credential lifecycle risk. The practical lesson is simple: if the agent can discover new tasks faster than security can review permissions, standing access has already failed.

Related resources from NHI Mgmt Group

• Why do AI agents complicate zero trust architecture assumptions?
• Why do AI agents complicate zero trust architecture for IAM teams?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more IAM risk than ordinary developer tools?