What’s your AI blast radius?
The question people usually ask about a new AI agent is whether they trust it. That is the wrong question, and it is worth saying why before you connect anything to anything else. Trust is not really a yes or no you can check once and move on from. The question that actually protects your business is smaller and much more answerable. If this thing does something wrong, the real question is how much damage it can do.
That is the whole idea behind what we call blast radius, and it is worth thinking through before you give any AI tool the ability to act on your behalf, not after.
Trust is not a control. Scope is.
Every AI tool will eventually do something you did not expect. Not because it is malicious, but because it is a very well read guesser, not a person who understands consequences the way you do. It will misread an instruction, follow a prompt injected into a document it was asked to summarize, or confidently take the wrong action on incomplete information. That is not a hypothetical. It is closer to a when than an if.
Once you accept that, the useful planning question changes. It stops being “can I trust this” and becomes “what is the worst thing that happens if I am wrong.” An agent with read-only access to a shared calendar has a small answer to that question. An agent with the ability to send emails, move money, or delete files has a much bigger one. The size of that answer should drive how much freedom the agent gets, not how impressive the demo looked.
What blast radius actually means here
Blast radius, in this context, is the full scope of what an AI agent can see and do. Multiply that by the worst plausible outcome if it acts on bad information, and you have the real number that matters. Two things set it: how much access the agent has, and how much of that access is read versus write.
Read access is looking. An agent that can read your calendar, search your files, or pull data from a system can produce a wrong summary or a bad recommendation. That is a real problem, but a contained one. A person still has to act on what it says before real damage happens.
Write access is doing. An agent that can send an email, update a record, move a file, or spend money acts directly, sometimes without anyone reviewing the action first. That is where a bad guess stops being an inconvenience and starts being an incident.
Start read-only, add write access on purpose
The safest default for any new AI agent or automation is read-only, full stop. Let it look, summarize, and suggest before it ever gets the ability to act. This is not overcaution. It is how you find out what the agent actually does with a given task before that behavior can cause a problem you cannot undo.
When you do decide an agent needs to take action, keep a person in the loop for anything with a real consequence attached. A calendar agent that proposes a meeting time and waits for a click to confirm it carries almost no risk. The same agent auto-booking a client meeting without confirmation carries more, even though the underlying task looks identical on the surface.
Put a real number on the worst case
The most useful version of this question is not abstract. It has a dollar figure or a specific boundary attached. Before you give an agent any kind of write access, decide what you are actually willing to lose if it gets something wrong. Build the access around that number, not around how convenient full access would be.
Think of it the way you would think about handing a new hire a company card on day one. You would not hand them your business checking account and tell them to figure out the budget as they go. You would give them a card with a real limit on it. Let them use it inside that boundary, then expand it once you have seen how they actually handle it. The same logic applies to an AI agent with access to your systems. Give it a boundary small enough that the worst case is a bad afternoon, not a bad year, and widen that boundary only as it earns it.
A short checklist before you give an agent write access
- Confirm whether the agent needs read access, write access, or both, and default to read-only unless there is a specific reason for more.
- Set a concrete limit on anything involving money, whether that is a spending cap, an approval step, or both.
- Require a human confirmation step for any action that is hard to undo, such as sending an external email or deleting a file.
- Check whether the tool logs what it did, so a mistake is something you can trace rather than something you discover secondhand.
- Ask what happens if the agent is given a bad or malicious instruction hidden inside a document it is asked to read. That is a common way these tools get misused without anyone typing a bad prompt directly.
None of these questions require deep technical knowledge to ask. They require asking them before the agent is live, not after something goes wrong.
Common questions
It scales down fine. A two-person accounting firm using an agent to draft weekly summary emails needs a much smaller version of this thinking than a company automating financial transfers. The underlying question is the same size regardless of company size: what happens if this is wrong. Skipping the question does not make the risk smaller. It just means you find out about it later.
They are related but not the same. Our piece on Copilot and SharePoint covers what an AI tool can see through existing file permissions. Blast radius covers what an agent can do once it has access, including actions that go beyond simply reading a file. A tool can have a small read footprint and still have a large blast radius if it has broad write access, and the reverse is also true.
Ask what it is connected to and what each connection allows, specifically. “It’s connected to our email” is not a complete answer. Whether it can read email, send email, or both is the actual answer needed. Whoever set up the connection should be able to answer that in one sentence. If they cannot, that is worth treating as a signal on its own.
The depth should match the stakes, not apply uniformly to everything. A read-only agent that summarizes public news does not need the same scrutiny as one with access to customer records or company funds. The mistake we see most often is not overthinking the simple cases. It is skipping the thinking entirely for something that looked simple at first and quietly grew more access over time.
Audit what they can actually touch before you add the next one. It is common for early AI experiments to get broad access because nobody expected them to stick around. Then they become part of daily operations without anyone revisiting the original setup. That review is worth doing on its own, independent of whatever new tool prompted you to think about this.
Where to start
Before your next AI tool gets connected to anything, write down two things: what it can see, and what it can do if it is wrong. If the honest answer to the second one is bigger than you are comfortable with, that is the access to scope back, not a reason to avoid AI tools altogether.
If you want help thinking through what a specific agent or automation should and should not be allowed to touch, our team does this scoping work regularly. We are happy to walk through your specific setup. That conversation is free, and it usually settles the question faster than debating it internally would.
