Read access decides what you can lose. Write access decides what you can break. Almost everyone conflates the two, hands over one credential that does both, and then hopes the system behaves. Hope is not a control.
Start with the number that matters. Blast radius is the complete list of what a system could damage if it went wrong in the worst plausible way on a single run. Not how likely that is. Just the list.
You should be able to produce it for every automation you run, in one or two lines, without investigating. If producing it requires investigation, you have already found your answer.
Separate the two questions
Ask them independently, because the right answers are usually different:
- What does it need to read? Wrong answers here leak. The damage is exposure, it may be silent, and it is not undoable.
- What does it need to change? Wrong answers here break things. The damage is loud, usually recoverable if you planned for it, and occasionally catastrophic if you did not.
Most tooling defaults to a single credential with broad rights on both. That is the configuration that makes the demo work on the first try. It is also the configuration that makes the incident report long.
Default worth adopting
Read narrow. Write narrower. Delete never, without a person. Nothing irreversible without a person.
Four levels of write
Write access is not one thing, and treating it as one thing is what makes people either too permissive or too restrictive. There are four levels, and moving down one level is often the entire safety design:
- Propose. It produces a draft somewhere a person will see it. Nothing has changed in the world. Almost all first automations should live here.
- Write to its own space. A dedicated folder, table, or branch that only this system touches. If it writes garbage, you delete the folder.
- Write to shared systems, reversibly. Real records, real consequences, but versioned and restorable, with an audit trail showing which entries came from the system.
- Irreversible action. Sending to a customer, moving money, deleting, publishing. A person approves each one, or it does not happen.
Most requests to give a system level three or four are actually requests to skip the review queue, which is a staffing problem wearing a technical costume. Solve it as a staffing problem.
Scope the credential, not the intent
Prompts are not permissions. Telling a system not to touch the customer table is a preference. Not giving it access to the customer table is a control. The gap between those two sentences is where nearly every avoidable incident lives.
Practically, this means:
- A separate account per system, never a person's account. A system using someone's credentials produces logs that blame a human for what a machine did, and it inherits every right that person accumulated over nine years.
- Access to specific resources, not to categories. This folder, not all files. This table, read only. This mailbox, not the mail server.
- Credentials that expire and can be revoked in one place, quickly, by someone who is awake at the time.
- A hard spending limit at the vendor, set at the account level. A loop that retries forever is a cost incident whether or not it is a security one.
Approvals that people actually use
A gate everyone clicks through is not a gate. Three rules keep approvals meaningful:
Gate on consequence, not on frequency. Approve the irreversible things and let the reversible things run. If your gate fires forty times a day, it is being rubber stamped by lunchtime and you have bought paperwork rather than safety.
Show the diff, not the essay. The approver needs to see precisely what will change. Give them a summary of the reasoning and the exact change, and they will catch things. Give them a wall of transcript and they will approve it unread.
Keep the path to one person. A two person approval on a routine action means each assumes the other looked. One named approver, and a short list of what they are actually responsible for catching.
Start narrower than feels reasonable
Give a new system less access than you think it needs and let it fail. Each failure tells you exactly what it needed, which is nearly always less than the initial request. You learn it in a controlled way rather than by discovery.
Widening access is a five minute change and a small conversation. Explaining why something had broad access when it should not have is a much longer conversation, and by then it has an audience.
Revision trail