❌

Normal view

Received today — 11 July 2026 ⏭ Anton on Security

From Cloud to Chaos: Defining Shared Responsibility for AI Security

✇Anton on Security
By: Anton Chuvakin
2 July 2026 at 19:26

For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many “cyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.

Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.

Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?

Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predate cloud).

Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…

Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In my opinion:

  1. A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations about AI.
  2. The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
  3. Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.

Early attempts to create a logical foundation for AI shared security responsibility produced some answers — and more questions.

In light of this being a tricky problem, here I really want to focus on one thing — a post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog). So:

  • Who takes a loss vs who is to blame?
  • Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blame myself?

If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a “shared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.

I was recently involved with a CoSAI (Coalition for Secure AI) working group to develop a paper covering the shared responsibility framework for AI security. As others on the team humorously pointed out, my voice was one of the loudest calling for the paper to be kept simple, crisp, and highly usable. You can judge based on the final result whether we succeeded.

CoSAI matrix

We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI system fails?

Under the CoSAI framework, accountability traces down the stack with absolute clarity:

  • The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the model card.
  • The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
  • The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the first place.
  • The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing it live.
Layers

Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific path forward:

  1. Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
  2. Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
  3. Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them for you.

Fun quotes:

  • “Ambiguous ownership is a growing liability for Al system deployments.” [A.C. — filed under ‘no shit, Sherlock’]
  • “Without explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C. — this will get worse, then MUCH worse, then eventually better…]
  • “The framework turns ‘whose fault is this?’ into ‘which layer’s controls failed, and who owns remediation for each?’” [A.C. — this is beautifully, I probably wrote this :-)]
  • “There should be exactly one accountable party per component to prevent overlaps.” [A.C. — ideal world called, it wants its problem back! Real world picked up and said ‘get lost’]
  • “Clear accountability eliminates finger-pointing during incidents” [A.C. — clear evidence that Captain Obvious is alive!]

More seriously, read the paper!

In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gems there!)

Related blogs:

From Cloud to Chaos: Defining Shared Responsibility for AI Security was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Anton’s Security Blog Quarterly Q2 2026

✇Anton on Security
By: Anton Chuvakin
30 June 2026 at 20:16

My Anton’s Security Blog Quarterly covers both Anton on Security and my posts from Google Cloud blog, Google Cloud community blog, and our Cloud Security Podcast (subscribe on Spotify, now with VIDEO).

Top 10 posts with the most lifetime views (excluding paper announcement blogs):

  1. Anton’s Alert Fatigue: The Study [A.C. — wow, this is still #1 now! Awesome! Perhaps I need more of such deep studies]
  2. Security Correlation Then and Now: A Sad Truth About SIEM
  3. Can We Have “Detection as Code”?
  4. Detection Engineering is Painful — and It Shouldn’t Be (Part 1)
  5. Revisiting the Visibility Triad for 2020 (update for 2025 is here!)
  6. Beware: Clown-grade SOCs Still Abound
  7. Why is Threat Detection Hard?
  8. Top 10 SIEM Log Sources in Real Life?
  9. A SOC Tried To Detect Threats in the Cloud … You Won’t Believe What Happened Next
  10. Log Centralization: The End Is Nigh?

Top 5 posts with paper announcements:

  1. New Paper: “Future of the SOC: SOC People — Skills, Not Tiers” (paper 2 of the series)
  2. New Paper: “Future of the SOC: Evolution or Optimization — Choose Your Path” (Paper 4 of 4.5) (one more paper coming later in 2026 … we are in reviews now!)
  3. New Paper: “Future of the SOC: Forces shaping modern security operations”
  4. New Paper: “Future Of The SOC: Process Consistency and Creativity: a Delicate Balance” (Paper 3 of 4)
  5. New Paper: “Autonomic Security Operations — 10X Transformation of the Security Operations Center” (Our classic 2021 ASO paper! Still epic, still relevant)

3 random fun posts, must-read:

Top 7 Cloud Security Podcast by Google episodes (excluding the oldest 3!):

  1. EP150 Taming the AI Beast: Threat Modeling for Modern AI Systems with Gary McGraw
  2. EP75 How We Scale Detection and Response at Google: Automation, Metrics, Toil
  3. EP47 “Megatrends, Macro-changes, Microservices, Oh My! Changes in 2022 and Beyond in Cloud Security”
  4. EP153 Kevin Mandia on Cloud Breaches: New Threat Actors, Old Mistakes, and Lessons for All
  5. EP109 How Google Does Vulnerability Management: The Not So Secret Secrets!
  6. EP17 Modern Threat Detection at Google
  7. EP156 Living Off the Land and Attacking Critical Infrastructure: Mandiant Incident Deep Dive

Now, fun posts by topic.

Security operations / detection & response:

Cloud security:

How Google Does Security (HGD) — the new master site How Google Does It: An inside look at cybersecurity:

(if you only read one, choose this one! BTW, we also have a lot of fun HGD podcasts)

AI security:

Fun presentations shared (nothing much new here):

Enjoy!

Previous posts in this series:

Anton’s Security Blog Quarterly Q2 2026 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1)

✇Anton on Security
By: Anton Chuvakin
29 June 2026 at 23:24

One particular aspect of an agentic or AI-powered SOC (but NOT “humanless SOC”) has bothered me over the last few months: specifically, the people and process side of such a SOC. If you recall my blog posts (part 1, part 2 and this video) about AI SOC readiness, I hinted at certain elements of a traditional process stack and legacy personnel profiles (both technical and leadership) that make AI adoption inside SOC incredibly difficult.

So we (me and Augusto Barros @ Prophet Security) want to create a modernized people and process framework for a SOC powered by AI and intelligent agents. Otherwise, what I am observing is a lot of “robotic horse pulls a buggy” kind of operations — where everything is kept exactly the same as it was in 2003, but “AI SOC” tools are simply tacked on to perform some of the tasks.

Gemini visual of old SOC with “AI SOC” tools

I believe that people and process components must change far more dramatically, and such changes are a critical requirement for achieving “step change” SOC with AI capabilities. Simply adding AI tools and Ai agents to a 2003-style SOC will produce, at best, marginal results. Things would get better, but not better enough to counter the feared “bad guy with AI.”

The SOAR Analogy

The analogy I want to use here is SOAR adoption from 10+ years ago. Back then, organizations simply shifted a few processes — or even just specific tasks — to a machine, and then kept the rest of their operations exactly the same. Because of that, I observed a lot of SOAR tools being used strictly for alert enrichment or for dealing with one specific, isolated type of alert, like phishing. To follow this analogy to the present day, I now frequently see an “AI SOC” being utilized only for EDR alerts or only for phishing alerts (wow, what a coincidence!)

A First-Principles Approach

What I really want to build is a first-principles approach to the specific personnel, skills, processes, and practices required to run a true agentic SOC in the late 2020s.

Now, if you prefer incremental change, that is OK, I won’t judge. However, you must be aware that the same principles caused organizations to struggle with cloud adoption. People often hear that “lift and shift” is bad. Most consultants will tell you that “lift and shift” is fine as a first step, but you eventually need to modernize and take more steps. Unfortunately, many organizations never make that second step. The same risk applies to the AI SOC. 2003 SOC + AI = somewhat better 2003 SOC.

BTW, many artifacts of the modern, engineering-powered SOC — which we covered in our now-famous ASO (Autonomic Security Operations) paper back in 2021s — apply here as well. In fact, if you recall, one of our core principles was: Humans build machines; machines do the work.

In the context of an agentic SOC, that evolves into:

Today, humans build the machines with the help of other machines, and then the machines do the heavy lifting.

So, our questions so far:

  • What do humans do in an agentic SOC?
  • What do entry-level humans do?
  • What SOC processes stay the same despite AI?
  • What SOC processes can just go and vanish (triage)?
  • What processes get handed to machines?
  • Are there new processes for humans?
  • What is the new human role for validation?
  • How do we check AI quality without fully redoing the work?
  • How SOC metrics must change due to AI and agents? (some ideas)
  • What do humans and machines do jointly? What does it mean, practically?
  • How to HITL in a SOC without breaking the humans or machines?
  • What is the effective mechanism for the human-to-AI feedback loop so that corrections actually improve future SOC performance?
  • Is “fully automated” detection engineering a realistic goal, or does the dependency on local, inconsistent environment context make it inherently a hybrid human-machine effort?
  • What do humans do before SOC (TI) and after SOC (IR)?
  • What is the first step to move from a legacy SOC to an agentic SOC?
  • Can we run legacy and agentic SOC structures in parallel during transition, or does this duplication create operational friction?
  • Is it easier to move from a modern non-AI SOC (aka “SOCless D&R”) to an AI SOC?

Looking Ahead

This blog post is just the first part of the series. My goal here is simply to collect the right questions we need to be asking, but I promise we will provide concrete answers in upcoming posts. This research is being undertaken together with my former colleague, Augusto Barros, now at Prophet Security

Related blogs:

Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

❌