Blast radius and reversibility: how much can this tool call break?

Most agent incidents are not exotic attacks. They are ordinary operations (a delete, an overwrite, a deploy, an email) run in the wrong place, on the wrong target or at the wrong time. A rule like "never run DELETE" is too strict for a database agent whose job is cleanup, and too loose for an agent that can run UPDATE without a WHERE clause.

A better first question is: if this action turns out to be wrong, how bad is it and can we undo it? That splits into two properties that are worth scoring separately:

• Blast radius: how far the effect reaches.
• Reversibility: whether the effect can be undone, and how cheaply.

An action with a small blast radius and an easy undo can usually run without a human. An action that reaches production or the outside world, and cannot be taken back, deserves friction even when the agent is probably right.

MCP Guard's blast_radius head places every action on an ordered scale:

The ordering matters more than the labels. Read-only calls are rarely where the damage happens, although they can still leak data (that is the job of the exfiltration head, covered in prompt injection through tool results). The top level is where most of the irreversible harm lives, because once a message is sent or a payment is made, no rollback on your side brings it back.

The separate destructive head asks a narrower question: does this action delete, overwrite or irreversibly change data? A git push --force to a shared branch is both destructive and production-mutating. Sending an email is not destructive (nothing is deleted) but it is an external side effect. Keeping the two apart lets you treat "loses data" and "is visible to others" differently.

The same command can be fine in one environment and unacceptable in another. What changes is usually not the command but the safety net around it:

• Backups and point-in-time recovery. A DROP TABLE on a database with tested point-in-time recovery is expensive, not catastrophic.
• Soft delete. If "delete" sets a flag and a job purges later, a mistaken delete is a support ticket rather than an outage.
• Dry runs and plans. terraform plan, kubectl diff and --dry-run flags turn a write into a read. Many teams let agents run the plan freely and ask a human before the apply.
• Staging and branches. Changes on a branch or a staging database are reversible by design; the same change on main or production is not.
• Transactions. A write inside an open transaction can still be rolled back; the commit is the irreversible step.

A pre-execution guard cannot inspect your backup policy. It judges the action from the text it is given. So if an action is in fact reversible in your setup, say so in the check; otherwise the guard has to assume the worst plausible reading.

Two request fields carry what the guard cannot infer: context (free text about the agent, its role and its environment) and constraints (rules the action must respect). A check for a database agent working on staging might look like this:

{
  "action": { "tool": "sql.execute", "args": { "query": "DELETE FROM sessions WHERE created_at < now() - interval '90 days'" } },
  "intent": "Clean up sessions older than 90 days on staging",
  "trigger": "user_request",
  "context": "Database agent. Connected to the STAGING replica. Nightly snapshots, point-in-time recovery enabled.",
  "constraints": ["Never modify production", "Deletes must have a WHERE clause"]
}

Good context is short and factual: which environment, what the agent is for, what safety nets exist. Good constraints are the rules you would tell a new colleague on day one. Do not use context to talk the guard into approving something ("this is definitely safe"); describe the facts and let the scores follow.

Only send what is true. If you describe a staging database but the agent is connected to production, the guard's scores will reflect the story, not reality. That is one reason to derive context from configuration (the connection string, the deploy target) rather than from what the model says about itself.

A reasonable policy uses blast radius and destructiveness to decide how much friction an action gets, and the overall safe score and the approval_policy head to decide the verdict. By default the service returns block if P(unsafe) is at least 0.8 or the policy head says reject, ask if P(unsafe) is at least 0.3, the policy head says require_human, or args_grounded is below 0.5, and allow otherwise. You can apply your own thresholds on the scores; a common adjustment is to lower the ask threshold for actions scored as production-mutating and destructive, and to raise it for read-only calls.

Keep deterministic rules for the cases that must never happen, whatever any model says: the agent's database user has no DROP privilege on production, the deploy tool refuses to target main without a review, the cloud credentials cannot delete backups. The guard reduces the chance that a bad action gets through the flexible middle ground; it does not replace least-privilege credentials. See allowlists and denylists vs a guard for how the two fit together.