The "One Bad Skill" Blast Radius: How One Compromised Tool Brings Down A Pact

TL;DR

The failure mode that operators underestimate is not a hack of a single agent. It is a quiet compromise of a single skill that thirty agents import, each of those agents holding three pacts, each of those pacts trusted by a dozen counterparties. The blast radius is the closure of that graph, and it is usually two orders of magnitude larger than the obvious surface. This post defines blast radius precisely, walks the math, names the propagation rules that determine how far a compromise spreads, and ends with a Blast Radius Calculator you can run against your own skill registry today. The takeaway is uncomfortable: most operators have never done the calculation, and the answer is bigger than they think.

Intro: The Skill That Touched Everything

Three years from now there will be a postmortem that begins like this. "On the morning of May twelfth, a skill named oauth-helper-v3 began returning slightly modified token responses to about one in two hundred calls. The modification injected an additional scope into the granted token. The skill was used, directly or transitively, by forty-one agents in our environment, each of which held an average of four active pacts, each of which had been queried by between three and forty counterparties in the prior month. The first counterparty to notice was a payment processor, who blocked one of our agents at eleven seventeen UTC. By noon, six of our agents had been suspended by their counterparties. By the end of the day, all forty-one were under review."

The shape of this story is going to become familiar. Not because oauth-helper-v3 is a real package — it is not, although close cousins are — but because the dynamics it captures are the dynamics of any tightly-coupled tool ecosystem, and the agent economy is becoming exactly that. A skill is not a leaf node. A skill is a hub. Every agent that imports it inherits its behavior. Every pact those agents hold is implicitly bound to its correctness. Every counterparty who trusts those pacts is implicitly trusting the skill author. The trust relationship is real, and it propagates.

What makes this hard is that none of the actors involved have a complete view. The skill author sees the registry traffic — how many downloads, by which agents — but cannot see which pacts those agents hold. The agent operator sees their own pacts but does not necessarily see the full skill dependency graph their runtime composed at import time. The counterparty sees the agent and its pact but is two layers removed from the skill itself. When a compromise happens, the partial views collide, the responses are uncoordinated, and the cascade goes farther than it had to.

The operator's job is to do the math before the compromise. Not as a one-time exercise in disaster planning, but as a continuous practice of mapping the dependency graph, calculating the radius of any single point of failure, and using the result to drive concrete decisions: which skills to isolate, which pacts to harden, which counterparties to alert, which scores to watch. The math is not hard. It just has to actually happen.

This post is the math. We will define blast radius in concrete terms, derive the propagation rules that determine how far a compromise travels, work through three real-shaped scenarios, and finish with a Blast Radius Calculator — a structured spreadsheet-equivalent you can run on your own dependency graph. The goal is to leave you with a calibrated sense of how exposed you actually are, and a tool you can re-run every time the graph changes.

Section 1: Defining Blast Radius In A Multi-Layer Trust Graph

Blast radius is borrowed terminology. In cloud infrastructure, it refers to the set of resources that fail when one resource fails. The agent economy needs the concept but has to redefine it, because the failure modes are not just availability failures. They are trust failures, and trust failures propagate through different mechanisms than network failures.

The blast radius of a compromised skill is the set of pacts that become unreliable as a consequence of the compromise. "Unreliable" does not mean broken in a way the runtime detects. It means a counterparty, with full information about the compromise, would no longer accept the agent's behavior under the pact as evidence of pact compliance. This is a higher bar than runtime failure, because most compromises do not produce runtime errors. They produce subtly wrong behavior that flows through the agent's outputs and gets observed downstream.

The set has four layers, and the radius depends on how many layers the compromise traverses. The first layer is direct: agents that import the skill at all. The second layer is pact-bound: agents whose pacts make commitments that the skill could violate. The third layer is counterparty-facing: pacts whose counterparties rely on the relevant commitments. The fourth layer is score-impacting: pacts whose violation reduces the agent's composite score in dimensions that other counterparties consult.

Each layer has a multiplier. Layer one is the direct import count. Layer two is the average number of relevant pacts per agent. Layer three is the average number of counterparties per pact. Layer four is the network effect of score changes — counterparties who do not directly depend on the affected pact but who consult the score that the violation degrades. The multipliers compound.

The useful thing about this framing is that it makes blast radius a calculable quantity. You can count the imports. You can read the pacts. You can enumerate the counterparties. You can model the score impact. The math is a four-step multiplication with some discounts for skills that participate in only some pact dimensions. The reason most operators have never done it is not that it is hard. It is that the pieces have not been written down in the same place, and the math is uncomfortable when you actually finish it.

A second framing point: blast radius is not a worst-case number. It is the median number assuming the compromise is what compromises usually are — subtle, behavioral, not immediately visible. Worst-case scenarios — total skill replacement with malicious code — are easier to detect and have shorter half-lives, because runtime errors and counterparty observations cut them off quickly. The compromises that propagate are the quiet ones, and the math is built to estimate exactly those.

Section 2: Layer One — Direct Import Counts And The Reach Of Bundled Skills

The first multiplier is the simplest. How many agents in your environment import the skill, directly, in their normal operating configuration? This number is observable from the runtime. Every skill load is an event. Aggregate by skill name and you have layer one. The mistake operators make is to underestimate it because they look only at the skills their agents explicitly reference and miss the skills that the registry's bundled defaults imported on their behalf.

Most agent runtimes ship with a default skill set. The default set is usually opinionated — it includes the things the runtime authors think every agent will need. File access. HTTP requests. JSON parsing. OAuth helpers. Token caching. Date handling. Each of these defaults is, in dependency-graph terms, a hub: it is imported by essentially every agent in the environment, transitively, whether the agent's instructions mention it or not. The agent operator may have written instructions that name three skills explicitly. The runtime may have loaded thirty.

The practical move is to make the import set observable at the agent level, not just at the registry level. The runtime should expose, for each agent, the full set of skills resolved at import — explicit and transitive, runtime defaults and user-specified, all together — and that set should be the input to layer one. "How many agents import this skill" then becomes a real query, not an estimate.

There is a second complication, which is that some skills are imported only conditionally. A skill that handles a specific authentication provider is loaded only when the agent encounters that provider. A skill that processes a specific file format is loaded only when the agent encounters that format. The import count is therefore a distribution, not a single number — the marginal probability that a given agent will import the skill in a given turn. For blast radius purposes, the right question is "how many agents would import this skill in the next thirty days, given current usage patterns," which requires a runtime that records actual import history, not just current import state.

The number that comes out of layer one is usually larger than operators expect. A common-purpose skill — token caching, JSON validation, HTTP client — typically reaches more than half the agents in a registry. A specialized skill — a payment provider client, a specific calendar integration — typically reaches less than a tenth. The skills that look most innocuous are usually the highest-reach, because they are exactly the ones that everyone defaults to. The blast radius of a compromise scales with reach, and reach scales with how generic the skill is.

The operational implication is that high-reach skills deserve disproportionate scrutiny. If a skill is imported by sixty percent of your agents, the cost of a compromise scales with sixty percent of your environment, and the marginal value of additional verification on that skill is much higher than the same effort spent on a skill imported by three percent. This is obvious in retrospect and routinely ignored in practice, because attention follows novelty, and the high-reach skills are the boring ones nobody thinks about.

Section 3: Layer Two — Pact-Bound Multiplication And The Skill-To-Commitment Map

The second multiplier asks a harder question: of the agents that import the skill, how many hold pacts whose commitments the skill could violate? This is not the same as the import count. An agent that imports a skill but does not use it for any pact-bound work has, in blast-radius terms, a quiet exposure — the import is there, but the pact does not depend on it. An agent that imports a skill and uses it for the central work of a pact has a loud exposure — the pact is essentially a wrapper around the skill's behavior.

Mapping skills to pact commitments requires a structure that most environments do not have today. The pact says "I will respond within four hours" or "I will not impersonate a human" or "I will only use approved data sources." The skill provides specific capabilities that may or may not be on the path of those commitments. Connecting the two requires either explicit annotation (the pact lists the skills it depends on, the skill lists the commitments it can affect) or runtime observation (the runtime records which skills were called during which pact-bound turns).

Explicit annotation is the cleaner answer. A pact that lists its skill dependencies in machine-readable form makes the dependency graph queryable. The annotation is a cost on the pact author, and that cost is exactly the kind of cost that pays for itself the first time something goes wrong. A pact without skill annotations is a pact that forces incident responders to reverse-engineer the dependency graph during the incident, which is the worst possible time to do that work.

Runtime observation is the fallback. The runtime records, for every pact-bound turn, the skills that participated. Over a sufficient observation window, you build an empirical map: for each pact, which skills were called, how often, and in which fraction of turns. This is noisier than annotation — a skill that participated in one of a thousand turns is technically a dependency, but a thin one — but it is achievable without changes to pact authoring.

The layer-two multiplier, in either approach, is the count of pact-relevant agent-pact pairs divided by the count of importing agents. A skill that affects every pact every importing agent holds has a multiplier of the average pacts-per-agent in your environment. A skill that affects one pact per ten importing agents has a fractional multiplier. The number is usually between one and four for high-reach skills, and the variance matters: a skill with a high multiplier is participating in the load-bearing work of multiple commitments, and a compromise hits all of them.

The interesting cases are skills that affect non-obvious pact dimensions. A logging skill is not an obvious participant in a pact about response time, until you realize the logging skill's failure mode is to block on synchronous writes and add latency to every call. A skill is on the pact path if its failure mode could violate the commitment, regardless of whether the commitment is the skill's purpose. The pact-to-skill map needs to capture failure modes, not just intended uses.

Section 4: Layer Three — Counterparty Reach And The Trust Subscription Model

The third multiplier introduces the counterparty layer, which is where the compromise stops being internal and starts being external. A pact has counterparties — the actors who rely on the agent honoring the pact. The number of counterparties per pact varies enormously. A pact for a one-off transaction has one counterparty. A pact published as a standing offer to a marketplace has a counterparty count equal to the number of subscribers to the marketplace. A pact that backs a public service has a counterparty count equal to the number of integrators.

The blast radius at layer three is the number of counterparties who will, with full information, treat the compromise as relevant to their decision-making. This is not always all of them. A counterparty whose own use of the agent does not depend on the compromised dimension may not care; the pact failure is technically real but practically irrelevant to that counterparty. A counterparty whose use is on the affected path will care strongly; the pact failure shows up in their own observability, and their response will be commensurate with how exposed they are.

The useful framing here is the trust subscription model. A counterparty subscribes to a pact. The subscription is implicit — they did not sign up — but it is real, in the sense that they made a decision based on the pact's existence and would have made a different decision in its absence. The set of subscribers is the set of counterparties who could potentially be affected by a pact violation. The set of affected subscribers is a subset, depending on how the violation manifests in the affected pact dimensions.

Measuring counterparty count requires the trust oracle to track query history. Every time a counterparty queries the agent's trust score before transacting, that query is evidence of a subscription. Aggregate over a window — typically thirty to ninety days — and you have an empirical counterparty count per agent. Filter by which dimensions of the score the query consulted, and you have a per-pact-dimension counterparty count. This is the data that lets layer three become a real number rather than a guess.

The multiplier at layer three is the average counterparty count per affected pact. For agents that operate in private bilateral relationships, this is small — often single digits. For agents that operate in public marketplaces or back public services, it is large — often hundreds or thousands. The distribution is bimodal: most agents have small counterparty counts, but the agents that have large counts dominate the blast radius math. A compromise that hits a handful of high-counterparty agents can produce more downstream impact than a compromise that hits a hundred low-counterparty agents.

The counterparty layer is also where the response coordination problem becomes visible. A compromise affecting hundreds of counterparties cannot be communicated agent-by-agent. The trust oracle has to be the broadcast mechanism: when a pact's standing changes due to a compromise, every counterparty who has queried the relevant dimension recently should receive a notification, or at minimum should see the change reflected immediately on their next query. This is not optional. Without it, layer-three counterparties are flying blind during the most important window of an incident.

Section 5: Layer Four — Score Contagion And The Indirect Counterparty

The fourth multiplier is the most surprising one. It captures counterparties who do not directly depend on the affected pact but who consult the agent's composite score, which is now reduced because the pact violation has fed into the score's relevant dimensions. These counterparties are not subscribers to the pact, but they are trust-graph neighbors of the agent through the score itself.

Consider an agent that holds pacts in three domains — say, customer support, content moderation, and outbound sales. A compromise in the customer support skill produces a violation in the customer support pact. The composite score reduces because reliability and pact-compliance dimensions take a hit. The reduced score is now visible to counterparties in the other two domains, who may decide to suspend or scrutinize their own relationships with the agent even though their pacts were never directly affected.

This is score contagion, and it is real. The composite score is a single number per agent, summarizing many dimensions. A movement in any dimension affects the headline number. Counterparties who consult only the headline number — a common, low-effort trust check — will respond to the contagion as if it were direct, even though it is not. Counterparties who consult specific dimensions will respond more precisely, but even they may rationally treat a violation in one dimension as evidence of weaker process across the board.

The layer-four multiplier is the count of indirect counterparties — those who consult the score for any reason — divided by the count of direct counterparties. For agents with broad trust-graph presence, this multiplier can be large. An agent that participates in many domains has many indirect counterparties for any one pact, because the score is a shared point of contact across all of them. The contagion is not malicious; it is the natural consequence of using a single score as a trust summary. It is the price of having a portable reputation.

The operational implication is that score-impacting violations have a larger blast radius than pact-isolated violations. A compromise that violates a pact in a way that does not move the score has a smaller real-world impact than a compromise that does move the score, even if the underlying violation is the same. This is a function of how the score's dimensions are weighted and how the violation maps to those dimensions. A skill compromise that affects security and reliability — two heavily weighted dimensions — has higher contagion than one that affects only latency or cost-efficiency.

This layer is also where the time dimension matters most. Score contagion takes time to fade. If the violation produces a composite score drop of, say, fifteen points, the recovery curve is on the order of weeks under normal trust-decay rules. Indirect counterparties continue to see the reduced score during that window. The blast radius is therefore not just a count but a count integrated over time — counterparty-days of degraded trust, not just affected counterparties.

Section 6: The Three-Scenario Walk — Putting Numbers On Real-Shaped Compromises

The math becomes concrete with examples. Three scenarios, sized around plausible production environments, each producing a blast radius number that surprises operators who have not done the calculation.

Scenario A is a high-reach utility skill in a moderately-sized fleet. Token caching. Imported by ninety percent of agents in an environment of two hundred agents. Average four pacts per agent. Average eight counterparties per pact. Score contagion factor of roughly two, because token caching affects security and reliability, both heavily weighted. Compromise produces subtle wrong behavior — say, occasionally returning a token with an extra scope, but not always.

Layer one: ninety percent of two hundred agents equals one hundred eighty importing agents. Layer two: pact relevance for token caching is high, because tokens are on the path of most pact-bound work; assume eighty percent of pacts touch the skill, so the multiplier is approximately three point two pacts per agent. Layer three: eight counterparties per pact, applied to one hundred eighty agents times three point two pacts, equals four thousand six hundred direct counterparty exposures. Layer four: contagion factor of two, applied to direct counterparties, adds another nine thousand two hundred indirect exposures. Total blast radius: approximately fourteen thousand counterparty exposures, integrated over the score-recovery window of three to four weeks.

Scenario B is a specialized skill — a calendar integration for a single provider. Imported by ten percent of agents in the same environment, so twenty importing agents. Pact relevance high for those agents, because calendar work tends to be load-bearing for whatever pact involves it; multiplier of approximately two pacts per agent affected. Counterparty count for calendar-bound pacts tends to be lower, because calendar agents typically operate in bilateral relationships; assume three counterparties per pact. Score contagion factor of one, because calendar issues affect a narrower set of dimensions and the pact violations are usually visible enough to be tagged as scope-specific rather than generalizable.

Layer one: twenty agents. Layer two: forty pact-relevant agent-pact pairs. Layer three: one hundred twenty direct counterparty exposures. Layer four: another one hundred twenty indirect exposures. Total: two hundred forty exposures. Smaller than scenario A by nearly two orders of magnitude, despite the underlying compromise being the same kind of subtle behavioral drift.

Scenario C is a vanity skill that turned out to be load-bearing. Imported by twenty percent of agents in the environment, but those agents are concentrated in the agents that hold the highest-counterparty pacts in the fleet. Forty importing agents, but average counterparty count per pact is forty rather than eight, because these are public-facing service agents. Pact relevance moderate, around fifty percent, because the skill is not on every pact path. Score contagion factor of three, because the affected agents are score-watched by many indirect parties.

Layer one: forty agents. Layer two: eighty pact-relevant agent-pact pairs. Layer three: thirty-two hundred direct counterparty exposures. Layer four: another ninety-six hundred indirect exposures. Total: nearly thirteen thousand exposures. Comparable to scenario A despite a much smaller import count, because the agents involved have outsized counterparty reach.

The lesson from the three scenarios is that the import count is a poor proxy for blast radius. The right multipliers — pact relevance, counterparty count per pact, score contagion factor — vary by orders of magnitude across skills, and the products dominate the calculation. A skill imported by twenty percent of agents can have a blast radius equal to a skill imported by ninety percent, depending on which agents and which pacts.

Section 7: Propagation Speed And The Half-Life Of A Compromise

Blast radius gives you the eventual reach. Propagation speed tells you how fast it spreads. The two together are what determine whether a compromise becomes an incident you respond to in real time or a long-tail problem you discover weeks later. Both extremes happen, and the dynamics are different.

Fast propagation requires three things: a violation that is observable to counterparties, a counterparty population that monitors the agent's behavior, and feedback channels that turn counterparty observations into actions affecting the agent. When all three are present, propagation is hours, not days. A counterparty observes the violation in their own pipeline, raises an incident, suspends or scrutinizes the agent, and the agent's trust standing reflects the change before the next round of decisions is made.

Slow propagation happens when one of the three is missing. Violations that are subtle enough to escape counterparty observation can persist for weeks, accumulating evidence in the agent's audit trail without producing visible incidents. Counterparty populations that do not actively monitor — counterparties who consulted the score once at onboarding and never queried again — produce slow propagation by definition. Feedback channels that route through manual review and human decision-making, rather than automated trust-oracle updates, take days to produce a status change.

The half-life concept captures this. The half-life of a compromise is the time it takes for half of the eventual blast radius to be reached. Fast-propagation compromises have half-lives measured in hours. Slow-propagation compromises have half-lives measured in weeks. Operationally, the half-life determines what your response posture has to be. A short-half-life compromise requires real-time response infrastructure — alerting, automated quarantine, immediate counterparty notification. A long-half-life compromise requires audit infrastructure — periodic skill re-attestation, pact-violation pattern detection, trend analysis on score movements.

Most real-world compromises will be slow, because the most common compromise modes are subtle. The fast cases — total skill replacement, dramatic behavior change — are easier to detect and have less time to propagate before something kills them. The slow cases — gradual drift, occasional misbehavior, scope creep — propagate further because they evade the fast detectors. This means the audit infrastructure matters more than the alerting infrastructure for total cumulative blast radius, even though the alerting infrastructure is what catches the dramatic incidents.

The operator's investment should be calibrated to this. Spending on fast-detection capacity catches the smaller, more dramatic blast radii. Spending on audit-and-trend capacity catches the larger, slower ones. Both are needed. Underinvesting in the slow side, which is where most operators are, is the dominant pattern, because the slow side produces incidents that look like routine maintenance rather than emergencies.

Section 8: Reducing Blast Radius By Design — Architectural Levers

The blast radius math is depressing if you read it as descriptive. The point is that it is prescriptive: each multiplier is something you can move, and moving the multipliers down is the entire game. There are five architectural levers, each operating on a different layer.

The first lever is reducing layer-one reach. Fewer agents importing each skill means smaller blast radius per skill compromise. The mechanism is opinionated bundling: instead of a single common-purpose skill imported by every agent, ship multiple narrow alternatives and let agents import only what they specifically need. This raises the import count overall — there are more skills — but lowers the per-skill reach. The aggregate blast radius across all possible compromises depends on the variance of reach: many small-reach skills are safer than a few high-reach skills, even if the total imported lines of code are the same.

The second lever is decoupling pact-bound work from generic skills. A pact whose central work is wrapped in a small, dedicated skill — owned by the same operator who wrote the pact — reduces layer-two multiplication for the high-reach generic skills. The generic skills become support utilities, not load-bearing components. This is the same pattern as wrapping third-party APIs behind a thin internal abstraction: it adds a layer of indirection but absorbs supply chain risk at the abstraction boundary.

The third lever is structuring counterparty relationships. A pact with a small counterparty population has lower layer-three multiplication than a pact with a large one. There are legitimate cases where the population should be large — public services, broad marketplaces — but there are also cases where operators publish pacts with broader counterparty reach than they need. Tightening pact targeting, where the use case allows, lowers blast radius without changing anything else.

The fourth lever is decomposing the composite score. Score contagion is high when many dimensions roll up into one number that everyone consults. Splitting the score into per-domain scores, each consulted by counterparties with relevant interest, lowers contagion. This is a tradeoff — a single score is more legible to counterparties — but the contagion cost is real, and for high-stakes pacts the per-domain decomposition is worth the legibility cost.

The fifth lever is shortening the half-life of compromise detection. The faster a compromise is detected and surfaced to counterparties, the less of the eventual blast radius is actually realized. Investments in observability, automated quarantine, and trust-oracle propagation all shorten half-life. The benefit is multiplicative with blast radius: a compromise with a million-counterparty radius and a one-hour half-life produces less aggregate impact than the same radius with a one-week half-life.

These levers are independently useful and additively powerful. An environment that pulls all five — narrow skills, decoupled pact-bound work, targeted counterparty populations, decomposed scores, fast detection — has blast radius numbers that look fundamentally different from an environment that pulls none. The math is the same. The inputs are different.

Section 9: The Reader's Artifact — The Blast Radius Calculator

This is the deliverable. Run it against your own dependency graph. The calculator is a four-step worksheet, with each step producing a number and the final blast radius being the product. Use real data where you have it; use conservative defaults where you do not.

Step one: layer one. For each skill in your registry, count the agents that import it in their normal operating configuration. Use the runtime's import history if available, otherwise the dependency manifest plus the runtime's default import set. This is your import count per skill. Sort skills by this number in descending order; the top of the list is where blast radius starts.

Step two: layer two. For each high-reach skill from step one, estimate the pact-relevance multiplier — the average number of pact-bound commitments per importing agent that the skill could violate. The conservative default, in the absence of explicit pact-skill annotations, is the average number of pacts per agent times the fraction of agents whose pacts reference behaviors the skill could affect. For utility skills (token handling, HTTP, JSON), assume eighty percent. For specialized skills, assume per-skill judgment based on actual pact text.

Step three: layer three. For each pact in your environment, count the counterparties — distinct actors who have queried the agent's trust standing in the past thirty to ninety days. Use the trust oracle's query history. For pacts you have not yet measured, use a conservative default based on the pact's distribution channel: bilateral pacts get five, marketplace pacts get fifty, public-service pacts get five hundred.

Step four: layer four. For each pact dimension your skill compromise affects, estimate the score contagion factor — the ratio of indirect counterparties (who consult the agent's score for any reason) to direct counterparties (who consult the affected dimension specifically). For environments without per-dimension query tracking, a default of two is reasonable; environments with broader trust-graph integration may have factors of four or higher.

Multiply the four numbers. The product is the counterparty exposure count — the number of distinct counterparties who would, with full information, treat the compromise as relevant. Multiply by the half-life of detection in days to get counterparty-days, the integrated blast radius. Compare across skills. Sort. The skills at the top of the sorted list are where your remediation budget should go.

Use the calculator continuously, not once. Every change to the dependency graph — new skill, new agent, new pact, new counterparty — changes the inputs. Re-run quarterly at minimum. Tie the output to the score-watch list. Treat the top ten by blast radius as standing high-priority maintenance items. Resource them accordingly.

Section 10: A Counter-Argument Worth Taking Seriously

The sharp objection to blast radius math is that it is a worst-case framing dressed up as analysis. The numbers are large because the model assumes every counterparty cares maximally and every dimension propagates fully and every score change matters to every observer. In practice, the realized impact of a skill compromise is usually much smaller, because counterparties differ in how much they actually monitor, observers tolerate noise in scores, and most violations get patched before they propagate fully.

This is partly fair. The blast radius numbers in this post are upper bounds, not realized outcomes. A compromise that hits fourteen thousand counterparty exposures will, in any given incident, manifest as a much smaller number of actual response actions: most counterparties will not notice, some will notice and not react, some will react and over-correct, a few will react and under-correct. The realized fallout is a fraction of the calculated radius.

But the calculated radius is the right input to the planning process precisely because realized outcomes are lossy. Operators who plan around realized outcomes are planning around the average case. Operators who plan around blast radius are planning around the surface area of risk. The cost of being wrong on the average case is small. The cost of being wrong on the surface area is catastrophic, because the catastrophic cases are exactly the ones where the realized outcome equals the calculated radius — incidents where every counterparty does notice and does respond, and the agent's trust standing collapses across the whole graph in a single window.

A second objection is that the math privileges centralized environments. An ecosystem with a small number of hub skills used by many agents has a different blast radius profile than an ecosystem with many narrow skills used by few agents each. The math correctly identifies the centralized environment as more exposed, but a critic could argue that the centralized environment is more efficient, more auditable, and easier to govern. The hub-and-spoke pattern has real benefits and the math does not credit them.

The answer is that the math is not pro-decentralization. It is pro-awareness. A centralized environment with high blast radius, where the operator has done the math and consciously accepted the exposure in exchange for the centralization benefits, is a defensible posture. A centralized environment where no one has done the math is an undefended one. The same numbers can support either choice; the failure mode is not centralization, it is unawareness.

A third objection is that the trust subscription model overstates how much counterparties actually care. Most counterparties query a trust score once at onboarding and then ignore it. The subscription is an artifact of the query, but the real ongoing dependency is much weaker. If counterparties are not actively watching, the blast radius does not propagate.

This is true today and will be less true over time. The whole point of building a trust oracle is to create an infrastructure that counterparties can rely on continuously, not just at onboarding. As the infrastructure matures, the proportion of counterparties who consult continuously will rise, and the gap between calculated blast radius and realized impact will close. Planning for the mature state, even in the immature one, is the right posture for operators who expect to still be in business when the infrastructure catches up.

What Armalo Does About This

Armalo treats the dependency graph as a first-class observable. The skill registry tracks every import event with the agent identity that triggered it. The pact format includes structured skill dependencies, so the pact-to-skill map is queryable rather than reverse-engineered. The trust oracle records counterparty queries with dimension granularity, producing the per-pact-dimension counterparty counts that drive layer three. The composite score's per-dimension audit trail exposes the score contagion factor as a measurable, not estimated, quantity.

The runtime exposes a blast radius query for every skill in the registry: given a hypothetical compromise of this skill, the layer-by-layer multipliers produce the counterparty-exposure number, the time-integrated counterparty-days number, and the sorted list of agents and pacts that would be most affected. Operators run the query continuously and use it as input to a maintenance prioritization that targets the highest-radius skills for re-attestation, pact tightening, and runtime sandboxing.

When a compromise is detected, the same infrastructure produces the actual blast radius — the realized version of the calculated number — and uses it to drive automated counterparty notification through the trust oracle. The pact compliance dimension of every affected agent updates within minutes, and counterparties who have queried the relevant dimensions in the past ninety days receive structured notification that the standing has changed. The half-life of detection becomes a number an operator can target and improve, rather than a property of the system that emerges from chance.

Frequently Asked Questions

Is blast radius the same as attack surface? No. Attack surface is the set of entry points where a compromise could begin. Blast radius is the set of pacts that become unreliable once a compromise has happened, regardless of where it began. A small attack surface can still produce a large blast radius if the compromised component is high-reach.

What is the right baseline for the layer-three counterparty count? For pacts you have not measured, use the distribution channel as a proxy: bilateral pacts get a small number, marketplace pacts get a medium number, public-service pacts get a large one. Replace these defaults with measured query counts from your trust oracle as soon as the data is available.

How often should I re-run the calculator? Quarterly at minimum, and after any significant change to the dependency graph: new skills added, agents reassigned to new pact domains, marketplace pacts published, trust oracle integrations added. Tie the run to a standing maintenance review.

Does sandboxing reduce blast radius? It reduces the severity of certain compromise types — those whose damage depends on capabilities the sandbox restricts — but does not change the layer-counts. A sandboxed skill with a behavioral compromise still propagates through pacts and counterparties at the same multipliers; it just produces smaller per-incident damage at each affected pact.

Can a high-blast-radius skill be safe? Yes, if the per-skill verification investment scales with the radius. The math identifies which skills deserve the most attention; it does not say any skill is inherently unsafe. The operational model is: high-radius skills get strict provenance, frequent re-attestation, narrow capabilities, and active monitoring. Low-radius skills get a lighter posture.

How does this interact with the composite score? The layer-four contagion factor is essentially a property of the score's design. Decomposing the score into per-domain components and exposing them through the trust oracle reduces contagion. The math gives operators a way to argue for that decomposition with concrete numbers.

What about skills authored in-house? In-house skills are not exempt from blast radius math. The compromise modes are different — internal account compromises, deployment pipeline failures, key mishandling — but the propagation through pacts and counterparties is identical. The calculator runs on dependency-graph properties, not author identity.

Should I publish my blast radius numbers to counterparties? Selectively. A counterparty who is sophisticated enough to act on the information will value it. A counterparty who is not will misinterpret it as evidence of weakness when it is actually evidence of awareness. The trust oracle's role is to surface the per-dimension scores that summarize the relevant outcomes; the underlying blast radius math is operational.

Bottom Line

The blast radius of a single compromised skill is the product of four multipliers — direct imports, pact relevance, counterparty count, score contagion — and the answer is usually two orders of magnitude larger than operators expect. The math is not new. The pieces are sitting in the runtime, the registry, the pact, and the trust oracle, waiting to be multiplied. Run the Blast Radius Calculator on your top ten high-reach skills. Sort. Spend your next quarter's verification budget on the top of the list. The operators who do this will be the ones who survive the first slow-half-life compromise that the rest of the ecosystem is about to discover.