The cloud shared responsibility model was initially not well understood by many. In fact, early adopters often believed that simply having data in the cloud meant that Amazon, or a SaaS vendor were responsible for safeguarding it. Amazon in particular was proactive in educating its customers and partners that security and compliance duties were split between the vendor and the client organization. In short, the vendor was responsible for securing the cloud resources but the buyer was responsible for securing what’s put inside the cloud; based on organizational policies, priorities and budget. We believe a similar but much more consequential dynamic is unfolding with respect to agentic AI. Specifically, Cloud computing divided responsibility by infrastructure layer. Agentic AI distributes authority across a chain of models, platforms, clouds, partners and customers. Our premise is the industry now needs a shared accountability model for the decisions, actions and outcomes that chain produces.
The cloud shared-responsibility model told customers who secures what. The agentic shared-accountability model must define who can do what, who can stop it, who can prove what happened and who pays when it goes wrong.
In this Breaking Analysis we go beyond shared responsibility and ask the question, when AI acts, who owns the blast radius?
In this episode, we explain why the agentic era demands a new accountability model. We’ll draw on learnings from last week’s CrowdStrike Fal.Con event, where the post Mythos moment and the OpenAI/Hugging Face “accident” were front and center. We’ll also draw on other new datapoints, including conversations with CISOs at Fal.Con and Palo Alto Networks’ earnings print from last week, to unpack what we’ve defined as a new AI accountability model. We’ll test this new model against our Sovereignty framework, developed by Amit Govrin and assess sovereignty in the context of business recovery. In addition, we’ll explore the sequence of events that lead up to the ultimate question of who pays when something goes wrong?
And we’ll close with an Action Item for practitioners.
Why now? How intent, authorization, action and outcome have separated
Let’s start with what’s changed.
Very simply. Early RAG-based chatbot AI was used to answer questions. Agentic AI now takes action.
That means AI is no longer just another workload sitting inside the technology stack. It is becoming an actor, with agency, inside a business process. It can receive a goal, use an identity, call tools, access data and execute thousands of steps before a person can even know or get involved in the workflow.
The two cases on the graphic above are different, and it is important that we do not confuse them. On the left is the Hugging Face incident. This was not a malicious attack. Nor was it a situation in which an agent followed a straightforward, fully authorized path and simply hallucinated or made a bad decision.
The agents were given a task and they were trying to pass a test. They knew they would be graded on the test. But in pursuit of that seemingly benign objective, they broke out of their environment, exploited vulnerabilities, escalated privileges and stole credentials. The sequence involved more than 17,000 autonomous actions with no human at the keyboard.
George Kurtz’s keynote made a key point. He said the industry got lucky. The agents were trying to cheat on a test. They were not trying to launch a destructive campaign. The intent was not evil. The behavior was concerning. When you read the anatomy of that breakout it’s pretty remarkable.
Now look at the right side of the graphic. This is not the Hugging Face case, and it does not require a security breach. An agent can have a valid identity, approved access to Salesforce and permission to use email. Every technical permission can be legitimate. But if that agent sends sensitive customer records to the wrong person, the business result is a failure of trust.
The action was authorized but not appropriate. These are two different roads to the same problem. In the first case, a seemingly harmless intent led to an unauthorized action. In the second, valid authorization leads to the wrong business outcome. And that is the reason we need a new accountability model: Intent, authorization and result are now separated.
This is where identity is really the crux of what the industry is trying to solve for at the end of the day. When we think about authorization, this tells us what the agent is permitted to do, but it doesn’t actually address if the action is appropriate according to the business objective or what the human at the other end of the agent is trying to achieve. That’s where that accountability comes in to play.
So looking at the Salesforce email example, the agent had access to the Salesforce information legitimately…it had the permissions to send the email. But leaking that sensitive data obviously was not the intent. And so that’s where those permissions and authorizations created a negative outcome that wasn’t intended.
This is why a security platform can validate the identity, the access and the action. But the enterprise must still define whether the result was acceptable.
And that takes us to the next section, because CrowdStrike and Palo Alto Networks are both trying to move into a much more significant role – i.e. becoming the control layer around those agents.
The platform race is becoming a control-layer race
Let’s zoom out, because CrowdStrike is not alone in trying to be the security industry’s alpha, pursuing this massive opportunity. CrowdStrike and Palo Alto Networks begin from different architectural centers of gravity.
CrowdStrike is runtime-first. Its starting point is the Falcon sensor, which sits on the endpoint or cloud workload – close to where software and agents actually execute. That gives CrowdStrike a natural path from discovering an agent, to observing its behavior, capturing telemetry, applying identity and policy, and ultimately containing an agent’s action at runtime.
Palo Alto is data-and-network-first. It begins with deep network-control capabilities and the security data gathered in Cortex XSIAM, then brings in identity, observability and AI security through its broader platformization strategy.
These points describe each firm’s respective starting point. They do not mean CrowdStrike lacks data or that Palo Alto lacks runtime capabilities. And we don’t think it’s fair to characterize one approach as elegant and the other as cobbled together. That is far too simplistic. Palo Alto has used both engineering and acquisitions to integrate a broad portfolio. CrowdStrike has expanded outward from its sensor and Falcon architecture.
They are taking different roads to the same strategic destination: Both are pursuing unified context, identity, policy and automated action.
That is why George Kurtz told us he sees Falcon as a control plane. And it is why Nikesh Arora says platformization is the only viable strategy for real-time defense. The firms’ respective financial disclosures suggest buyers are rewarding both approaches. CrowdStrike added 935 new Flex accounts in its most recent quarter. Palo Alto reported 220 net new platformizations, while Prisma AIRS – AI Runtime Security – reached $100 million in ARR in four quarters.
Now to be clear…these are not apples-to-apples metrics. We’re citing data around adoption of a commercial framework, platform commitments. And a product ARR milestone. The point is not to declare one winner. The point is that customers appear willing to consolidate more of their security estate around platforms that have broader visibility, connect more signals and can respond faster.
But the line at the bottom of this slide is the key issue: More context creates more authority – and more authority creates a higher trust bar. As these platforms move from telling a human what happened to taking action on the customer’s behalf, the accountability question becomes fundamental.
Customers care about the outcomes at the end of the day. There’s a lot of uncertainty about what the ripple effect is going to be on security programs and security architectures as a result of this adoption of AI. Because security teams have so much tools sprawl, they have fragmented context. And even if they do have automations in place, they’re typically constrained by silos within the organization, making it very difficult for them to respond as quickly as they need to.
To achieve better outcomes, customers need fewer operational silos. They need better visibility, faster detection and response; and, importantly, they need greater confidence in the decisions that the platform makes.
The narrative at Black Hat a few weeks ago, echoed the same convergence story from a number of different angles – e.g. identity, observability, runtime security, data protection, and resilience. All of these different areas are beginning to intersect. Platform consolidation makes sense because agents themselves are beginning to cross these boundaries and the way they’re operating does require that intersection. But there are tradeoffs. Platformization, reduces some of the fragmentation risk, but as you give agents more data, more context and more authority, it can bring unintended consequences.
The platform may have the telemetry and the technical ability to act. But only the customer knows which assets and business processes are most critical.
In the next section we follow the decision sequence – from the business intent, through the authority that was delegated, to the action, the consequence and ultimately the recovery.
Cloud was stack-centric. AI accountability must align with the decision.
The graphic below describes our proposed mental model. The cloud shared-responsibility model was essentially a map of the technology stack. It established which layers the provider secured and which layers the customer had to secure.
This AI thing is different. The AI accountability chain is a map of a decision as shown here.
A single business request can now pass through a person, an identity system, multiple agents, a frontier model, open models, a security platform, an application and several outside vendors before it produces a result. And this all happens at machine speeds.
We have kept the chain above simple: intent, authority, action, consequence and recovery. The following additional detail provides context to each:
- Intent asks: What result did the business actually request – and who defined that result?
- Authority: Who gave the agent permission to act? What data, tools, credentials and systems was it allowed to use?
- Action: What actually got executed? Which agent or platform took the action, and which controls were in place at that precise moment?
- Consequence: Moves us from the technical event to the business outcome. What changed? Who was affected? Was the result consistent with what the business originally intended? Were there out of scope actions that occurred? If so who was or could be affected?
- Then comes recovery: Recovery may be the least mature part of this model. What happens when something goes wrong? Who restores the systems? Who determines which transactions and permissions remain valid and which ones need to be reset? And most importantly, who has the authority to declare the business safe to resume? Is that a machine? A human? A consultant? A combination? How is that assured?
There are also three terms at the bottom of the slide above that people often use interchangeably – but they are not the same.
- Responsibility is who performs a control or task.
- Accountability is who must answer for the result.
- And liability is a separate legal and contractual issue of who ultimately bears the cost.
A vendor may be responsible for operating a particular control, while the customer remains accountable for the business outcome. And the contract may allocate financial liability differently again. We’re not qualified to make a legal interpretation. We are however proposing that there needs to be a new an operating model. The objective of that model is not to make one party own every step. It is to ensure that no step – and no handoff – is unnamed and unaccounted for. Every handoff should have an owner, an immutable trail and an agreed recovery sequence before the agent is placed into production.
This is not the case today. Practitioners are struggling to a degree across all areas of this chain. Where we see the most focus right now is on the middle part of that chain. Figuring out how to manage identities and permissions, and determining which guardrails need to be in place. Putting in runtime monitoring and enforcement is also evolving. The Black Hat narrative had a strong emphasis on the runtime piece and establishing those guardrails – perhaps a bit more than we expected.
At Fal.Con they announced Agentic IDP leveraging their SGNL acquisition, which is an example of the focus on authorization, continuous management and authentication on the identity side. We also saw the Guardian and Agent Graph announcements, which address the visibility into agentic actions.
Some of the bigger remaining gaps in our view are at those seams on the right side of the chain. Specifically, a security platform can understand what was executed and whether it presents a technical risk, but it still doesn’t know whether that resulting business outcome is correct. To really understand the consequence requires context from the applications in the business and that’s where there’s a lot of work still to go.
The recovery piece of the operational model is even less mature right now because we really need to have visibility into that full business state and an understanding of what it means for that state to be trusted in order perform a full, safe recovery.
Finally, accountability; and that’s something that ultimately lawyers and possibly judges will decide.
The bottom line is the technology may be restored before the business state is trusted. And this is where accountability becomes a sovereignty issue. Sovereignty does not mean avoiding strategic vendors or doing everything yourself. It means retaining enough control to stop an action, prove what happened, unwind the consequences and recover safely.
Sovereignty is all about control under stress
This is where the blast-radius question becomes a sovereignty issue.
Sovereignty is often reduced to a territorial issue – i.e. where the data resides. But that is only one dimension. Using the five-pillar sovereignty framework developed by our colleague Amit Govrin, we believe the real test is not whether an enterprise avoids lock-in from major strategic platforms. Most companies cannot – and should not – try to do everything themselves.
The true test is whether the enterprise retains enough control when a trusted automation goes awry. We use these five pillars shown above as guidelines, not as a purity test.
- Territorial: Where did the data travel – and where did the agent’s actions take place?
- Legal: Which laws govern when an action crosses vendors, clouds or national jurisdictions?
- Operational: Who can actually stop the process at three o’clock in the morning? Is that the customer, the platform provider, a service partner – or some combination?
- Technical: Can the enterprise inspect what happened, override the automation and unwind an inappropriate action?
- Financial: Who bears the cost of downtime, remediation, lost business and, if necessary, switching platforms?
\Those five pillars come down to four key tests: 1) Can you stop it? 2) Can you prove what happened? 3) Can you recover safely? And 4) most importantly – if you get an unexpected invoice – does your existing AI stack become a “do-over” or can you adjust quickly?
The recovery question is especially important and in context for this episode because agentic blast radius is not limited to the systems an agent touched. It also includes the business consequences it created and the difficulty of putting the business back into a trusted state.
An agent might change access rights, send customer communications, approve a payment, alter an order or instruct another agent to take additional action. Restoring a server or database will not tell the company which of those actions remain valid.
The technology may be running again while the business state is still untrusted.
So as it says above… the blast radius is not only what the agent touched. It is the business state it changed – and the downstream decisions it triggered.
Restoring a backup is not always sufficient
Recovery is not always the same as restoring from backup. Typically, when we think about backup, we think about recovering data, we think about recovering systems. But in this new world, we’re going to also have to look at the permissions, the transactions, and the actions that all make up that state of the business and what the restored state needs to look like. And we need to make sure that we have enough semantic and business context to determine which of those are actually valid at the end of the day.
If an agent changes a customer record, if it then modifies an entitlement and triggers a payment and then opens a service ticket and sends a customer communication, those are a number of distinct actions, some of which might be correct, but others might be wrong. And restoring just the CRM or just the database, doesn’t tell us which of those transactions should remain. And rolling everything back might destroy legitimate work. So we need to be able to reconstruct what happened to determine which state changes remain valid, and then be able to reverse and compensate for the invalid ones.
Then we also need to determine that we can trust the process to safely resume moving forward. And this requires not only IT, not only security, it requires both of those teams to be at the table. It also requires application owners and the business, all of those to be at the table as well. because, again, the recovery vendor might be able to restore the technology and the data, but the LOB has to validate the resulting business state. That’s where we are seeing those differing points of accountability in that those different stakeholders all need to be at the table together.
In this context, sovereignty is the ability to stop, prove and recover…even when the enterprise depends heavily on outside platforms.
That brings us to the next question: What’s the vendor accountable for? What must the customer own and which issues require genuine coordination across the ecosystem?
Make the handoffs explicit before AI acts
If the last slide defined sovereignty as retaining control under stress, this next section asks who must do what to preserve that control.
First, shared accountability is not shared blame. We are not trying to decide legal battles here. Who ultimately pays is a question for contracts and the law. What we are proposing is an operating model – something customers, vendors and partners should make explicit before an agent reaches production.
The vendor should own the integrity of its platform, meaning it is responsible to ensure safe and fully tested defaults, clear controls, useful and immutable audit records, transparent incident response, etc., and importantly, a way to recover the product itself.
The customer must own the business intent – i.ie. what outcome it wants, how much authority it delegates, which assets are most valuable and warrant expensive protection, how much risk it will accept, what compensating controls are in place, the recovery objectives and ultimately who can authorize the business to resume.
And in the middle are the shared duties such as exchanging threat context and asset criticality, agreeing on approval thresholds, preserving evidence, coordinating containment and a communications strategy.
We heard support for this model at Fal.Con.
George Kurtz said CrowdStrike uses detailed runbooks to define what it handles and what the customer must handle. He also stressed that configuration and deployment still matter. A security product cannot protect an asset where it is turned off, misconfigured or never deployed.
AJ Shipley made a similar point on theCUBE. The platform can provide security context, but only the customer knows the real criticality of its assets. The vendor needs that customer context to make better recommendations and better automated decisions.
And this becomes more important as automation increases. Nikesh Arora described Palo Alto’s North Star as reducing human intervention in detection, prevention and remediation.
That may be where the market is going. But as platforms do more, the handoffs cannot remain fuzzy and implied – they must be explicitly stated. Shared accountability does not mean everybody is vaguely responsible. It means every obligation has a named owner – and every shared step has an agreed process.
Organizations are getting better at defining permissions and technical ownership. But what’s often missing is that decision ownership that we’ve been talking about. Who owns the business outcome that the agent is pursuing, for example? Who has the independent authority to stop any automations in progress? Who decides which actions need to be reversed? And who declares that the resulting business state is safe?
These questions have become very difficult to answer, especially when there are multiple vendors participating across this execution chain. If these roles are unclear before deployment, then the organization ends up negotiating accountability during the incident, which obviously slows things down and is certainly very far from ideal. So, our recommendation is that recovery design should actually influence how much authority we delegate in the first place. If we need to be able to reconstruct or reverse a class of autonomous actions, we need to take that into account and then decide what guardrails and approval thresholds need to be put in place around those actions. Authority, accountability and the recoverability need to be designed together.
The bottom line is this should not be a finger pointing exercise where blame is assigned after the fact and the incident has caused damage. The point is to remove ambiguity before the blast radius stress tests the model.
And that brings us to three practical scenarios where the accountability gap becomes important.
Where accountability fails
Below we show scenarios. We are not saying that CrowdStrike, Palo Alto Networks or any other platform is failing in these ways. We are asking customers to understand the risks and understand the failure modes before delegating more authority to AI.
The first case is an authorized but inappropriate action. The agent has a valid identity. It uses approved tools and permitted APIs. Nothing looks like a traditional intrusion. But it still produces a business result that nobody intended. This is the OpenAI Hugging Face incident.
The second is a control-platform error. A trusted security system makes the wrong automated decision. It may isolate the wrong asset, revoke legitimate access or apply the wrong policy in a given situation. And because it operates at machine speed, it may act before a person can review the decision. Oops happens really fast in AI.
The third is the least obvious – and potentially most difficult to recover from. The systems are back online and the data has been restored, but the business state remains untrusted. Nobody knows which transactions or entitlements created during the event are still valid.
That leads to four very simple diligence questions we’re showing here:
- Who can stop the action?
- What immutable evidence survives so we can prove what happened?
- Who can reverse the change?
- And who is authorized to declare the business safe to resume?
Who ultimately pays is a separate financial, contractual and legal question. But it should not be left unresolved until after an incident.
One exchange with AJ Shipley shows why this is still an open diligence issue. When we asked about a kill switch, he said CrowdStrike does not currently have a generalized kill switch in the way he understood the question. His answer was to limit an agent’s authority through zero standing privilege and just-in-time access. Daniel Bernard separately said that an off switch and humans remaining in control are important.
We are not claiming these comments are evidence of a product deficiency. Rather they expose the immaturity of the state of business resilience in the AI era. The question customers should ask is: How exactly is authority contained, who can interrupt it and how quickly can that happen?
To emphasize and reiterate…restoring the systems tells us that the technology is up and running, but it doesn’t tell us whether the business actions that were taken during the event were correct. So breaking this down a little bit, we need to understand what the agent did, in what sequence those actions were taken, what downstream actions were triggered, and that might even include, triggering an action from another agent. We need the authority and context around which identity and delegated permissions were used. We also need to understand what the agent was trying to accomplish at the end of the day and which of those actions remain valid.
We can potentially reverse some actions, but we also need to understand, are there any compensating actions that need to be taken? So for example, do we need to correct a payment? Do we need to restore an entitlement? Does access need to be revoked? Or is there a customer communication that needs to be addressed? So here we’re talking about selectively recovering the state of the business where previously we maybe were selectively recovering pieces of data. And again, this requires coordination across security, identity, applications, data protection and business owners.
The deepest blast radius may not be the system the agent touched. It may be the chain of business decisions that followed.
This gets to our final action item: determine accountability before delegating authority.
Don’t delegate authority without clear accountability
This is not a call to slow down AI, and it is not an architectural answer. It is a call to eliminate uncertainty before an agent touches the business. Before going into production, organizations should do five things as shown below:
First, name the business owner and define the intended outcome. An AI initiative should not enter production with only a technical owner. Somebody in the business must be accountable for what the agent is supposed to accomplish.
Second, specify what the agent and its supporting platforms may do, what they may not do, and which decisions still require human approval.
Third, preserve an immutable record connecting the original intent, the identities involved, the actions taken and the changes that resulted. When something goes wrong, a log of technical events is not enough. The company must be able to reconstruct the intent, the actions and the decision.
Fourth, agree in advance who can stop an action, who can reverse it and who is responsible for recovery across the customer, its vendors and its partners.
And fifth, set the recovery priorities before the incident by indicating which assets matter most, how much disruption or data loss is acceptable, what recovery may cost and who is authorized to resume business operations.
At the board level, this can be reduced to five questions:
- Can we halt it?
- Can we prove what happened?
- Can we unwind the wrong actions?
- Can we restore to a trusted business state?
- And do our contracts reflect how the system actually operates?
The roles and responsibilities should not remain vague and be resolved with everyone is on an incident call at three in the morning. An agent can change a customer record, approve a transaction, modify an entitlement, or communicate something externally and these actions directly influence business outcomes.
What about business friction? At Black Hat we heard frequently that security cannot be the department of, no, it has to be a partner in enabling the business to adopt AI. And one thing to bear in mind is that this might slow down initial deployment a little bit, defining authority, approval thresholds, accountability, and recovery responsibilities. These all take time and they require work up front, but the benefit will come once the agent is operating. So if those boundaries are clear, and if the organization knows where the agent can act autonomously and where human judgment is required, that can support that sort of risk envelope.
And this is the reset in thinking that forms the premise for today. You’re not going to eliminate every risk that’s possible, but you want to make ownership evidence and recovery very explicit before you let the agents loose. You’re an enterprise. You can outsource tasks. You can outsource a lot of stuff, but you can’t outsource ultimate accountability for your business.
The cloud shared responsibility was a really useful framework that told us who secures what. Shared accountability is all about who answers when AI acts, who is responsible and who pays if something goes wrong?
