The AI Security Blindspot: What builders and leaders need to know before it's too late

Before I founded PanIAM, I spent several years building and deploying AI systems, leading data science teams, shipping models to production, and measuring success in accuracy metrics and business outcomes. Security was someone else’s department. And to be honest, when security engineers came knocking to review what we were building, my first reaction was rarely enthusiasm. They slowed things down, asked questions that felt tangential, and spoke a language that had little to do with what I was trying to accomplish.

I was not uniquely reckless. This is how most AI builders feel, and it is largely how AI systems have been built and deployed over the past decade. The concern was real but abstract, something to manage at the margins rather than a central design constraint.

What changed is not that I became more cautious. It is that I changed vantage points. Building PanIAM forced me to look at AI systems from another angle; from the perspective of what they look like in a cloud environment, what they can access, what happens when something goes wrong. And what I saw made the security engineers’ questions suddenly seem very reasonable.

The goal of this article is to bridge the gap I once stood on the wrong side of. AI is transforming cloud security in three distinct ways, each more important than the last, and the builders, executives, and security teams who understand all three will be far better placed to navigate what comes next.

1. Attackers now have an AI advantage too

The most visible shift is also the most intuitive. AI accelerates attack campaigns in ways that were simply not possible before. Reconnaissance that once required days of manual effort is now automated and run at scale against thousands of targets simultaneously: mapping an organization’s exposed services, identifying vulnerable entry points, crafting convincing phishing content.

This changes the economics of attacking. Previously, sophisticated attacks required sophisticated attackers, which naturally limited their frequency. AI lowers that threshold dramatically. A moderately skilled attacker with access to capable models can now execute campaigns that would previously have required a full team. And while defenders must pay for commercial model access, attackers have a growing ecosystem of open-source models available at no cost.

The result is that the volume, speed, and sophistication of attacks are all increasing at once. According to CrowdStrike’s 2026 Global Threat Report, AI-enabled adversaries increased attacks by 89% year-over-year in 2025. Security teams that were already stretched thin are now facing a fundamentally different threat landscape, one in which the attacker’s leverage has grown considerably faster than most organizations’ defenses have kept pace.

2. AI identities are the new attack surface

The second shift is less visible but potentially more consequential, and it is one that most organizations have not yet fully internalized.

When we think about identity and access management, we instinctively think about human users: employees, contractors, administrators. But in today’s cloud environments, non-human identities have quietly become the majority. Service accounts, API keys, automated pipelines, and increasingly AI agents all operate within cloud infrastructure with their own credentials and permissions. In 2026, it is estimated that non-human identities outnumber human ones in enterprise environments by a ratio of roughly 100 to 1.

AI agents, in particular, represent a new category of cloud actor. Unlike a human user who logs in, performs a task, and logs out, an agent operates continuously, makes decisions autonomously, and often holds broad permissions to do so effectively. It can read from databases, write to storage, call external APIs, spawn sub-processes, and trigger downstream workflows, all without human intervention.

This makes AI agents extraordinarily valuable targets. A compromised agent credential does not give an attacker a foothold from which to escalate: it may already give them production-level access. Traditional identity and access management frameworks, built around human behavior patterns and manually reviewed access cycles, are poorly equipped to govern this. Agent identities accumulate permissions over time, operate across multiple systems simultaneously, and are rarely subject to the same scrutiny as human accounts.

The parallel to human identity management is exact, and so is the solution: least privilege, continuous monitoring, and clear visibility into what each identity can actually access and do. The difficulty is that most cloud environments today have neither the tooling nor the processes to apply these principles to non-human identities at the scale required.

3. Prompt injection: when the input becomes the instruction

The third shift is the most technically subtle, and it is the one I find most instructive as someone who has worked directly with language models.

A core characteristic of current LLMs, one that is not a bug but a design property, is that they have no reliable way to distinguish between instructions given by the operator and content provided as input. The model processes both as text, and that text influences its behavior. This creates an attack vector that has no direct equivalent in traditional software: prompt injection.

In practice, this means an attacker does not need to compromise the agent’s credentials or the underlying system. They only need to craft input that the agent will encounter and act on as if it were a legitimate instruction. A document the agent is asked to summarize, an email it is asked to process, a web page it is asked to retrieve: any of these can contain embedded instructions that redirect the agent’s behavior. Because the agent already has legitimate access to the systems it operates on, the attacker does not need to escalate permissions. They simply need to convince the agent to use the ones it already has. This scenario is no longer theoretical: Palo Alto Networks documented the first in-the-wild cases of indirect prompt injection targeting production AI agents in late 2025.

The consequences depend entirely on what the agent is allowed to do. A read-only agent with limited scope is a manageable risk. An agent with write access to a production database, the ability to send emails on behalf of a user, or permissions to modify infrastructure configuration is a very different proposition. A successful prompt injection against such an agent can cause damage that a human attacker would have needed significant effort and skill to achieve directly.

Having deployed AI systems in production before founding PanIAM, I know how difficult it is to communicate this risk clearly to leadership. The threat feels abstract until it is not, and the instinct when building is to grant permissions generously: it is faster, it avoids friction, and the connection between a permission setting and a potential disaster is rarely obvious to non-technical stakeholders. But the gap between what a system needs to function and what it ends up being able to do is often wider than anyone realizes, and in a world where agents act autonomously at machine speed, that gap can become the difference between an incident and a disaster.

The real problem: two communities that do not speak the same language

Taken together, these three shifts paint a clear picture: the attack surface of cloud environments has expanded significantly, the tools available to attackers have improved dramatically, and the most dangerous new risks are concentrated precisely where AI systems operate.

But I want to resist the conclusion that the answer is simply “better security tools.” That is part of it. Full visibility into your cloud environment, who and what can access what, through which paths, and with what potential impact, is foundational. You cannot manage exposure you cannot see, and the complexity of modern cloud environments means that intuition and manual review are not sufficient.

The deeper problem, though, is that the people building AI systems and the people responsible for securing them are still largely operating in separate worlds. Builders optimize for what a system can do. Security teams think about what it could be made to do. These are genuinely different mental models, and in a world where the blast radius of a misconfiguration has grown enormously, the gap between them is no longer a manageable friction. It is a structural risk.

What is needed is not for builders to become security experts or for security teams to become AI engineers. It is for both communities to develop a shared vocabulary and shared visibility. When a builder can see, in plain terms, what their deployment actually looks like from a security perspective, what it can touch, what it can be tricked into doing, what breaks if a single permission is misconfigured, the conversation changes. The security review stops being an obstacle and starts being useful.

That is the gap PanIAM was built to close. Not by adding more findings to an already overwhelming stack, but by making the actual risk legible to the people who need to act on it, whether they come from a security background or, like me, from the other side.