Why do multi-cloud AI environments increase NHI risk?

Why This Matters for Security Teams

Multi-cloud AI environments amplify NHI risk because every cloud adds a different identity plane, policy language, token lifecycle, and logging model. That fragmentation makes it easier for service accounts, workload tokens, and model-facing endpoints to drift out of alignment. NIST’s Cybersecurity Framework 2.0 treats identity as a core control surface, but multi-cloud AI often turns that surface into several disconnected ones.

NHI Management Group research shows that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge. That is not just an administration problem. It means over-permissioned workloads can persist, offboarding can miss one cloud while succeeding in another, and hidden data paths can survive long after the original project owner has moved on. The issue is especially acute when AI systems are allowed to call external tools, storage, and model endpoints across environments without a single authority for runtime decision-making.

In practice, many security teams discover NHI sprawl only after a model, pipeline, or automation chain has already been granted more access than any one team intended.

How It Works in Practice

The risk rises because multi-cloud AI rarely uses one identity pattern end to end. A training job may authenticate with one cloud’s workload identity, fetch secrets from a second platform, and invoke a third-party model endpoint with yet another token format. Each hop creates a chance for a stale credential, broad role, or mis-scoped trust relationship to slip through. The result is not just more identities, but more incompatible control points that must all be correct at once.

This is why practitioners increasingly treat workload identity as the primary primitive rather than long-lived secrets. Standards such as SPIFFE and SPIRE are useful because they help express what a workload is, not merely what password or token it holds. In parallel, current guidance suggests that policy should be evaluated at request time, using context such as environment, task, data sensitivity, and destination service. That aligns with the direction of Ultimate Guide to NHIs and the Top 10 NHI Issues, which both emphasize access sprawl, secret reuse, and weak lifecycle control as recurring failure modes.

• Use separate workload identities for each cloud and each major AI pipeline stage.
• Prefer short-lived tokens and ephemeral secrets over static keys that survive across deployments.
• Evaluate access at runtime with policy-as-code so approvals reflect the actual request, not a stale role assignment.
• Centralise observability across clouds so anomalous tool use, data egress, and privilege escalation are visible quickly.

When teams do this well, offboarding becomes a revocation event rather than a search across multiple IAM consoles. These controls tend to break down when legacy applications still require static keys, because those dependencies force exceptions that are difficult to track across cloud boundaries.

Common Variations and Edge Cases

Tighter identity controls often increase integration overhead, requiring organisations to balance stronger containment against operational speed. That tradeoff is real in multi-cloud AI, where some vendors support workload-native tokens while others still depend on long-lived API keys or cloud-specific trust policies. There is no universal standard for this yet, so mature teams usually adopt a hybrid model while pushing each exception toward shorter lifetimes and narrower scope.

One edge case is cross-cloud inference routing, where a request begins in one environment but is served, cached, or logged in another. Another is federated ML pipelines, where data scientists, CI/CD systems, and AI agents all touch the same assets under different identities. In those cases, policy failures often show up as hidden trust between platforms rather than obvious over-permission. The 2024 Non-Human Identity Security Report also notes that organisations struggle to simplify non-human access management, which is consistent with the practical difficulty of coordinating multiple cloud IAM systems at once.

The safest posture is to assume that each cloud boundary is also an identity boundary. Where that is not true, risk tends to accumulate fastest in shared secrets, unmanaged service accounts, and AI workloads that can chain access across systems without a human noticing until after data movement has already occurred.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• Why do Salesforce integrations increase NHI risk?
• Why do federated workload tokens reduce NHI risk in multi-cloud environments?
• Why do AI and development environments increase NHI risk so quickly?