There is a long list of things to worry about when you connect an AI agent to real systems. Prompt injection, data leakage, over-permissioned tokens, agents that take an instruction too literally. Each deserves attention. But before any of them, there is a simpler question I’d ask first.
If this goes wrong, what is the worst that can happen?
That is the blast radius. It is not a measure of how likely a failure is or how clever the attack was. It is the set of things that can be touched when the failure happens. There is a reason to start here: you control it in advance, before anything goes wrong, and it bounds every kind of failure at once.
If the agent never had a path to your passwords, a mistake cannot leak them. It does not matter whether the mistake was a hallucination, a poisoned web page, or an ambiguous instruction from you. If the agent never had a path to customer data, a bad day stays an internal problem rather than a notification you have to send. The failure modes are endless. The blast radius is finite, and you own it.
Four questions
Here are four versions of the question, in the order I would ask them.
Could it reach credentials? Password managers, API keys, SSH keys, crypto wallets, the .env file in a project folder, the session cookies in a browser profile. Credentials are the one category where a leak is never contained, because whatever they unlock is now in the blast radius too. If an agent has a file-system tool and your keys are on that file system, the honest answer is yes.
Could it reach customer data? Customer records, patient data, payroll, anything that belongs to someone else or sits under a contract or a regulation. The distinction matters because the consequences are different in kind. Losing your own notes is embarrassing. Exposing a customer’s data creates obligations: to tell them, to tell a regulator, to explain what happened. If the agent cannot reach that data, none of that ever happens.
Could it do something that cannot be undone? Delete files, drop a table, send an email, post in a public channel, move money, force-push over a branch. Reads can be embarrassing. Writes can be permanent. An agent that can only read has a blast radius measured in what it saw. An agent that can write has one measured in what it changed, and some changes have no undo.
Could it talk to the outside world? Email, Slack, a web request, a file upload, a public repository. This is the exit path, and it multiplies everything above. Sensitive data an agent can read but cannot send stays inside. The same data with an exit path is one confused step away from leaving. When you tally the blast radius, reach and exit are two different axes, and the product is what you should worry about.
Then limit it
Once you have honest answers, the work is to shrink them. There are three moves, and you will use all of them.
Remove access the agent does not need for the job. Narrow what remains, by time, by scope, or by making it read-only. And filter what comes back, so a call succeeds but returns less than everything.
I wrote about doing exactly this for my own email in My Claude Guardrails. Claude can search my mailbox, but it gets results only from the last two weeks, and it cannot widen the window by phrasing the search differently. Old conversations come back empty. Claude still does real work in my email every day. The blast radius of that access is two weeks of mail, not fifteen years of it. That is the shape every good limit has: the agent keeps working, and the worst case got smaller.
Only you know where the crown jewels are
Here is the part no vendor can do for you. Some limits are universal. Nobody should let an agent near their password manager or their signing keys. But past that short list, the blast radius is personal.
Your most sensitive documents might be in SharePoint. Your colleague’s are in a folder on a laptop that has never been backed up. Someone else’s are in Box, or in a Slack channel, or in a spreadsheet named final_v3. A policy that protects SharePoint does nothing for the laptop folder. The only person who can draw the map is the person who knows where the things are.
So the work is thinking, before it is tooling. Sit down for half an hour and list everything your agent has access to today. Every connector, every tool, every folder. For each item, run the four questions. Then decide, item by item: remove it, narrow it, or filter it. Write the decisions down. Revisit them the next time you add a tool, because every new connection redraws the map.
That half hour is the most valuable security work you will do on AI this year. Not because agents are dangerous, but because you want to keep using them on real work, and that is only sustainable when you know what the worst case is and have made it small.
Good policy unlocks AI adoption. It starts with knowing your blast radius.
When you are ready to turn the list into policy, Dtwo is built for it. Start a free trial.
FAQ
What is blast radius in the context of AI agents? Blast radius is everything an agent could damage, expose, change, or send when it does the wrong thing. It is set by what the agent has access to, not by how the failure happens. An agent that has no path to your passwords cannot leak them, however badly it is fooled.
Why does blast radius matter more for agents than for other software? Agents take actions on your behalf across many systems, and they can be wrong, misled, or simply too literal. You cannot predict every way that happens. You can decide in advance what the consequences are bounded by, and that bound is the blast radius.
How do I limit the blast radius of an AI agent? List what the agent has access to. For each item, ask whether it includes credentials, customer or regulated data, irreversible actions, or a path to the outside world. Then remove access you do not need, narrow what remains by time, scope, or read-only, and filter what comes back. Only you know where your sensitive data lives, so the list has to be yours.