Why do AI systems complicate zero trust assumptions?

Why Traditional Zero Trust Assumptions Fray Around AI Systems

zero trust is still the right model, but AI changes the object being trusted. A human user typically authenticates, acts, and ends a session. An AI system may keep executing, chain tools, reuse tokens, and operate long after the original request is gone. That means the enforcement point cannot sit only at login or network perimeter; it has to follow runtime identity, session context, and policy revocation. NIST’s NIST SP 800-207 Zero Trust Architecture makes this boundary shift clear.

This is especially visible when AI touches secrets or delegated access. NHIMG research shows that 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases, and the State of Secrets in AppSec report from GitGuardian and CyberArk shows how fast secrecy failures become operational issues. In parallel, the Top 10 NHI Issues page highlights why static credential assumptions fail once machine actors begin to behave like persistent principals. In practice, many security teams encounter AI overreach only after a tool chain has already been abused, rather than through intentional design of trust boundaries.

How Zero Trust Should Be Applied to AI Workloads

For AI systems, zero trust shifts from “trust no network path” to “trust no action without fresh evidence.” The strongest pattern is workload identity plus intent-based authorisation. A model, agent, or pipeline should present a cryptographic workload identity, then request permission for each action based on what it is trying to do, where it is operating, and what data it needs. That is why implementation guidance increasingly points to identity primitives such as SPIFFE and SPIRE, documented in NHIMG’s Guide to SPIFFE and SPIRE.

In practice, this means:

• Issue JIT credentials for a single task, not long-lived secrets that survive multiple prompts or sessions.
• Use policy-as-code to decide access at request time, not only through static RBAC or pre-approved roles.
• Bind secrets, tokens, and certificates to workload identity so the credential is valid only for the intended agent or service.
• Revoke or downgrade access when the task completes, the context changes, or the model steps outside its approved intent.

This approach aligns with NIST’s NIST Cybersecurity Framework 2.0, especially around identity, access control, and continuous monitoring. It also matches NHIMG’s Ultimate Guide to NHIs — Standards, which stresses that NHI governance must account for machine-to-machine trust lifecycles, not only human access reviews. These controls tend to break down when an agent can call multiple tools across loosely governed platforms because the decision point is too far from the actual execution path.

Common Variations, Tradeoffs, and Edge Cases

Tighter runtime control often increases latency and operational overhead, so organisations must balance stronger containment against the need for fast, autonomous execution. That tradeoff becomes sharper in multi-agent systems, where one agent may delegate to another, or where a model uses MCP-connected tools to perform several steps under one high-level goal. There is no universal standard for this yet, but current guidance suggests treating each delegation as a new trust decision rather than an extension of the original one.

Edge cases appear when AI systems handle ephemeral secrets, cached prompts, or background jobs. A token that is safe for a single inference request may be unsafe if a workflow retries, queues, or fans out. Likewise, static RBAC often fails because the system cannot predict all actions in advance. Best practice is evolving toward intent-based authorisation, short TTLs, and revocation hooks that trigger when the model completes a goal, changes context, or enters an abnormal path.

The same caution applies to breach evidence. NHIMG’s DeepSeek breach coverage shows how exposed records and embedded secrets can amplify the blast radius when AI systems are allowed broad, persistent access. When AI systems are granted standing privilege, zero trust degrades into a paper policy because the trust decision no longer reflects what the workload is actually doing.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do NHIs complicate zero trust and least privilege efforts?
• Why do Active Directory service accounts complicate zero trust programs?
• Why do AI agents complicate zero trust architecture assumptions?