The privilege escalation nobody notices
An automation is a stored instruction that runs later, often with more access than the person who wrote it. If a coordinator can configure a rule that changes prices, deletes records or messages the whole customer list, they have just acquired permissions they were never granted directly.
The control is simple to state: rule creation is a privileged permission, and a rule's actions are bounded by what its authorising user is allowed to do. Enabling a rule should be as controlled as performing its most dangerous action by hand.
Four distinct actor types
- User: a person clicked something. Attribution is direct.
- Automation: a configured rule fired. Record the rule and its authorising user.
- Assistant: an AI took a registered action. Record both the assistant and the human who authorised it.
- System or webhook: an external event or scheduled process. No user; label it honestly.
Why attribution matters more than it sounds
Six months later, someone asks why a customer received a message, why a status changed, or why an invoice was created. Without an attributed actor you get a shrug. With one you get a rule name, a timestamp and the person who enabled it — which is the difference between fixing a process and arguing about it.
It also matters for tenancy. Every automated write must be scoped to the organisation it belongs to, resolved on the server rather than taken from whatever the request claimed.
What to gate hardest
- Anything that sends externally on the company's behalf.
- Anything that moves money, changes prices, or issues credit.
- Anything destructive, including bulk status changes.
- Anything that changes advertising spend or publishes ads.
- Anything that grants access or changes another person's permissions.