CSA Top Threats 2026 — Part 1 of 8

Why the cloud attack surface is shifting from infrastructure toward identities, relationships and autonomous actors.

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

For years, we have been securing the cloud as if the cloud were primarily a collection of things.

• Virtual machines.
• Containers.
• Storage accounts.
• Databases.
• Applications.
• Networks.
• Endpoints.
• Accounts.

We inventory them.

We classify them.

We configure them.

We scan them.

We patch them.

We monitor them.

And eventually, we assign controls and calculate something called residual risk.

This model has served us reasonably well.

It also increasingly describes the wrong problem.

The Cloud Security Alliance’s Top Threats to Cloud Computing 2026 provides an interesting signal of that change.

Identity has moved to the top of the threat ranking.

AI-enhanced attacks have entered near the top.

Third-party resources remain a major concern.

APIs continue to expose critical dependencies.

AI systems themselves have become attack targets.

And autonomous agents and multi-agent systems are beginning to create entirely new attack surfaces.

Taken individually, these look like different security problems.

Taken together, they point toward something more fundamental.

The cloud attack surface is shifting from infrastructure toward relationships.

And our security model has not fully caught up.

We Still Think in Assets

Most security programs are fundamentally asset-centric.

That is visible everywhere.

• Our CMDB contains assets.
• Our vulnerability scanner finds vulnerabilities on assets.
• Our EDR protects endpoints.
• Our CSPM examines cloud resources.
• Our IAM platform manages identities.
• Our application security program assesses applications.
• Our third-party risk process assesses suppliers.
• Our SIEM collects events from systems.

Even our risk registers often follow this logic.

• Asset.
• Threat.
• Vulnerability.
• Control.
• Residual risk.

This decomposition is useful because it makes complexity manageable.

We divide a large environment into smaller objects and secure them individually.

But there is a hidden assumption behind this model:

If the individual components are sufficiently secure, the resulting system will also be sufficiently secure.

That assumption is becoming increasingly dangerous.

Because modern cloud environments derive much of their power — and increasingly much of their risk — not from individual components but from the relationships between them.

Attackers Do Not See Your CMDB

Imagine a modern enterprise workflow.

• An employee receives an email.
• An AI assistant summarizes it.
• The assistant retrieves additional information from SharePoint.
• An agent interprets the request.
• It invokes an enterprise API.
• The API uses a workload identity.
• That identity receives a short-lived token.
• The token accesses a cloud service.
• The service triggers an automation pipeline.
• The pipeline modifies a configuration.

Another system consumes the result.

• Every individual component may be legitimate.
• Every individual identity may be authenticated.
• Every API call may be authorized.
• Every connection may be encrypted.
• Every cloud service may be correctly configured.

And yet the resulting sequence may produce an outcome nobody intended.

This is the security problem we increasingly need to understand.

An attacker does not necessarily need one catastrophic vulnerability.

They need a path.

Document → Agent → Tool → API → Identity → Cloud Service → Automation → Outcome

The weakness may not exist in any individual node.

It may exist in the composition.

That is why attackers do not care how our CMDB is organized.

They care about what connects to what.

They care about which identity can reach which service.

They care about which service trusts which token.

They care about which API can trigger which workflow.

They care about which data can influence which agent.

And increasingly, they care about which autonomous actor can invoke which tool.

The attacker sees a graph.

The defender often still sees an inventory.

That asymmetry matters.

The Cloud Became a Relationship Machine

The first generation of cloud security was heavily infrastructure-oriented.

That made sense.

Organizations were moving workloads from environments they controlled physically into environments they controlled logically.

Security therefore focused on questions such as:

Is the storage bucket public?

Is the security group correctly configured?

Is the administrative interface exposed?

Is encryption enabled?

Is the workload patched?

Are credentials protected?

These questions remain important.

But cloud computing evolved.

Infrastructure became programmable.

Identity became the control plane.

APIs became the connective tissue.

SaaS became embedded in business processes.

Automation connected environments.

CI/CD connected development directly to production.

Third-party services became runtime dependencies.

And now AI agents are beginning to connect reasoning with execution.

The result is something fundamentally different from a traditional data center.

The cloud is no longer simply infrastructure somewhere else.

It is a highly interconnected execution environment.

And execution environments create risk through paths.

Identity Is No Longer Just About Login

The CSA’s decision to place inadequate identity and access management at the top of its 2026 threat ranking is therefore particularly interesting.

For many organizations, IAM still carries conceptual baggage from an earlier era.

Identity means users.

Users need accounts.

Accounts receive permissions.

Privileged users receive additional controls.

Employees leave.

Accounts are disabled.

That model is increasingly incomplete.

Cloud environments are full of identities that never log into anything.

Service accounts.

Service principals.

Workload identities.

API identities.

Automation identities.

Managed identities.

Machine identities.

Temporary credentials.

Application tokens.

And increasingly:

AI agents.

CSA specifically highlights the challenge created as non-human identities outnumber human users.

That changes the problem.

A human identity generally has an organizational context.

There is an employee.

A manager.

A department.

A role.

A contract.

A lifecycle.

A departure date.

But who is the manager of a workload identity?

Who owns an API token?

Who periodically reviews an automation credential?

Who knows whether a service principal created three years ago is still necessary?

Who terminates the identity of an AI agent when the experimental project that created it quietly disappears?

The technical identity may be perfectly valid.

The governance around it may not exist.

The Real Attack Surface Is the Trust Graph

This suggests a different way of thinking about cloud security.

Instead of asking only:

What assets do we have?

we need to ask:

What trusts what?

Which identity can call which API?

Which API can invoke which service?

Which service can obtain which token?

Which workload can assume which role?

Which automation can modify which environment?

Which third party can influence which transaction?

Which document can influence which AI agent?

Which agent can invoke which tool?

Which tool can perform an irreversible action?

These relationships form what we might call the organization’s trust graph.

And the graph may reveal risks that traditional asset-centric assessments do not.

Consider three systems.

System A contains no critical vulnerability.

System B contains no critical vulnerability.

System C contains no critical vulnerability.

Individually, all three may pass their security assessments.

But:

A can influence B.

B can authenticate to C.

C can modify production.

The resulting attack path may be critical.

The risk exists in the edges.

Not necessarily in the nodes.

AI Makes the Graph Executable

This is where AI agents make the problem particularly interesting.

Traditional software follows predefined logic.

An application performs actions developers explicitly programmed.

Automation expanded this model, but workflows were still largely deterministic.

Agents introduce something different.

They can interpret context.

Select tools.

Combine information.

Choose intermediate actions.

Adapt their behavior.

And potentially pursue goals across multiple systems.

In other words, AI does not merely add another node to the enterprise graph.

AI can navigate the graph.

That distinction matters enormously.

A traditional application might have five API integrations because a developer explicitly programmed five workflows.

An agent may have five tools and dynamically decide which sequence of those tools is appropriate.

The permissions have not necessarily changed.

But the effective capability has.

This is why the rise of autonomous agents and multi-agent systems deserves more attention than simply adding “AI Security” to an existing control catalogue.

We are introducing software actors capable of combining permissions at runtime.

That is a different security problem.

Read-Only Does Not Necessarily Mean Harmless

This also challenges one of our familiar security intuitions.

Consider an agent with predominantly read-only access.

It can read email.

It can read documents.

It can query customer records.

It can inspect calendars.

It can retrieve configuration information.

Individually, each permission might appear low risk.

But the agent can correlate those sources.

It can infer relationships.

It can discover sensitive context.

It can identify decision-makers.

It can understand workflows.

It can pass information to another system.

And if one of its tools permits an action, the accumulated context can influence that action.

The relevant question is therefore no longer simply:

What permission does the agent have?

It is:

What capability emerges from the combination of its permissions, context and tools?

That distinction will become increasingly important.

Because the security of agentic systems cannot be determined solely by examining permissions individually.

A Human in the Loop Does Not Automatically Solve This

One response is obvious.

Keep a human in the loop.

That sounds reassuring.

But it only works if the human can independently understand what they are approving.

Imagine an agent that has:

retrieved several documents,

queried two APIs,

interpreted an email,

correlated customer information,

selected a workflow,

generated parameters,

and prepared an action.

The user now sees:

Approve?

Is that meaningful human control?

Perhaps.

Perhaps not.

The relevant question is:

Could the human independently understand and verify the exact consequence before execution?

Because a human in the loop is not automatically a security control.

It becomes a security control only when the human can meaningfully evaluate the decision.

Once approval becomes habitual rather than deliberative, the human may no longer be the last line of defense.

The human may simply become another node in the attack path.

Third Parties Are Becoming Runtime Dependencies

The CSA report also keeps insecure third-party resources near the top of the cloud threat landscape.

Again, the interesting issue is not merely supplier security.

The meaning of “third party” itself is changing.

Traditionally, third-party risk looked relatively clear.

There was a supplier.

There was a contract.

There was a service.

There was an assessment.

There was an owner.

Modern cloud systems may instead rely on:

SaaS platforms,

managed APIs,

identity providers,

open-source libraries,

cloud marketplaces,

AI models,

AI-generated components,

MCP servers,

external data sources,

and services consumed dynamically at runtime.

The third party is no longer necessarily outside the business process.

It may be embedded directly inside the transaction.

That means supplier governance and technical architecture can no longer remain separate disciplines.

The important question becomes:

Which external dependency can influence a critical business outcome?

That is a very different inventory from a supplier list.

We Need to Map Paths, Not Just Assets

None of this means asset management becomes irrelevant.

Quite the opposite.

You cannot understand relationships if you do not know the objects being connected.

But asset inventory becomes the beginning of the analysis rather than the end.

The next layer is relationship discovery.

Identity paths.

Trust relationships.

API dependencies.

Data flows.

Token exchanges.

Automation chains.

Agent-to-tool relationships.

Third-party dependencies.

Human approval points.

And ultimately:

attack paths.

This also changes vulnerability management.

A vulnerability with a CVSS score of 9.8 on an isolated system may matter less than a seemingly minor weakness positioned on a path from an exposed identity to a critical control plane.

Context becomes decisive.

The question is no longer simply:

How severe is this vulnerability?

It becomes:

What does this weakness connect?

The CISO’s Problem Is Becoming Graph-Shaped

This has an uncomfortable organizational consequence.

Most enterprises are not structured like their attack surface.

IAM has one owner.

Cloud has another.

Application security sits somewhere else.

Supplier risk belongs to procurement or GRC.

SOC monitors events.

AI governance may sit with a newly created committee.

Data protection has its own mandate.

Developers own APIs.

Business units own processes.

Every function sees part of the graph.

Very few see the whole graph.

Attackers do not respect those organizational boundaries.

An attack path can cross:

Identity → SaaS → API → AI → Cloud → Supplier → Business Process

without caring which department owns each component.

That creates a governance challenge for the CISO.

Not because the CISO should operationally own all of these domains.

They should not.

But someone must be able to identify when individually acceptable decisions combine into an unacceptable systemic risk.

That is increasingly the security leadership problem.

Control Effectiveness Becomes Contextual

This also changes how we should think about controls.

Take MFA.

MFA may work perfectly for human administrators.

But what does MFA mean for a workload identity?

Take privileged access management.

It may govern administrative accounts very well.

But does it govern machine identities and agent tokens?

Take supplier assessment.

A strategic SaaS provider may undergo extensive due diligence.

But what about an API introduced by a developer?

Or an MCP server connected to an AI agent?

Take change management.

It may govern infrastructure changes.

But does it capture a change in an agent’s toolset?

A new model?

A new system prompt?

A new external data source?

A new permission that seems harmless individually but creates a new path when combined with existing permissions?

The control may exist.

The control may even be effective within its intended scope.

And yet the organization may still lose control of the system as a whole.

This is one of the central security challenges of highly interconnected environments.

Local control effectiveness does not guarantee systemic control effectiveness.

From Attack Surface Management to Attack-Path Governance

External Attack Surface Management was an important evolution.

It moved organizations beyond simply maintaining an internal asset inventory toward understanding what attackers could actually see from outside.

But the next step may need to go further.

Because visibility alone does not describe how compromise propagates.

We need to understand paths.

Which identities can move where?

Which systems trust one another?

Which APIs bridge security domains?

Which credentials allow lateral movement?

Which agents can combine tools?

Which external services can influence internal decisions?

Which paths terminate in critical business processes?

This is not merely attack surface management.

It is attack-path governance.

And governance matters because not every path can or should be eliminated.

Modern organizations depend on connectivity.

APIs must communicate.

Workloads need identities.

Automation requires permissions.

AI agents need tools if they are to deliver meaningful value.

The objective therefore cannot be zero connectivity.

The objective is to understand which paths exist, which paths matter, and where the organization must constrain them.

The Security Model Must Follow the Architecture

Security architecture has always had to follow technology architecture.

Mainframes produced one security model.

Client-server computing produced another.

The internet changed it again.

Cloud changed it again.

Agentic computing will do the same.

The mistake would be to assume that our existing controls can simply be extended indefinitely without reconsidering the underlying model.

We cannot protect graph-shaped systems indefinitely with purely asset-shaped thinking.

We will still need asset inventories.

We will still need vulnerability management.

We will still need IAM.

We will still need API security.

We will still need supplier assurance.

We will still need logging.

But increasingly, we must understand how these controls interact across relationships.

Because that is where systemic risk emerges.

The Question I Would Ask as a CISO

If I had to reduce this shift to one question for a security leadership team, it would not be:

Do we know all our cloud assets?

That is important, but insufficient.

I would ask:

Can we explain the most consequential paths through our digital environment?

From an external identity to production.

From a compromised endpoint to a cloud control plane.

From a third-party service to sensitive data.

From an API token to a critical transaction.

From an AI prompt to a tool invocation.

From an agent identity to an irreversible business action.

And from one apparently low-risk permission to another until their composition becomes high risk.

If we cannot answer those questions, then we may know our components without understanding our system.

That is not the same thing as control.

Cloud Security Is Becoming the Governance of Relationships

The CSA’s Top Threats to Cloud Computing 2026 can be read as another threat ranking.

Identity moved up.

AI arrived.

Third-party risk remains.

APIs remain difficult.

AI systems need protection.

All true.

But I think the more important message lies underneath the ranking.

The individual categories are converging.

Identity connects systems.

APIs connect services.

Third parties extend processes.

AI interprets context.

Agents connect reasoning to action.

Automation turns decisions into execution.

The cloud attack surface is therefore becoming increasingly relational.

And once security becomes relational, the central question changes.

It is no longer enough to ask whether each component is secure.

We must ask:

What becomes possible when they are connected?

That is where the next generation of cloud risk will increasingly emerge.

Not necessarily from one catastrophic vulnerability.

Not necessarily from one compromised administrator.

Not necessarily from one insecure server.

But from a chain of individually legitimate capabilities that together produce an illegitimate outcome.

The cloud has changed.

Our security model must change with it.

Because attackers already understand something defenders are only beginning to operationalize:

The real attack surface is not the collection of assets.

It is the set of paths between them.

Next in the series: Part 2 — Identity Is Becoming the New Cloud Control Plane — why identity is evolving from an access mechanism into the infrastructure through which humans, workloads, automation and AI agents exercise power across the cloud.

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.