Wire one MCP gateway to a database with an admin credential and you have just made the blast radius of a single bad tool call equal to the entire database. Not the table the agent needed. The database. That is the operational reality of MCP gateways, and it is worth sizing before you connect anything important.
Blast radius is the amount of damage one action, one compromised process, or one bad instruction can do before something stops it. An MCP gateway exposes tools to a model, and those tools reach real infrastructure. So the agent's blast radius is whatever the connection behind those tools can touch. The number to care about is not how clever the model is, it is how wide that grant is.
Where the radius comes from
Two things set it. The scope of the credential the connection uses, and whether that access is standing. A broad credential means a single action can reach far. Standing access means the reach is always live, available to anything that can drive the MCP server, including a prompt the model should never have followed.
The common failure is convenience. The fastest way to get an agent working is to give it a wide service account and leave it on. That ships a demo and a large blast radius in the same afternoon.
It helps to think in terms of two distances. The first is reach: how many systems and tables the connection can touch at all. The second is depth: how destructive a single action can be once it is touching something, a read versus a drop. A wide, admin-grade credential maximizes both at once, which is why one bad tool call can be catastrophic rather than annoying. Shrinking the blast radius means cutting both distances, and they are cut by different controls: scope cuts reach, approval gating cuts depth.
Containing it, operationally
- Scope the connection down. The agent should reach exactly the resources its task needs and nothing adjacent. A tight scope is a small radius.
- Make access just in time. Access that exists only for the task and expires after cannot be misused between tasks. The radius is zero when no session is live.
- Route dangerous operations for approval. A destructive command should pause for a human instead of executing because the model decided to. That breaks the chain before the damage spreads.
- Record every command. Recording does not shrink the radius, but it caps the time you spend finding the edge of an incident.
One control surface, not four scripts
The reason to treat blast radius as a gateway problem is that scope, expiry, approval, and recording all act on the same thing: the connection between the agent and the infrastructure. hoop.dev is an identity-aware proxy that sits on that connection. It binds the session to an authenticated identity, grants just-in-time access scoped to the resource, routes risky commands for human approval, and records the session at the command level.
So the blast radius of an MCP-connected agent stops being whatever the credential allows, forever, and becomes this resource, for this task, with destructive actions gated. The containment lives on the connection, below the MCP server, where the agent cannot widen its own scope. One model ends access on disconnect. The other checks every command on the way through.
For the mechanics, see how scoped, time-bound access is set up and the wider argument in hoop.dev's runtime governance writing.
FAQ
What sets the blast radius of an agent on an MCP gateway?
The scope of the connection's credential and whether access is standing. Broad and permanent is a large radius. Narrow and just-in-time is a small one.
Can I rely on the model to limit its own blast radius?
No. The model can be wrong or be steered by injected instructions. Containment has to live on the connection, enforced below the agent where it cannot reconfigure the limits.
How does approval help?
Routing destructive commands for human review stops the most damaging actions from executing automatically, which caps the worst case regardless of what the agent was told to do.
The gateway is open source. Read it and deploy it from the hoop.dev repository on GitHub to put a real boundary around what your MCP tools can reach.
