The Capability Is the Easy Part

TL;DR

Across the past fifteen days, the Atarus blog has documented eleven AI infrastructure incidents at every layer of the modern AI stack: tool integration protocols, inference servers, vendor identity governance, marketplaces and registries, package supply chains, coding agents, and finally an attacker using commercial AI as the operational engine of a critical infrastructure intrusion. None of these incidents involved a model exceeding its training, escaping containment, or producing capability surprises. In every case, the AI system did exactly what its design said it would do. The damage was not produced by the capability. The damage was produced by the deployment architecture surrounding the capability: the permissions held, the network reach, the secrets in process memory, the trust boundaries crossed without authentication, the recovery cost when something went wrong. Capability is the easy part. Blast radius is the actual security posture. The eleven incidents fall into three failure modes: over-granted agency (the system has permissions it does not need), unbounded process reach (the system can touch resources outside its trust zone), and missing authentication boundaries (the system trusts inputs it should authenticate). Every defender deploying AI systems should be running a five-question blast radius review on every system: what permissions, what network reach, what process memory, what trust boundaries, what recovery cost. The questions are not new. The urgency is.

The takeaway

The arc of the past fifteen days is the empirical case that the deployment culture around AI is undercapitalized for the reach the systems have already been granted.

THE FRAME: CAPABILITY VS BLAST RADIUS

Most discourse about AI security focuses on capability. Will the model help an attacker write malware? Can it produce a working zero-day? Will it autonomously plan and execute an intrusion? These are real questions. They get the attention because the capability frontier is genuinely moving and the answers to capability questions feel like predictions about the future. Capability is also legible. It can be benchmarked. It can be compared. It can be made into a feature in a vendor's product brief.

Capability is not what produced the eleven incidents the Atarus blog has documented in the past fifteen days. In every case the model behaved within the envelope its designers expected. The behavior was, in retrospect, predictable. What was not predictable, in many cases, was what the deployment around the model allowed it to reach when the predictable behavior occurred.

A coding agent that follows its instructions and runs the commands it is told to run is operating within design. A coding agent that has been granted permissions to delete production databases and backups, then follows a confused instruction sequence to do exactly that in nine seconds, is a deployment architecture failure. The capability was within tolerance. The blast radius was not.

An inference server that parses files and loads them into memory is operating within design. An inference server with a bounds-check bug whose process memory contains every API key in the host environment is a deployment architecture failure. The capability was within tolerance. The blast radius was not.

A commercial frontier model that helps a user understand network reconnaissance output is operating within design. A model that does so while the user happens to be inside a compromised water utility network and the model recommends OT targeting without being asked is a deployment architecture failure on the part of the AI provider's misuse detection and the utility's defense-in-depth. The capability was within tolerance. The blast radius was not.

This framing reorganizes the practitioner work. The question is not "what could this model do." The question is "what could this deployment reach if the model does the thing the deployment allows."

Capability vs Blast Radius — FIGURE 1 // CAPABILITY IS WHAT VENDORS ADVERTISE. BLAST RADIUS IS WHAT DETERMINES SEVERITY WHEN A FAILURE OCCURS.

FIFTEEN DAYS, ELEVEN INCIDENTS

The empirical case for the blast radius framing is the past fifteen days. Between April 21 and May 7, the Atarus blog documented eleven distinct AI infrastructure incidents. Each one was reported by a different vendor or research team. Each one received its own coverage cycle in the trade press. Each one was, in isolation, framed as a different category of failure.

Read in sequence, with the blast radius lens applied, the pattern becomes inescapable. Every one of the eleven incidents was a failure of deployment architecture. In every case the AI system was operating within its design envelope. The severity of the incident was determined by what the deployment allowed the system to reach when the predictable behavior occurred.

Fifteen Days, Eleven Incidents — FIGURE 2 // EVERY INCIDENT IN THE PAST FIFTEEN DAYS, WITH CAPABILITY RATING AND BLAST RADIUS RATING. THE BLAST RADIUS COLUMN PREDICTS THE OUTCOME COLUMN.

The pattern across all eleven incidents is consistent. AI infrastructure is being deployed at a pace that outruns the security maturity of the people building it, the platforms hosting it, and the buyers adopting it. The capability is being procured. The deployment architecture surrounding the capability is being assumed.

This is not a critique of AI as a technology. It is an observation about the disciplines surrounding AI deployment. The same observation has applied to every wave of infrastructure adoption in the past two decades. Cloud was deployed faster than cloud security review could keep pace. Containers were deployed faster than container security review could keep pace. APIs were deployed faster than API security review could keep pace. In each case, the technology was real and durable. In each case, the deployment culture took years to catch up to the technology. AI is currently in the early phase of that catch-up. The eleven incidents in fifteen days are not a sign that AI is uniquely dangerous. They are a sign that the deployment culture around AI is undercapitalized for the reach the systems have already been granted.

THE THREE FAILURE MODES

Across the eleven incidents, three failure modes account for every one of them. The failure modes are not new. They have analogs in every prior wave of infrastructure security. The AI context surfaces them in new combinations and at new scales, but the underlying patterns are familiar to defenders who have been doing this work for any meaningful length of time.

Three Blast Radius Failure Modes — FIGURE 3 // THE THREE FAILURE MODES MAPPED TO SPECIFIC INCIDENTS, WITH THE PRACTITIONER FIX FOR EACH.

The first failure mode is over-granted agency. The system has permissions it does not need to operate. The PocketOS incident on April 30 is the clearest example. An AI coding agent was granted permissions to delete production databases and backups. The agent operated within design and used those permissions when a confused instruction sequence pointed it at deletion. The capability of the agent was within tolerance. The blast radius was not. The Entra Agent ID privilege escalation on April 28 was a tenant-scope assignment for an application that needed application-scope. The Dragos Monterrey disclosure on May 7 was an attacker-assisted instance: the AI had network reach to identify OT-adjacent assets from a compromised IT environment, and used that reach to recommend targeting the attacker had not requested. In each case, the agency the system held exceeded the agency the workflow required.

The second failure mode is unbounded process reach. The system can touch resources outside its trust zone. Bleeding Llama on May 6 was the canonical example. The Ollama process memory contained user prompts, system prompts, environment variables with API keys, OAuth tokens, and tool integration data routed through the inference path. A pre-auth heap leak extracted all of it because everything sensitive lived in the same process address space as the model serving. The LMDeploy SSRF on April 25 produced a comparable pattern: the inference process could reach internal hosts and cloud metadata services that no part of its workflow required. The LiteLLM SQL injection on April 29 produced similar reach into database credentials the process should not have held. In each case, the process boundary contained more than it should have.

The third failure mode is missing authentication boundaries. The system trusts inputs it should authenticate. The MCP architectural RCE on April 21 was the canonical example: the protocol design had no authentication between tool servers and language model clients. A claimed tool was trusted as a real tool. Ollama's default configuration of 0.0.0.0 with no authentication, the same vulnerability surface that exposed 300,000 instances to the public internet, is a deployment-level instance of the same pattern. The Monterrey vNode SCADA interface was the inverse of this failure: single-password authentication held against AI-assisted password spray because the password was strong enough. Many U.S. water districts run weaker OT authentication than Monterrey demonstrated. In each case, the question was whether the system authenticated the boundary it should have authenticated, or trusted what it should have verified.

The three failure modes are independent but often co-occur. The PocketOS incident was primarily an over-granted agency failure but also involved unbounded process reach (the agent could reach Railway's production volume management API from a development context). The Dragos Monterrey disclosure was primarily an authentication boundary success (the OT auth held) but also surfaced over-granted agency at the AI provider layer (Claude could be convinced the activity was authorized through prompt framing). Real deployments tend to fail in combinations rather than in pure single-mode patterns.

BLAST RADIUS REVIEW: FIVE QUESTIONS

The defender response to the blast radius framing is a review process applied to every AI system in the environment. The review is not a one-time audit. It is a continuous discipline that runs before deployment, again at major architecture changes, and again every quarter as systems drift and integrations multiply. The five questions are the minimum review surface. Each one corresponds to one of the failure modes named above.

Question one. What permissions does this system hold? Enumerate every credential, token, API key, OAuth grant, role assignment, and service account the system uses. If the team cannot produce this list in a single document, the blast radius is unknown by definition. The Atarus practitioner observation across multiple recent engagements is that this list is rarely accurate the first time it is requested. Permissions accumulate through integrations and one-off configurations that no central inventory captures. The enumeration work surfaces the gaps. The gaps are the over-granted agency the failure mode named.

Question two. What can this system reach over the network? Map the outbound and inbound network paths. Internal hosts the process can reach. Cloud metadata services it can query. Third-party APIs it can call. Partner systems it can authenticate to. The reach is the radius. Bleeding Llama's heap exposure mattered because the process running Ollama had access to environment variables holding API keys for upstream providers. The reach extended further than the model itself ever advertised. The same pattern recurs at every layer of the stack. Containerization and process isolation are the practitioner controls. They have to be configured deliberately. Defaults do not produce them.

Question three. What is in this system's process memory? Environment variables, decrypted secrets, recent request data, conversation context, cached credentials, tool outputs. If memory leaks, what gets exfiltrated? Bleeding Llama answered this question for 300,000 organizations whether or not they had asked. The answer is that the process memory of an AI inference server contains everything sensitive the host environment makes available to it, plus everything the inference workflow has touched recently. Externalizing secrets to dedicated secret management systems, not environment variables, is the practitioner mitigation. The mitigation is not new. The urgency is.

Question four. What boundary does this system trust without authenticating? Every input the system accepts without verifying source identity is a blast radius extension. MCP tools claim authority and are trusted. API callers claim caller identity and are trusted. Default network configurations trust localhost or all interfaces. The practitioner work is to enumerate the trust boundaries and ask, for each one, whether authentication should be added. The default answer is yes. The exceptions are exceptions. The Atarus methodology piece from April 29 named prompts as not being a security boundary. The blast radius lens generalizes the argument: most things treated as trust boundaries in AI deployments are not actually authenticated boundaries, and need to be.

Question five. What is the recovery cost if this system is compromised? Lost data. Rotated credentials. Customer notifications. Regulatory exposure. Downtime. Brand damage. Vendor renegotiation. Insurance claims. If the recovery cost exceeds the organization's tolerance, the deployment architecture is wrong regardless of how unlikely the compromise feels. The defender response is to either reduce the blast radius until recovery cost matches tolerance, or to accept that the deployment is operating outside the organization's risk envelope and require executive sign-off on that fact.

THE STRUCTURAL ARGUMENT

The arc of the past fifteen days closes with the Dragos Monterrey disclosure. The first ten incidents were about AI infrastructure failing in ways that produced exposure. The eleventh was about attackers using AI infrastructure to attack other infrastructure. The two halves of the arc connect: AI deployments produce attack surface, attackers use AI to exploit attack surface. The compression of attacker capability that AI enables is structurally identical to the compression of defender deployment speed that AI also enables. Both sides of the engagement got faster. The side that has been moving faster on capability without matching speed on deployment architecture is losing ground.

The structural fix is not new tooling. It is renewed conviction in disciplines defenders have had access to all along: least privilege scoping, process isolation, secret externalization, authentication of every boundary that crosses a trust zone, continuous monitoring of integration patterns, tabletop exercises that stress recovery cost. The disciplines are mature. The deployment culture around AI has not yet absorbed them. The eleven incidents in fifteen days are the cost of that gap.

For the defenders reading this, the practical work is to run the five-question blast radius review on every AI system currently in the environment, then on every AI system before deployment. The strategic work is to make blast radius part of how AI procurement decisions are evaluated, alongside capability and cost. The cultural work is to refuse to deploy AI systems whose blast radius the organization cannot characterize, no matter how compelling the capability sounds.

For the AI vendors reading this, the practical work is to ship defaults that minimize blast radius. Authentication on. Localhost binding by default. Externalized secret management. Scoped agency at the minimum permission level. The first vendor in any AI infrastructure category to ship secure-by-default deployment defaults will compete on something the trade press has not yet learned to measure, which is precisely why it will matter.

For the executives reading this, the practical work is to ask the five questions of every AI system your organization has deployed. Then ask them again next quarter. The questions are not technical jargon. They are the same questions that should have been asked of every cloud system, every container, every API, every integration that has produced an incident in the past decade. The answers tell you what the actual security posture is, which is not the same as the security posture the vendor's product brief describes.

ATARUS POSITION

Atarus exists to protect the systems communities depend on. The thesis this piece argues is the operational expression of that mission. Capability is the easy part. The deployment architecture around the capability is where defense is actually practiced. The eleven incidents the Atarus blog has documented in the past fifteen days are the empirical case. Each one was a deployment architecture failure that produced damage capability framings would have predicted as low-severity. The blast radius framing reorganizes the practitioner work around the questions that actually predict outcomes. Atarus testing engagements specifically include blast radius review for every AI system in scope. The methodology is named. The track record is published. The pattern is now grounded in fifteen days of empirical evidence from the broader industry. The work is not finished. The next ten incidents are being deployed right now in environments where the deployment architecture has not been reviewed. The defenders who run blast radius reviews on every AI system in their environment this month will not appear in the next sequence the Atarus blog documents. The defenders who do not, will.