Section 1
Two different problems wearing one label
Data security in automation splits into inbound and outbound. Outbound is what leaves your control: what gets sent to a model provider, whether it is retained, whether it trains a future version, and which subprocessors touch it on the way. Inbound is what the system can reach inside your business. An automation with read access to a shared drive can surface anything in that drive to anyone who can trigger it, including documents the requester was never meant to see. This one surprises people, because the permissions were correct at the file level and wrong at the workflow level. Treat them as separate reviews with separate owners. Solving one tells you nothing about the other. The data foundations underneath both are covered in [The Role of Data in Effective AI Automation](/blog/the-role-of-data-in-effective-ai-automation).
Section 2
Least privilege, applied to workflows
The old principle transfers directly. An automation should have the narrowest access that lets it do its job, and no more. In practice this means a dedicated account per workflow rather than a shared one, scoped to specific folders, tables, or mailboxes. This is more work than granting broad access once, and it is the difference between an incident that affects one workflow and one that affects everything. It also makes the logs meaningful. When every automation acts under its own identity, you can answer what happened afterwards. When they all share an account, you cannot, and the answer to what did it touch becomes everything it could reach.
Section 3
The contract is a security control
Retention periods, training rights, subprocessor lists, breach notification, and data location are all decided in the vendor agreement, not in your configuration. Read them before the workflow is embedded, because afterwards the review becomes a negotiation you have already lost by depending on the tool.
Section 4
Making it real without stopping the work
Blanket bans do not work. They push usage onto personal accounts where you have no visibility at all, which is worse than the problem you were solving. Give people a sanctioned tool with acceptable terms, then make the rule concrete. Name the categories that must never be pasted anywhere: customer identity documents, payment data, credentials, unreleased financials, personal data about employees. A named list is followed. An instruction to be careful is not. Then close the gap with defaults: sensible retention settings, single sign-on so accounts die when people leave, and a periodic review of what each automation can still reach. Access granted for a pilot outlives the pilot in almost every company.
Section 5
The controls worth having, in order
The NIST language of trustworthiness, design, evaluation, and use becomes five controls in a small company: know what each system can access, know what it can change, decide what it must never do alone, log every automated action, and name an owner accountable when something reaches a customer. After those, add the ones specific to this technology. Keep sensitive fields out of prompts that do not need them, which is usually a redaction step rather than a policy. Confirm retention and training terms in writing. Watch for prompt injection wherever a workflow reads content from outside, since a system that reads incoming email and can also send it is a system that can be instructed by a stranger. Treat any external content as data, never as instructions.
Section 6
Measuring security without theatre
Policy acknowledgements measure nothing. Track the number of automations with a documented owner and access scope, the share running under dedicated rather than shared credentials, time to revoke access when someone leaves, and the count of workflows that can send external communication without review. That last number is your blast radius. It should be small and you should know every item on it by name. Review quarterly, and re-review every time a workflow gains a new permission, because scope creep is how a safe automation becomes an unsafe one without anyone deciding to make it so. The sequencing context is in [Building an AI Automation Roadmap for Your Startup](/blog/building-an-ai-automation-roadmap-for-your-startup), and [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation) covers communicating a policy people will actually follow.