The question to ask before switching anything on
Not “will this work?” but “if this runs wrong two hundred times tonight, what will I be repairing tomorrow?”
That is blast radius, and it is decided entirely by what you connected, not by how good the prompt is.
Give it its own account
The commonest and worst setup is an automation running under the owner’s login. It inherits everything: every folder, every mailbox, every permission accumulated over six years, including the ones the owner has forgotten they have.
Instead, make a separate account for the automation (automation@yourbusiness) and share with it only the specific folder, calendar or inbox it needs. This costs one extra seat on most platforms, sometimes nothing, and it converts “it can reach everything” into “it can reach one folder”.
It also gives you a clean audit trail. When something odd is filed at 03:40, the log shows who did it, and the answer is not ambiguous.
Read and write are different permissions
Most platforms let you grant read without write, and most people grant both out of habit because the setup screen makes it one click.
Separate them deliberately:
- An automation that summarises orders needs read on orders. Nothing else.
- One that files documents needs write on one folder, not the drive.
- One that drafts replies needs draft permission, which several mail providers expose separately from send. Use it.
The difference is not theoretical. Read-only access that misbehaves produces a wrong summary. Write access that misbehaves produces two hundred modified records and a restore from backup, assuming you have one.
Keys, and where they must not be
An API key is a password that works from anywhere and is usually not protected by anything else. Treat it exactly as you would the bank login.
- One key per automation, so you can revoke one without stopping the rest.
- Never in a message, a shared document, a screenshot, or a spreadsheet cell. Keys pasted into a team chat are among the most common ways small businesses get an unexpected bill.
- Rotate when anybody with access leaves.
- Set the spending cap per key where the provider allows it.
If a key has ever been in a message, treat it as public and replace it. Revoking is free; discovering later that somebody has been using your account is not.
The connection you forgot you made
Blast radius grows by accretion rather than by decision. You connect the automation to your drive to read one folder, and six weeks later somebody moves a folder of scanned contracts into the same drive. Nobody granted anything; the boundary moved because the contents did.
This is why access should be granted to the narrowest container the platform allows (a specific folder, a specific label, a specific calendar) rather than to the account that holds it. The narrow grant survives somebody reorganising the filing; the broad one silently expands to include whatever arrives.
The same applies to integrations sold as one-click. “Connect your mailbox” usually means full read and send on everything, including the folder with your bank correspondence in it. Read the permission screen rather than clicking past it; it is the only moment the software will tell you the truth about what it is taking.
Bound the action itself
Permissions limit what it can reach. Rules limit what it can do with what it reached, and you want both.
- A maximum per run: “no more than twenty emails an hour”, “no invoice above USD 500 without a person”.
- An allow-list where you can: it may send only to addresses already in your customer records.
- A stop condition: if more than three actions fail, halt and notify rather than continuing.
These are trivial to write and they are what turns a bad night into a bad ten minutes.
Backups, which now matter more
Automation makes a bad backup situation worse, because the damage arrives faster and looks legitimate. Two questions worth answering before you connect anything with write access.
How would you restore your customer records if four hundred of them were modified incorrectly overnight? And do you have a copy that a compromised key could not also reach, which is what “offline” or “separate account” means in practice?
A cloud provider’s version history usually covers this and is usually switched on. Usually is not a plan. Check, and check that you know how to use it under pressure, because the afternoon you need it is not the afternoon to learn.
The five-minute review
Once a quarter, for every automation you run: what account does it use, what can that account see, what can it change, which key does it hold, and what is the per-run limit.
Most businesses doing this for the first time find at least one automation with access to something it has not needed since the second week. Remove it. The cost of over-permission is zero right up until the day it is the entire problem.
Every lesson here is open. Your progress is recorded once you pass the AI at Work exam.
Check your understanding
A practice connects a booking-summary automation using the owner’s own login because it was quickest, and sets a strict prompt forbidding it from touching anything except the bookings calendar. Why is this weaker than a separate account with calendar-only access?
Pick the one you would defend. Your answer stays private.
Stuck on something?Ask Yetunde, your AI tutor
