The Cloud Has Changed — Our Security Model Hasn’t
Introducing an eight-part CISOsCISO series on what the CSA Top Threats to Cloud Computing 2026 really mean for security leaders
By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.
Eight Questions for the CISO
This CISOsCISO series will use the CSA Top Threats to Cloud Computing 2026 as its starting point.
But it will not simply reproduce the threat ranking.
Over eight articles, I want to explore what sits underneath it.
Part 1 — The Cloud Has Changed — Our Security Model Hasn’t
Why the cloud attack surface is shifting from infrastructure toward identities, relationships and autonomous actors.
Part 2 — Identity Is Becoming the New Cloud Control Plane
Why identity is no longer merely an access mechanism but increasingly the mechanism through which infrastructure itself is controlled.
Part 3 — When Non-Human Identities Outnumber Humans
What happens when service principals, workloads, automation and AI agents become the dominant identity population.
Part 4 — AI Doesn’t Replace Cyberattacks — It Compresses Them
How AI changes attack economics by reducing time, cost and skill while increasing scale and adaptability.
Part 5 — Your Cloud Boundary Is Now Someone Else’s API
Why SaaS, APIs, AI components and service dependencies require a different model of third-party governance.
Part 6 — AI Systems Are Becoming Security Domains of Their Own
Why AI security cannot remain merely a subsection of application security.
Part 7 — From Least Privilege to Least Agency
Why controlling individual permissions may not control the cumulative capability of an autonomous actor.
Part 8 — The CISO’s Cloud Security Agenda for 2027
How identity governance, AI security, dependency governance, observability and resilience may need to converge into a new security operating model.
For more than a decade, cloud security has been built around a relatively familiar set of questions.
- Is the infrastructure configured securely?
- Are workloads patched?
- Is data encrypted?
- Are privileged accounts protected?
- Are logs collected?
- Are APIs secured?
- Are suppliers assessed?
- Do we know where our data resides?
None of these questions has become irrelevant.
But they are no longer sufficient.
The Cloud Security Alliance’s Top Threats to Cloud Computing 2026 provides an interesting indication of why.
At first glance, the report looks like another evolution of the cloud threat landscape.
Identity has moved to the top.
AI-enhanced attacks have entered the ranking at number two.
Third-party risk remains near the top.
APIs remain problematic.
AI systems themselves are becoming attack targets.
But reading the individual threats as a ranking misses the more important story.
The nature of the cloud attack surface is changing.
And with it, the security model that CISOs have relied upon for years may need to change as well.
The Ranking Is Not the Most Interesting Part
Security reports naturally encourage us to look at rankings.
- What moved up?
- What moved down?
- What is new?
The CSA’s 2026 findings certainly provide answers.
Inadequate Identity and Access Management has moved from number two to the top position.
AI-Enhanced Attacks appear as a major new concern.
Insecure Third-Party Resources remain among the leading cloud risks.
These movements matter.
But for a CISO, the more interesting question is not where an individual threat appears on a list.
It is:
What do these threats have in common?
Look at them together and a pattern begins to emerge.
Identity.
AI.
Third-party services.
APIs.
Autonomous agents.
Machine identities.
AI-generated components.
Multi-agent systems.
These are not primarily isolated infrastructure problems.
They are relationship problems.
The risk increasingly exists in the connections between systems, identities, services and actors.
That is a profound change.
From Assets to Relationships
For years, cybersecurity has been organized around things.
- Servers.
- Endpoints.
- Applications.
- Databases.
- Networks.
- Accounts.
- Cloud workloads.
We inventory them.
We classify them.
We scan them.
We patch them.
We assign controls to them.
Eventually, we calculate residual risk.
That model works reasonably well when the system we are protecting can be decomposed into identifiable components.
But consider a modern cloud environment.
An AI agent reads a SharePoint document.
The document influences the agent’s reasoning.
The agent calls an API.
The API invokes a cloud service.
The cloud service uses a workload identity.
The workload identity receives temporary credentials.
Those credentials trigger an automation pipeline.
The pipeline modifies another environment.
Another agent may consume the result.
Where exactly is the security boundary?
Which asset owns the risk?
Which individual control determines whether the process is secure?
Increasingly, there may be no satisfactory answer.
Because the risk does not reside exclusively in any single component.
It emerges from the composition.
The modern cloud attack surface is therefore becoming less like an inventory.
It is becoming a graph.
A graph of identities, permissions, APIs, services, data, dependencies and increasingly autonomous actors.
Attackers do not have to compromise every node.
They need to discover the right path through the graph.
Identity Is Becoming Infrastructure
Perhaps the clearest indication of this change is identity.
Identity was once largely about people.
Employees had accounts.
Administrators had privileged accounts.
Applications occasionally had service accounts.
IAM governed who could access what.
That world is disappearing.
Modern cloud environments contain service principals, workload identities, API credentials, automation identities, machine identities, short-lived tokens and increasingly AI agents.
The CSA explicitly highlights the growing importance of non-human identities.
This is more significant than it may initially appear.
Because identity is no longer simply the mechanism through which humans access infrastructure.
Identity increasingly controls infrastructure.
A workload identity can deploy resources.
A service principal can modify configuration.
A CI/CD identity can change production.
An automation identity can create credentials.
An AI agent can invoke tools.
And an agent equipped with an identity, an OAuth token and access to enterprise APIs may no longer simply use a system.
It may act within it.
That changes the IAM question.
Traditional IAM asks:
Who can access this resource?
The emerging question is:
What can this identity cause to happen?
Those are not the same thing.
AI Changes Both Sides of the Equation
The CSA’s 2026 findings introduce another important shift.
AI appears on both sides of the security equation.
Attackers can use AI to improve reconnaissance, phishing, vulnerability discovery and attack automation.
At the same time, defenders are introducing AI systems, copilots and autonomous agents into their own environments.
AI therefore becomes simultaneously:
an attack accelerator,
an attack target,
a business capability,
a privileged actor,
and potentially part of the security control plane itself.
This makes AI security fundamentally different from many previous technology transitions.
The problem is not simply that organizations are deploying another class of application.
AI systems increasingly interact with other systems.
They consume context.
They retrieve enterprise information.
They make decisions.
They invoke tools.
And increasingly, they act.
The transition from generative AI to agentic AI therefore represents something much more significant than another generation of chatbot technology.
It introduces a new class of actor into enterprise environments.
From Shadow IT to Shadow Agency
We already know the concept of Shadow IT.
A business unit subscribes to a SaaS application without involving IT.
An employee uploads information into an unapproved service.
A team creates an application outside established governance processes.
The problem was visibility.
We did not know which technology was being used.
Shadow AI expands that problem.
But agentic AI changes it again.
The question is no longer simply:
Which applications are employees using?
It becomes:
Which actors are operating inside our environment — and what authority have we given them?
An AI agent may possess an identity.
That identity may possess tokens.
Those tokens may provide access to APIs.
Those APIs may invoke tools.
Those tools may change enterprise systems.
At that point we are no longer dealing merely with Shadow IT.
We are approaching Shadow Agency.
And that may become one of the defining governance challenges of the next phase of cloud computing.
Least Privilege May No Longer Be Enough
Cybersecurity has spent decades building around the principle of least privilege.
Give an identity only the permissions necessary to perform its task.
It remains one of the most important principles in security.
But agentic systems expose a limitation.
Imagine an AI agent with several individually reasonable permissions:
read email,
read documents,
query a database,
create a ticket,
write a file,
invoke an API,
trigger a workflow.
No single permission necessarily appears dangerous.
But the agent can combine them.
- Read.
- Interpret.
- Correlate.
- Decide.
- Invoke.
- Trigger.
- Modify.
The resulting capability may be far more powerful than the individual permissions suggest.
That leads to a concept I believe security leaders will increasingly need to consider:
Least Agency.
Least privilege asks:
What can this identity access?
Least agency asks:
What outcomes can this actor produce?
Privilege is largely a property of permissions.
Agency is a property of composition.
That distinction will become increasingly important as AI agents gain access to enterprise tools and cloud control planes.
The Third Party Is Moving Inside the Transaction
The same structural change can be seen in third-party risk.
Traditional third-party governance assumes identifiable suppliers.
A company purchases a service.
Procurement knows the supplier.
Legal reviews the contract.
Security performs an assessment.
The relationship enters a vendor register.
Modern cloud architectures are considerably more complicated.
A business transaction may depend on:
a SaaS provider,
an identity provider,
an API gateway,
a cloud platform,
an open-source component,
an AI model,
a managed API,
an MCP server,
and several downstream services.
Some of these dependencies may never appear in a traditional supplier assessment.
Yet they can influence the transaction.
This suggests another important change.
Your security boundary is no longer where your infrastructure ends.
It increasingly extends to every external dependency capable of influencing a business outcome.
That boundary is much harder to inventory.
And much harder to govern.
AI Security Is Becoming a Security Domain of Its Own
There is another lesson in the CSA findings that deserves attention.
Attacks against AI systems themselves are becoming sufficiently important to be considered separately.
Prompt injection is perhaps the most familiar example.
But the broader problem includes models, prompts, training and retrieval data, vector stores, identities, memory, tools, APIs and the systems to which an AI agent is connected.
This should feel familiar.
We made a similar mistake during the early years of cloud computing.
Organizations initially treated cloud as another hosting environment.
Put the same applications somewhere else.
Apply roughly the same controls.
Eventually we learned that cloud required different architecture, governance, operating models, competencies and security controls.
We may currently be repeating that mistake with AI.
An AI system is increasingly not merely:
Model + Prompt.
It may instead be:
Model + Context + Data + RAG + Memory + Identity + Tools + APIs + Agents + Human Approval.
That is an entirely different security object.
The Real Shift: From Control to Agency
Taken together, the CSA findings point toward something larger than another annual change in cloud threats.
Cloud computing has evolved through several security eras.
First we protected infrastructure.
Then we protected workloads.
Then identities became central.
Then APIs and supply chains expanded the boundary.
Now AI agents are beginning to introduce autonomous action.
The security question evolves accordingly.
Who can access the system?
becomes:
Who can act within the system?
And eventually:
How much agency have we delegated — intentionally or unintentionally?
That is why the next generation of cloud security cannot be understood purely through vulnerability management, configuration management or access control.
It increasingly becomes a question of governing digital agency.
Five Questions May Matter More Than Eleven Threats
The CSA concludes its presentation of the 2026 threat landscape with four broad priorities: strengthen identity governance, treat AI as a dedicated security domain, improve governance of third-party ecosystems, and increase visibility, resilience and operational awareness.
Those are sensible priorities.
But from a CISO perspective, I would translate the underlying challenge into five questions.
Who can act?
Identity.
What can they cause?
Agency.
What do they depend on?
Dependencies.
Can we see what happened?
Observability.
Can we continue when trust fails?
Resilience.
If a security organization cannot answer those questions, having an inventory of controls may provide considerably less assurance than we think.
Because the fundamental challenge is changing.
The cloud was once primarily a place where organizations moved infrastructure.
It became a platform on which organizations built businesses.
Now it is becoming an environment populated by software actors capable of making decisions and taking actions across interconnected systems.
That changes what it means to maintain control.
And ultimately, that is the question behind this entire series.
Not whether we have enough controls.
Not whether we passed the audit.
Not even whether every individual component is secure.
But something more fundamental:
Do we still understand who and what can act inside our digital environment — and do we retain the ability to constrain that action when it matters?
Because the next era of cloud security may not be defined by who controls the infrastructure.
It may be defined by something much more consequential:
Who controls the agency.
Publication Note & Disclaimer
This article provides security and governance analysis, not legal advice. Regulatory obligations must be assessed against the facts, jurisdictions, data types, and roles of the organizations involved.
This article reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.
For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.
Member discussion