Work out the blast radius before you grant a scope

Every useful version of this exercise starts by granting the attacker the win. An agent reads text it did not write: a web page, an email, a tool description. Some of that text will eventually be an instruction it follows.

So the question is never whether it can be tricked. It is what it can reach in the minute after it is, and that is entirely decided by what you ticked during setup.

Write down every permission the setup asks for, in its own words. The one people forget is never the frightening one; it is the one that reads like plumbing. Network access. Environment variables. A webhook.

Those are exactly the scopes that turn a contained problem into a disclosure, because they are how the other permissions get their results out.

Read credentials, on its own, is a bad afternoon. Read credentials plus reach any host is a breach, and nobody objected to the second one. Write files plus run commands is arbitrary code execution assembled from two ordinary requests.

This is why permission review as a checklist fails: each line passes on its own merits and the set is indefensible. Review the set.

Remove one permission at a time and see which removal changes the picture most. That scope is the conversation to have with the maker, and the good ones have an answer: a narrower integration, a read-only mode, a declared host list.

Where the answer is that it needs everything because it is easier that way, you have learned something about the software that no test result would have told you.

Never hand over a personal token carrying your own access. Issue a scoped one, and know how to revoke it before you grant it rather than while you need to.

Then rotate whatever you gave it on the day you stop using it. An agent you uninstalled and a credential you left live are not the same decision, and only one of them was made.