Reading view

From Cloud to Chaos: Defining Shared Responsibility for AI Security

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:

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.
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.
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.

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.

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

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.
Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
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.

America250 Fourth of July Threat Assessment

Threat Intelligence Blog | Flashpoint

By: Flashpoint Intel Team

30 June 2026 at 18:20

Blogs

Blog

America250 Fourth of July Threat Assessment

In this post we break down the intersecting cyber risks, physical security strains, and operational challenges shaping the security landscape for the historic Semiquincentennial celebrations.

The Complete Guide to OSINT for Executive Protection

Download Now

As the United States prepares to mark its 250th anniversary this Fourth of July, the convergence of historic national celebrations, sprawling public events, and simultaneous high-profile sports tournaments is creating an exceptionally complex threat landscape. The multiyear national initiative “America250,” features over 1,200 synchronized grassroots gatherings under the “America’s Block Party” umbrella, with flagship events taking place in Washington DC, Philadelphia, Boston, New York, and Los Angeles.

Key Takeaways

While public sentiment surrounding America250 remains broadly positive, Flashpoint analysts have assessed the physical, cyber, and operational threat vectors that organizations, security teams, and municipalities must navigate during this high-visibility holiday weekend.

America250 Threats & Security Challenges:

Distributed Physical & Infrastructure Strain: Massive tourism influxes will collide with ongoing 2026 FIFA World Cup matches in Houston and Philadelphia on July 4, putting historic operational pressure on metropolitan transit grids and soft targets.
Elevated Iconicity and “City of Concern” Status: Although no specific, credible plots have been confirmed, the National Mall events in Washington, DC have received their first-ever National Special Security Event (NSSE) designation. Meanwhile, the National Counterterrorism Center (NCTC) has officially designated Philadelphia a “city of concern” due to the volume of synchronized events.
Ideological Protest Dynamics: Activist groups are organizing a significant anti-authoritarian march in Philadelphia. While expected to be peaceful, open-source chatter indicates a portion of attendees plan to exercise their license to carry firearms.
Disruption & Cyber Threat Vectors: Cyber threat groups, ransomware operators, and hacktivists are expected to attempt to exploit thin holiday IT staffing. Threat vectors range from mass public-transit ticketing fraud to high-consequence digital hoaxes involving rogue cellular infrastructure.

Physical Threat Vectors

Transportation and Infrastructure

Flashpoint assesses that “lone wolf” actors motivated by various ideological grievances, including those inspired by foreign terrorist organizations (FTOs), pose the most likely threat of disruptions to transportation infrastructure during America250 events. This threat is likely to apply to all major transport hubs during the event, including Washington DC, Philadelphia, New York City, and Boston. Attendees can expect to see an increased police and military presence near transit hubs at major events.

Event Threats

While no specific credible threats targeting America250 events have been identified, the July 4th events taking place on the National Mall in Washington DC, have been given a National Special Security Event designation, which is typically reserved for events deemed potential targets for terrorism or other criminal activity. This is the first time such a designation has been given to July 4th celebrations on the National Mall.

Memos released by the National Counterterrorism Center to security agencies also identified Philadelphia as a “city of concern” regarding potential targets for terror attacks due to the number and scale of events taking place on July 4th. Law enforcement officials have indicated that while no specific threats have been identified, increased security measures will be in place throughout the city.

Planned Protest

The Fayetteville Resistance Coalition, alongside Veterans Against Fascism, and the Women’s March is organizing an anti-authoritatian protest march in Philadelphia on July 4th—being the largest mobilization of military veterans in decades.

Flashpoint has identified chatter indicating that march attendees may be armed. However, Flashpoint has not identified any calls for violence at this protest and deem that actions will likely remain peaceful. Despite this, arrests may be possible if attendees gather in unauthorized areas or engage in civil disobedience.

Cyber Threat Vectors

Ransomware and Operational Technology (OT) Disruptions

Financially motivated threat actors frequently deploy ransomware during major US holiday weekends when corporate and municipal IT security staffing is historically thin.

Flashpoint analysts assess that attackers could target automated ticketing systems, regional rail signaling, and digital municipal transit grids. Disruption to public transit during the high-density travel window surrounding major events could induce logistical gridlock. Secondary targets include municipal water treatment facilities, local power grids, and emergency response (911) dispatch systems in primary host cities.

Hactivism

With hundreds of thousands of spectators gathering at prominent national landmarks, hacktivist groups seeking political leverage or global media visibility pose an elevated threat to public messaging infrastructure.

Compromising the digital billboards, stadium screens, or viewing decks used for America250 events presents an attractive vector for defacement. Adversaries may attempt to display political propaganda, anti-war messaging, or explicit content to captive, high-density crowds.

Event App Vulnerabilities and Data Harvesting

The decentralized nature of “America’s Block Party,” featuring over 1,200 grassroots events managed via localized apps, introduces software supply chain vulnerabilities.

Cybercriminals may target the ticketing infrastructure of high-profile, restricted-access events. Phishing campaigns, credential stuffing, or application programming interface (API) vulnerabilities within event-specific mobile applications could result in mass ticketing fraud, legitimate attendees being locked out, or crowd-control issues at venue gates.

Additionally, malicious actors frequently deploy spoofed public Wi-Fi networks around high-density tourist hubs to harvest sensitive personal data, financial credentials, and biometric profiles from unsuspecting attendees.

Protect People Using Flashpoint

To ensure attendee safety, safeguard operations, and protect public-facing brands, Flashpoint recommends implementing the following proactive measures:

Secure Public-Facing and Display Infrastructure: Implement strict access controls, multi-factor authentication (MFA), and offline fail-safes for all internet-connected digital signage, stadium screens, and public notification systems to prevent hacktivist defacements.
Audit Event Applications and Mobile Endpoints: Conduct rigorous vulnerability scans on event-specific APIs and ticket validation platforms. Advise personnel and contractors against posting photographs of official credentials, badges, or operational passes on public social media channels.
Establish Out-of-Band Incident Response Protocols: Prepare alternative communication channels and verified public-address messaging to immediately counter potential rogue emergency broadcasts, digital hoaxes, or localized telecom disruptions that could cause public panic.
Monitor High-Risk Overlap Zones: Cross-reference physical security deployment schedules in cities like Philadelphia where World Cup traffic, official America250 parades, and armed protest routes intersect near major transit networks.

Ensure your security team has full visibility into the cyber and physical threat vectors shaping this historic holiday weekend. Request a demo and see how Flashpoint equips organizations with the intelligence needed to detect, analyze, and mitigate emerging risks.

See Flashpoint in Action

Get a Demo

Contact Sales

The post America250 Fourth of July Threat Assessment appeared first on Flashpoint.