Notifications
Clear all
Topic starter
09/06/2026 11:13 pm
TL;DR: Multi-cloud AI deployments spread training, inference, and data across providers, creating identity and visibility gaps that legacy cloud controls miss, according to Orca Security. The real problem is not cloud choice but fragmented trust boundaries, where short-lived AI workloads, inconsistent IAM models, and cross-cloud data flows outpace governance.
NHIMG editorial — based on content published by Orca Security: securing AI workloads in multi-cloud environments
Questions worth separating out
Q: How should security teams govern AI workloads across multiple cloud providers?
A: They should treat each AI workload as a governed identity with one owner, one approved purpose, and one revocation path.
Q: Why do multi-cloud AI environments increase NHI risk?
A: They increase NHI risk because service accounts, tokens, and model endpoints are split across different IAM systems with incompatible policy models.
Q: What breaks when agentless visibility is missing in AI infrastructure?
A: Without agentless visibility, ephemeral training jobs, GPU clusters, and short-lived inference services can disappear before traditional tools observe them.
Practitioner guidance
- Standardize cross-cloud identity ownership Assign one accountable owner for each AI workload identity, including training jobs, model registries, inference services, and supporting service accounts.
- Inventory shadow AI with agentless discovery Use agentless discovery to map AI endpoints, data stores, and GPU workloads across providers without relying on agents inside ephemeral compute.
- Validate permission meaning across providers Review the same identity in each cloud as if it were a different control object, because role names and policy semantics do not translate cleanly.
What's in the full article
Orca Security's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step controls for federating human, service account, and AI workload access across AWS, Azure, and Google Cloud.
- Implementation detail on agentless SideScanning for inventorying ephemeral GPU clusters, serverless inference, and cross-cloud dependencies.
- Practical examples of behavioural detection rules for prompt injection, abnormal API use, and data movement across approved boundaries.
- Data residency and encryption guidance for training data, model weights, and inference output across multiple regions and providers.
👉 Read Orca Security's guide to securing multi-cloud AI workloads →
Multi-cloud AI security: what IAM teams are missing now?
Explore further
10/06/2026 1:30 am
Multi-cloud AI security is an identity governance problem before it is a cloud architecture problem. The article correctly shows that training, storage, and inference become fragmented when each provider exposes different IAM semantics and control planes. That fragmentation matters because privilege decisions no longer live in one place, which makes NHI governance the control layer that must survive provider boundaries. Practitioners should treat the AI pipeline as a distributed identity estate, not just a distributed workload.
A few things that frame the scale:
- 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to The 2024 Non-Human Identity Security Report.
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts.
A question worth separating out:
Q: How can organisations detect cross-cloud AI abuse before data is exposed?
A: They should correlate prompt behaviour, API access, and storage activity across clouds so that unusual runtime actions stand out. Detection should focus on requests that cross an approved boundary, because that is often where model misuse becomes data leakage or credential abuse.
👉 Read our full editorial: Multi-cloud AI security fails when identity controls fragment
