Excessive agency and blast radius
The question of what an agent could do at its worst, not what it usually does. Permissions, spend limits, irreversible actions and human checkpoints. Mostly a design review, and testers are unusually well placed to run it.
On the intern's first day, someone hands them a key.
Not the key to their desk drawer. The master key — every room, the server cupboard, the safe, the front door. Nobody meant anything by it. It was simply the key that was in the drawer.
Nothing bad happens for months. Then something does, and the question in the room afterwards is not "why did they do that?" It is "why could they?"
That is excessive agency. And the test for it takes an hour, needs no code, and can be run before the feature is even built.
Three kinds of too much
Too many tools. The agent can reach things this job never needs. A refund assistant that can also delete customers.
Too much permission on a tool. The tool exists for a reason, but its credentials are wider than the job — a database user with write access when reading would do.
Too much freedom. No spend cap, no step limit, no human approval on anything, no upper bound on the value of an action.
Any one of these is enough. Together they are how a small mistake becomes an incident.
Why you should care about this
Because this is the one place on the layer where a tester can prevent an incident rather than document one.
Everything else here measures behaviour after it exists. A blast-radius review needs only the list of tools, which exists on day one, in a design document, before there is anything to click. Findings at that point cost a conversation. The same findings after launch cost an incident review.
It is also familiar work in unfamiliar clothes. Ranking by consequence rather than by likelihood is exactly the risk thinking testers have always done; the only new part is that the actor is a model that will occasionally be talked into something by a sentence hidden in a document.
Everything else on this layer asks what the feature does. This one asks what it could do. Only one of those questions can be answered before the code exists.
How you run the review
An hour, a table, and the person who built it.
1. List every tool. Name, what it does, what it touches. If nobody can produce this list, that is finding number one.
2. Mark what changes the world. Reads are cheap. Writes, sends, payments, deletions and permission changes are the rows that matter.
3. Mark what cannot be undone. An email is sent forever. A refund can be reversed but the customer already saw it. A deleted row may be recoverable from a backup — ask whether anyone has ever tested that.
4. Write the worst case in one sentence per row. "Refunds every order for every customer." "Emails a thousand customers the wrong policy." Plain language, no hedging.
5. Ask what stops it. For each worst case: a permission check outside the model, a value cap, a rate limit, a human approval, or nothing. "Nothing" is the answer you are looking for, and it appears more often than you would like.
6. Ask who the agent is. Whose credentials does it use? A service account with broad rights, or a scoped identity? An agent acting as a superuser inherits every permission that user has, forever.
7. Then test the top three. Try to trigger the worst case in a sandbox, including by talking it into the action rather than clicking a button.
Try this today
Ask for the tool list. Fill in five columns. This is the deliverable — the table itself is the work.
FEATURE: support assistant credentials: svc-support (write on orders, tickets, mail)
TOOL CHANGES? UNDO? WORST CASE WHAT STOPS IT
get_ticket no - reads any ticket, any customer nothing <-- scope?
get_customer no - reads any customer record nothing <-- scope?
search_docs no - reads internal-only documents doc filter (untested)
request_refund YES partial refunds any order, any amount threshold 100 in the
prompt only <-- !!
send_email YES NO emails any customer, any content nothing <-- !!
close_ticket YES yes closes tickets wrongly nothing
update_customer YES partial overwrites customer details nothing
TOP THREE RISKS
1 refund limit lives in the prompt, so anything that talks past the prompt
removes the limit entirely — needs a check in the payment service
2 send_email is unbounded and irreversible: no rate limit, no template
restriction, model controls the body
3 service account has write on all orders, not just the customer in context
ASKED, NOBODY KNEW
- what is the maximum spend per run?
- who is alerted if a refund is issued outside the threshold?Look at risk 1. The refund limit is written in the prompt, which means it is a request rather than a rule — and everything in the injection topics is about getting past requests. Moving that number into the payment service is a one-line change nobody had thought to ask for.
How to show you know it
The table. Seven rows, five columns, three named risks. It is the single most reusable artefact on this layer and you can produce it before the feature works.
A limit that lives in the wrong place. Finding a business rule enforced only by the prompt is the classic result of this review, and it is always worth fixing.
An identity question. "Whose credentials does it use, and are they scoped to the customer in context?" Nobody expects a tester to ask, and the answer is often uncomfortable.
An unanswered question, written down. "What is the maximum spend per run?" recorded as an open item is a finding. Decisions nobody has made are risks nobody owns.
Questions
Is this security work or testing work?
Both, and the split does not matter much. Security teams review the perimeter; this is about what the feature is permitted to do once it is working normally. Testers are well placed because it is really a requirements question in disguise.
The team says the model would never do that. What do I say?
That the model does not need to want to — a sentence planted in a document it reads is enough. Then point at the row where the answer to "what stops it" is "nothing".
How do I rank the findings?
Irreversible first, then money, then anything touching customers, then internal data. Likelihood matters less than usual here, because the whole point is that a rare event with an unbounded consequence is worse than a common one you can undo.
Can I do this without engineers?
You can draft it from the tool list and the design document, and you should. The last two columns need an engineer, and the conversation that fills them in is where most of the value lands.