State of AI in the Cloud 2026: How AI Is Reshaping Cloud Security
AI is no longer a standalone tool, it’s embedded across cloud environments, development workflows, and production systems. This report reveals how AI adoption is expanding the attack surface, accelerating attacker behavior, and introducing new risks through agents, copilots, and automation. Get the data behind what’s changing and what security teams need to do about it.
Identity, API and Privilege Risk in the Cloud
Cloud security increasingly depends on securing human and non-human identities. Strong authentication, digital certificates, identity federation and zero trust are just some of the factors that can reduce API and service account risks, while least-privilege access limits potential damage, because even well-designed security controls can ultimately be breached.
Cloud security continues to be a challenge to any organization that uses the cloud to any significant extent. As with all technology, though, there are some key risks and mitigating activities which, if treated sensibly, can vastly reduce the perils of operating in the cloud.
Beyond The Hard Network Boundary
The first challenge we face when using cloud services is that the perimeter of the network has now extended outside the walls of our offices and datacenters. Largely speaking, though, we have figured out how to address this by realizing that physical boundaries are far less relevant than the identity of the people using our systems. As the saying goes, identity is the new perimeter – and this is something we have written about several times lately (for example: here; here; and here). A laser focus on effective identity management, and the associated controls around authenticating those identities (single sign-on, multi-factor authentication and so on) will bring a massive reduction in cloud-based risks.
Relatively speaking, user identity management isn’t as complex as it can appear. Yes, it can take significant time and effort to do properly, but there is no rocket science to it. Most importantly, as we write this in 2026, most cybersecurity professionals have seen and read enough media coverage about organizations being hacked that the additional step of having to enter MFA codes to log in is undoubtedly a necessary piece of user friction, given the potential impact of a hack.
Non-Human Identity Management
The elephant has not, however, left the room. If we have done identity management well, we can be confident that people are who they say they are. The same is not true, however, for non-human identities (NHIDs). In researching this article, we looked to establish how many types of non-human identity we might use today: the record went to the source that told us there are 58. Practically speaking, though, there are just two broad categories, which we will call inward-facing and outward-facing.
The identities we will refer to as inward-facing are those where our internal systems are authenticating to other internal systems – that is, we are not exposing anything to systems outside the infrastructure we own, manage and control. Examples are service accounts in our in-house applications – for instance where a front-end finance app needs to authenticate itself against the relational database that holds its data. Outward-facing systems is the term we will use to describe where we permit access for non-human entities to call into our systems from outside our infrastructure, such as an application programming interface (API) that we allow external systems to access.
It should be no surprise that inward-facing NHIDs pose a much lower risk than outward-facing ones, simply because we control both ends of the interaction. This does not mean, however, that they are inherently secure – nothing could be further from the truth – and so it is essential that we take a zero trust approach to mitigate the risk of a compromised server or app being used as an attack vector. It is fair, however, to say that the primary security focus should be on the NHIDs that, by definition, outsiders can access directly – the outward-facing identities. As we have already said, we cannot simply add MFA to outward-facing NHIDs because MFA is inherently a human thing. We therefore need alternative ways of authenticating the systems that are accessing our systems from outside.
Non-Human Authentication
The first question to ask is: how can we confidently identify a calling system? What mechanisms are there to identify that system? An obvious starting point is to use IP address allow-lists – to permit inbound connections only from the IP addresses we know belong to the third parties we want to allow in. The obvious drawback here is that the approach only works where we want to limit who can access our system (we will come back to that shortly), but there is another: the IP address we see as the source of a call may not be specific to the system we want to allow in.
What do we mean by this? Imagine the company whose app is calling into our world has a single public-facing IP address on its internet connection. This is very common, as the world has been woefully short of public IPv4 addresses for many years. By permitting that IP address to call our system, we are potentially allowing connections from any system on the caller’s network, not just the application server that needs to connect to us. A breach of any system on their network can therefore hand an attacker a path into our outward-facing systems. While we could insist that third parties calling us use unique internet-facing IP addresses for the specific applications we want to allow in (generally speaking most internet providers can generally find internet-facing IP addresses in ones and twos) it requires the remote party to customize their world. Most importantly, it relies on a level of trust that they will do it correctly and that a future generation of IT staff there will not undo all the good work in a couple of years’ time. IP allow-listing is definitely a great step forward where suitable, but it is not the whole answer.
The core part of the answer is to use digital certificates. The whole point of a digital certificate is as a means of authenticating the party presenting it as part of the service call processes. Now, the level of identity presented by today’s digital certificates is far less than it was 30 years ago (applying for a certificate in the mid 1990s involved presenting evidence of your corporate incorporation documents along with convincing proof that the applicant worked for the company) but nonetheless the certificate provides us with the level of authentication required. Most importantly, though, in the scenario we just painted where hundreds or thousands of devices on a third party’s network might be allowed into our world, only the system(s) in their network that have had the certificate installed will be able to authenticate to our outward-facing application. Incidentally, the global trend is for the lifetime of digital certificates’ lifetimes to reduce over time; while this is an inconvenience, it is one that we all need to embrace and work with, because it limits our exposure.
Even better, we can look to use identity federation, in which both we and the third parties accessing our systems use a trusted identity provider (Microsoft’s Entra ID is a common example – other federated ID providers are available) as the means of authenticating calls into our systems. It is common to use federated identity for user logins, but it is highly recommended that we should not use it for NHIDs too.
The Perils of Permissions
Having dealt with authentication and identity, there is a third essential element to access control: permissions. It is essential that we keep to a minimum the range of devices that an NHID can connect to, and also to minimize the permissions they have once they get there. Happily, the attitude of software vendors to permissions minimization these days is far better than it was (not so many years ago the installation manual for a web-facing app we were installing told us to punch a hole through the firewall to the SQL Server host and set up a Service Account with “database owner” permissions) but we need to be absolutely sure that the only permissions we grant are the ones that are needed.
Officer of the Watch
Finally, regardless of what defenses we have put in place, we must watch like a hawk to see how our systems are behaving. Even when we have strong authentication in place, there is always a chance of a breach occurring and we need to spot them when they do and be able to contain them. If we are hosting public-facing systems – that is, something where we are unable to enforce certificates, IP allow-listing or identity federation then we need to go much, much further and monitor what we can see – patterns of activity, unusually high transaction counts, connections coming in at unusual times of day, and so on. Regardless of the defenses we are able to put in place, we should assume that they can be breached and that something bad can happen.
