What CSA's 2026 cloud threat list says about the enforcement gap
The Cloud Security Alliance published its Top Threats to Cloud Computing 2026 survey today. More than 500 practitioners evaluated the issues they see creating the most risk in cloud environments.
Inadequate identity and access management moved into the #1 spot. AI-enhanced attacks debuted at #2. Insecure third-party resources climbed to #3, and AI system compromise entered the list at #6.
There's an obvious takeaway here about AI changing the threat landscape. But the movement inside the ranking points to something broader: more of the risk practitioners are worried about comes down to what an identity can reach, what it can do, and whether the architecture actually enforces those limits.
That's bigger than misconfiguration prevention. It spans identity, third-party access, segmentation, AI authority, and baseline protection. And in many cases, the controls to address it already exist inside the cloud providers.
Misconfiguration is no longer the whole story
One of the most telling changes this year is what happened to misconfiguration.
Misconfiguration and inadequate change control was the #1 cloud threat in CSA's 2024 report. This year, it fell to #5. Cloud teams certainly haven't stopped misconfiguring resources.
What changed is where practitioners seem to see the bigger source of loss. IAM is now #1. Third-party risk moved up. Two AI threats entered the ranking. Advanced persistent threats climbed from #11 to #7.
Those issues look different on the surface, but they increasingly converge on authority and reach.
An over-permissioned role can take a destructive action because that action was allowed. A third-party integration can reach sensitive resources because a trust relationship gave it access. An AI agent can act across an environment using the credentials and permissions it inherits. A compromised workload can move further than it should because the path exists.
In each case, the important question is not only whether the environment was configured correctly. It's whether the architecture limits what each actor can do, where it can go, and how far a compromise can spread.
AI makes those boundaries more important
AI doesn't replace the fundamentals of cloud security. It puts more pressure on them.
AI-enhanced attacks can move faster. Agents can take more actions across more infrastructure with less human involvement. And because agents are non-deterministic, you can't rely on the agent itself to consistently respect the security boundary.
The boundary has to exist outside of it.
If an agent only needs access to a particular environment, dataset, service, or action, the cloud architecture should enforce that scope regardless of the prompt it receives or the decision it makes.
A prompt can change an agent's intent. It should never expand its authority.
The same principle applies to human identities, workloads, third parties, and attackers operating through compromised credentials. Security gets stronger when the architecture itself constrains the actions that are available.
The controls already exist
This is what makes CSA's ranking particularly interesting from our perspective at Native.
Many of the threats on the list map back to controls AWS, Azure, Google Cloud, and OCI already provide.
Identity and third-party access can be constrained through identity, resource, and perimeter policies. Segmentation can limit how far a compromised identity or workload can move between production, development, data, and other zones. Baseline controls can prevent classes of risky configuration and destructive actions instead of waiting for them to appear as findings.
For AI systems, those same architectural controls can define which resources an agent can reach and which actions it can take, independent of the instructions or context flowing through the agent itself.
These capabilities aren't new. What's difficult is operating them consistently across a large, brownfield, multi-cloud environment.
Why enforcement still stalls
Security teams generally know they should enforce tighter boundaries. The hard part is doing it without breaking production.
Every cloud expresses controls differently. Requirements have to be translated into the right policies for each provider, tested against real workloads, deployed safely, and kept current as the environment changes.
And one question tends to stop enforcement projects cold:
What will this break?
Nobody wants to deploy a new policy and discover afterward that it blocked a critical CI/CD pipeline, service integration, or production workload.
That's why simulation matters. Before a control is enforced, teams should be able to evaluate it against the activity already happening in the environment and see which identities, resources, and actions would be affected. Legitimate exceptions can be handled before the policy ever reaches production.
That makes enforcement something teams can operate continuously, rather than a one-time hardening project they're afraid to revisit.
What I take from the 2026 ranking
CSA's report is a useful view into what cloud practitioners are worried about right now. But the movement inside the ranking may be even more useful than the ranking itself.
The center of gravity is shifting toward identities, access, third parties, AI systems, and attackers operating inside legitimate permissions. Misconfiguration still matters, but it's only one part of a larger enforcement problem.
Identity boundaries, segmentation, and baseline protections can remove entire classes of actions before they become incidents. AI makes that more urgent because the number of actors, the amount of automation, and the speed at which they can operate are all increasing.
At Native, that's the problem we're focused on: turning the security capabilities already built into AWS, Azure, Google Cloud, and OCI into active, operational defenses that teams can safely run across their environments.
You define the intent. Native translates it into provider-native controls, simulates the impact before deployment, and keeps those controls aligned as the cloud changes.
A related project we're working on
Native is also working on a report on AI Security Invariants: the architectural conditions that should remain true regardless of what an AI system decides to do. See the first two blogs on this, here and here.
Related content
More articles
Secure-by-Design PerspectivesAI Security Invariants
DateMarch 20 2026Read6 min
Chris Farris, Ariel Septon
Secure-by-Design PerspectivesYou can lock your AI agents down without breaking production. Here's how.
DateJune 22 2026Read8 min
Jeannie Christensen
Security Architecture & StrategyDetection vs Prevention in Cloud Security
DateMay 25 2026Read12 min
Native Team