Three claims I want to defend in this piece:
- Cloud security as a discipline is mostly mature.
- AI security, as practiced today, is mostly not.
- The gap between them is the most interesting place to spend the next decade.
I'm putting roughly the next decade of my career into the seam between those three things. This is the longer version of the case I'm making to myself for that bet. Some of it is observation; some of it is hypothesis. I expect to be wrong in places. The point of writing it down now is to make the wrongness visible later.
Cloud security is mature, and that's mostly the problem
Cloud security as a field has had close to twenty years to develop. AWS launched in 2006. The shared responsibility model, IAM as a primary control plane, network segmentation via VPCs, encryption at rest as table stakes, audit logging as a default, infrastructure-as-code as the deployment substrate: all of these are settled questions. There are good books, good certifications, good tooling. A reasonably motivated engineer can become competent at cloud security in a year and very good in three.
That maturity is exactly why it's no longer where the most interesting work is. Mature fields reward depth, not direction. Most of the unsolved problems left in cloud security are scaling problems: how do you do this for a 50,000-person organization, how do you keep a posture management program running for a decade, how do you train enough people to staff a SOC. Important work. Not the work I want to spend a decade on.
The reason cloud security still feels current is that the systems running on top of the cloud keep changing, which keeps surfacing new shapes of the same underlying problem. Containers in 2015. Serverless in 2018. Service meshes in 2020. Each one was “cloud security has to figure out X.” The figuring-out has gotten faster each cycle because the foundational concepts hold up.
AI agents are the next cycle. The figuring-out hasn't happened yet.
AI security is not yet a discipline
When I say AI security isn't mature, I don't mean nobody works on it. I mean there isn't a coherent body of practice that a competent engineer can pick up and apply. There are research papers. There are vendor frameworks (the OWASP LLM Top 10, NIST's AI RMF). There are good blog posts. What there isn't is a settled professional consensus on:
- What “least privilege” means for an agent that needs to take broad actions in response to unbounded inputs
- How you do meaningful threat modeling on a system whose behavior is statistical rather than deterministic
- What the equivalent of a SAST/DAST tooling layer looks like for prompt-and-tool-driven systems
- How you write a security incident postmortem for an event whose root cause is “the model output a sentence that, when interpreted by another component, produced behavior we didn't want”
- How you do continuous compliance for a system whose decision boundary moves every time you swap models
Each of these has answers being proposed in 2026. None of those answers have been pressure-tested at scale yet, because most production AI deployments are too new for the relevant breaches to have happened yet. The field is still in the period before its first real incident year, the AI-native equivalent of the years between the Morris worm and modern endpoint security.
That period is short and it's the most useful one to enter the field in. The first generation of practitioners in any new security discipline gets to define vocabulary, establish norms, and build the tools that everyone else inherits. That work compounds in a way that work in mature fields doesn't.
The seam between cloud and AI is where the field actually is
Most takes on AI security treat it as its own self-contained problem: prompt injection, model theft, training data poisoning, alignment failures. Those problems are real, but they're also the parts of AI security most people are already paying attention to. The under-discussed part is what happens when AI systems are deployed on cloud infrastructure designed for human-driven workloads.
A few examples of the seam that don't fit cleanly in either discipline:
IAM patterns built for humans don't compose with agents. Cloud IAM assumes the principal making a request is a person or a service operating under defined logic. Both are categorizable. An agent is neither; it's a principal whose action set is bounded but whose decision logic is not auditable in the traditional sense. The least-privilege patterns we built around predictable principals stop being load-bearing when the principal is making contextual decisions you can't pre-enumerate.
Audit logs designed for human-paced activity get overwhelmed by agent-paced activity. A human SRE might issue a few hundred privileged actions in a workday. An agent doing the same job might issue a few thousand in an hour. The log pipelines, the SIEM rules, the alert thresholds, all calibrated to the wrong baseline. The signal-to-noise ratio collapses.
The shared responsibility model doesn't cover the model. AWS is responsible for the infrastructure. The customer is responsible for the application. Who's responsible for the behavior of a third-party model API the application calls? The vendor isn't signing up for it. The customer can't inspect it. The cloud provider doesn't see it. There's a gap in the responsibility map that didn't exist when applications were just code.
Threat modeling is harder when one of the parties in your data flow is an LLM. STRIDE works on processes you can reason about deterministically. It's less helpful when one of the processes is “the model decides what to do based on inputs we don't fully control.” The whole methodology assumes you can enumerate the threat surface, and the threat surface of an LLM call is genuinely open-ended.
None of these problems are unsolvable. None of them have settled solutions yet. That's the gap I want to spend time in.
The third leg: visibility
There's a piece of this that gets less attention than it deserves: the most under-served security workflow in 2026 is making the behavior of these systems legible to the humans accountable for them.
Cloud security got this right relatively early. CloudTrail, security hub dashboards, the now-standard practice of pulling audit logs into a central SIEM: the whole observability layer was built so that humans could ask “what happened, who did it, and was that allowed.” Even if the answers were sometimes hard to get to, the data was there.
AI systems don't have an equivalent yet. Most of what passes for “AI observability” today is request-counting and latency-tracking. That's monitoring. It's not security visibility. The questions a security person actually wants to answer about an AI system are not what current AI tooling is built to answer: what has this agent been doing all week, what tools has it been calling and with what arguments, when did its behavior shift and why, what inputs preceded the action that turned out to be wrong.
This is where data visualization stops being a UI concern and becomes a security concern. If the right answer to “what is this agent doing” is a 10,000-row log dump, you don't actually have visibility. You have data. The thing that converts data into visibility is design: what to show, how to summarize it, how to surface anomalies in a form a human can act on.
I think the people who can do that conversion well, for AI systems specifically, are going to be in short supply for a long time. That's the third leg of the bet.
The bet, stated plainly: the place where cloud architecture, AI/ML systems, and security observability overlap is going to be a high-leverage place to be a generalist for the next ten to fifteen years. Not a specialist in any one of them, but a person who can think rigorously about the seam between all three.