When I review an automated action, my first question is not what it does. It is what it can reach.
Three boundaries answer that question: scope, time, and consequence.
They matter because many automation incidents are not caused by the wrong action. They are caused by the right action at the wrong size. An update meant for one record runs against a million. A cleanup meant for a test environment points at production. The action was approved, and it may even have worked. It just worked on far more than anyone intended.
The last two issues covered approval and recovery. Approval decides whether the system may act. Recovery decides whether you can get back after it does. Together, they leave another design question: how much of the system one action is allowed to affect. Engineers call it the blast radius. That question changed how I read a design. I used to look at what an action does. Now I look for the line around it.
The first boundary is scope.
Scope is what the action can touch: which systems, which tables, which records, and how many of them. A query with a WHERE clause can feel bounded and still match every row in the table. What bounds the action is the set of records it is allowed to change. Someone has to decide that set on purpose, before the action runs.
Human access already works this way. A new engineer does not get write access to every table on day one. A new automation often gets exactly that, because scoping it takes extra work and the demo ran fine without it.
Scope also includes a number. An action built to update forty records should stop when it matches forty thousand. That stop is not the system failing. The action hit something nobody expected, and the count deserves a look before the write happens, not after.
The second boundary is time.
Time is when the action may run and how long its permission lasts. An action allowed to run once, right now, carries a different risk than an action allowed to run whenever its trigger fires. A credential issued for a task is different from a credential that outlives the task by two years.
Retry logic makes this concrete. An action that fails once and stops is an event. An action that fails and retries all night is an outage. The code and the intent are the same in both. The difference is that nobody put an edge on how long it was allowed to keep trying.
Setting an expiration is not free. Enforcing it means renewal, rotation, and handling the moment it lapses. But it forces a decision about when access should end. Without that decision, temporary access just becomes standing access.
The third boundary is consequence.
Consequence is where the action lands. Drafting a refund email and issuing the refund can look like the same feature in a design document. In production, one is a draft and the other is money leaving an account. The same gap sits between writing to a staging table and writing to the system of record, and between suggesting a change and applying it.
The work is choosing the least consequential surface that still does the job. If a suggestion is enough, do not grant the write. If staging proves the point, leave production out of it. Most of the time the wider surface is a convenience, not a requirement.
This is where containment meets recovery. Recovery asks whether you can undo what the action did. Consequence asks whether the action needed to land somewhere that requires undoing at all. The cheapest recovery is the one the boundary made unnecessary.
The principle under all three is simple. The size of a failure should be a design decision, not a discovery.
Teams skip this because the action worked in the demo. But the demo ran against ten rows, in a sandbox, with the author watching. Production is where the same action meets real scale, standing credentials, and records that matter. An unbounded action is not more capable than a bounded one. It is the same action, unsized.
Every automated action has a blast radius. If you did not choose it, you will meet it.