TL;DR: Cloud Security Alliance's 2026 cloud threat survey shows inadequate identity and access management at #1, AI-enhanced attacks at #2, and insecure third-party resources at #3, while misconfiguration fell to #5. The shift shows that cloud risk is increasingly about enforced authority, not just configuration hygiene.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Native's report: Cloud threat priorities have shifted toward identity, third-party access, AI systems, and enforced boundaries rather than misconfiguration alone.
Why it matters: This matters because IAM, workload reach, and third-party permissions now shape blast radius across cloud and AI programmes, so practitioners need enforceable controls, not only detection.
By the numbers:
- More than 500 practitioners evaluated the cloud risks in the 2026 survey.
Context
Cloud security failures now tend to start with authority that is broader than it should be, not just with a visible misconfiguration. When identities, workloads, third parties, and AI systems can reach too much, the environment may still look compliant while the blast radius remains oversized.
In cloud and AI environments, enforcement matters more than policy intent. A role, token, or agent can only be governed if the platform constrains what it can do at runtime, which is why identity boundary control belongs alongside segmentation and configuration hardening.
Native's framing aligns with a broader shift in cloud governance: the most consequential failures are often permission failures that cross organisational boundaries, not isolated setup errors.
Key questions
Q: How do cloud teams limit runtime authority for service accounts?
A: Cloud teams limit runtime authority for service accounts by giving each account only the API permissions it needs, then binding access to short-lived credentials, workload identity, and scoped IAM roles. They also rotate secrets, separate production from non-production accounts, and remove standing credentials that outlive the task or workload.
Q: Why do third-party SaaS integrations increase blast radius?
A: They increase blast radius because one trusted app can reach multiple systems, data stores, and secret locations at once. If that app is compromised, the attacker inherits every downstream entitlement attached to its scopes. The risk is not the number of integrations alone, but how far each one can travel through the identity chain.
Q: What is the difference between segmentation and access control in cloud security?
A: Segmentation limits where cloud traffic can move by separating networks, subnets, security groups, or workloads, while access control determines who or what may use a resource after reaching it. Segmentation is about reachability and blast radius. Access control is about authentication, authorisation, and specific permissions such as RBAC, ABAC, or IAM policies.
Technical breakdown
Why cloud misconfiguration is no longer the whole story
Misconfiguration describes incorrect resource settings, but cloud loss often comes from authorised reach that is simply too broad. A role may be valid, a policy may be syntactically correct, and a workload may authenticate successfully, yet the resulting authority still spans too many resources or actions. That is why cloud threat rankings increasingly pull IAM, third-party access, and AI actors into the same conversation. The problem is not only whether a control exists. It is whether the control limits what each identity can actually reach when the environment changes fast and at scale. See the IAM and IGA Basics.
Practical implication: Map controls to reachable actions and resource scope, not only to configuration state.
How third-party and AI access expand blast radius
Third-party integrations and AI agents create delegated access paths that can outlive the original trust assumption. If a partner token or agent credential can traverse production services, data stores, or control APIs, the compromise path is defined by reach, not intent. AI adds a second layer of risk because agent behaviour is non-deterministic. A prompt can change what the system tries to do, but it should not widen the permissions it already has. Effective cloud design therefore treats delegated access as a constrained runtime boundary, not as a standing trust relationship.
Practical implication: Constrain delegated access by resource, action, and environment so partner and agent credentials cannot widen scope at runtime.
Why simulation is now part of cloud enforcement
Cloud enforcement often stalls because teams cannot predict the operational fallout of a new policy across brownfield environments. Simulation closes that gap by showing which identities, workloads, services, and actions would be affected before enforcement begins. That matters in multi-cloud estates where each provider expresses policy differently and where a blocked CI/CD path can create immediate operational risk. Simulation also shifts governance from a one-time hardening exercise to an ongoing change-management discipline. The core technical issue is not policy creation. It is safe translation of intent into provider-native controls that can be tested before they break production. See the Cloud Security Guide.
Practical implication: Simulate new policies against live activity before rollout so enforcement does not interrupt critical workloads.
Threat narrative
Attacker objective: The objective is to turn legitimate cloud authority into broad operational reach that can be abused for disruption, exposure, or lateral movement.
- Entry begins when an attacker, third-party integration, or AI-driven workflow obtains legitimate cloud access with permissions that are already too broad.
- Escalation occurs when that identity or agent can act across additional services, zones, or data paths because enforcement does not constrain its runtime authority.
- Impact follows when the compromised access reaches more infrastructure than intended, increasing the blast radius of destructive action, data exposure, or cross-environment movement.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authority, not configuration, is now the dominant cloud security problem: the ranking shift shows that practitioners increasingly fear what an identity can do once it is allowed to operate. Misconfiguration remains relevant, but it is no longer the main lens through which cloud loss is understood. The practical implication is that governance must focus on reachable actions and runtime boundaries, not just on static posture.
Third-party and AI access are now the same governance problem class: both create delegated authority that can cross environment boundaries if it is not tightly constrained. The article points to a cloud model in which partner integrations, service identities, and AI agents all need scope limits that survive prompt changes, trust drift, and operational reuse. Practitioners should treat delegated access as an enforced boundary, not a standing assumption.
Simulation is becoming a prerequisite for cloud policy enforcement: in brownfield multi-cloud estates, the biggest barrier is often not knowing what a new control will break. That makes pre-enforcement testing a governance requirement, not a convenience. Teams that cannot predict impact will keep postponing stronger controls, which leaves identity boundaries porous.
Identity boundaries are the new segmentation layer: cloud segmentation still matters, but it is no longer enough on its own when identities can move through APIs, data services, and AI workflows. The named concept here is enforcement gap: the space between a control that exists on paper and a boundary that actually limits runtime authority. Closing that gap is what separates visible hardening from real containment.
Cloud control has shifted from prevention alone to containment by design: the article shows that safer cloud operations depend on architectures that prevent overreach before incident response ever begins. That should push security leaders to re-evaluate whether their current policies limit blast radius or merely document it.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.
- Read next: NHI Lifecycle Management Guide
What this signals
Enforcement gap: the next cloud security problem is less about spotting unsafe resources and more about making sure identities cannot act outside intended scope. That shift pulls IAM, segmentation, and policy simulation into one operational discipline, because controls that exist but do not bind runtime behaviour will not contain compromise.
Cloud programmes should expect more attention on delegated authority, especially where third parties and AI systems can inherit access into production workflows. The practical test is simple: if a token, role, or agent can reach more than it should during normal operation, the architecture is still permitting avoidable blast radius.
For practitioners
- Inventory effective authority paths Map which identities, service accounts, third parties, and AI systems can reach production data, control planes, and privileged APIs today, then compare that reach to intended scope.
- Apply runtime scope limits to delegated access Constrain partner tokens, service credentials, and agent permissions by resource, action, and environment so delegated access cannot expand during normal operation.
- Simulate policy impact before enforcement Test new cloud policies against live activity to identify blocked CI/CD pipelines, service integrations, and workload dependencies before rollout.
- Separate third-party reach from core production paths Reduce the number of trust relationships that can directly touch sensitive resources, and require explicit policy boundaries for every external integration.
- Treat AI actions as constrained by architecture Ensure prompts, tool calls, and agent decisions cannot override the permissions already assigned to the underlying identity.
Key takeaways
- Cloud risk is moving from configuration drift toward enforced authority, with identity and access now the clearest ranking signal.
- The most worrying exposure pattern is not one control failure but the combination of delegated access, AI action scope, and third-party trust.
- Practitioners need policy simulation and runtime scope limits so that a valid identity cannot turn into an oversized blast radius.
Related NHI Mgmt Group resources: IAM and IGA Basics · NHI Lifecycle Management Guide · Cloud Security Guide · Identity Security Programme Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cloud threat exposure here is driven by excessive permissions and effective reach. |
| Recommendation — Apply PR.AA-05 to constrain cloud identities to the minimum reachable scope. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article centers on account scope, third-party access, and identity reach. |
| Recommendation — Use CIS-5 to govern cloud accounts, service identities, and third-party access paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Over-permissioned service accounts and agent identities are part of the risk pattern. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party integrations are a named driver of cloud risk in the ranking. | |
| Recommendation — Reduce NHI privilege scope so credentials cannot access more cloud resources than intended. Track and restrict third-party NHIs that can reach production resources. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI systems acting across cloud infrastructure create privilege abuse risk. |
| Recommendation — Bind agent permissions to fixed task scope so runtime decisions cannot expand authority. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article's concern is how valid access can be abused to move farther through cloud environments. |
| Recommendation — Map cloud compromise paths to credential access and lateral movement to prioritise containment controls. | ||
Key terms
- Inadequate Identity and Access Management: A cloud security condition where accounts, tokens, roles, or policies allow more reach than intended. In practice, the weakness is not just bad authentication but an enforcement failure that lets legitimate identities access resources, actions, or environments beyond their operational need.
- Overprivileged Nhi: An overprivileged NHI is a service account, token, key, or other machine identity that has been granted more access than it needs to do its job. The risk is not theoretical. Excess scope increases blast radius, makes compromise more valuable to attackers, and slows containment when the identity is abused.
- Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
- Policy Simulation: Policy simulation is the practice of making malicious instructions look like legitimate governance text, such as configuration files or rules. It works by exploiting the model’s tendency to trust structured context, which can override the protections that would normally apply to user requests.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider security architecture their programmes depend on.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org