Is our data safe if we automate?
The automation runs inside your own accounts, on subscriptions you own and pay for, with credentials held in your vault rather than ours. We build it there and hand it over. Nothing is copied to a system of ours, and our access is something you can revoke in an afternoon without the automation stopping.
The honest part: your data does pass through the automation platform in transit, and through a model provider wherever AI is involved. Those are real third parties with real terms, and they are worth reading rather than assuming. We name every one during scoping and tell you what each can see.
The real risks are mundane rather than dramatic, over-broad API permissions, a shared login nobody rotates, and credentials tied to someone who has since left. Those are worth more of your attention than the platform's security page.
Where your data actually goes
An automation is a path between systems you already run. Following that path is the clearest way to see the exposure.
| Stage | Who holds the data | What they can see |
|---|---|---|
| Source system | You, as today | Unchanged by automating, your CRM already holds this |
| Automation platform | The vendor, on your subscription | The fields each step passes through, plus execution logs for a retention period you configure |
| Model provider, if AI is involved | The provider, on your API key | Only the text sent in each request |
| Destination system | You, as today | Unchanged |
Two things follow from this. First, the platform's execution history is the part people overlook: it stores the actual payloads, and its default retention is often longer than you would choose. We set it deliberately rather than leaving the default. Second, automating does not create a new copy of your database anywhere; it moves individual records between places that already hold them.
If even that is more exposure than you want, self-hosting removes the platform vendor from the path entirely. n8n runs on your own infrastructure, which is the usual answer for businesses with genuine data-residency constraints.
What AI providers do and do not keep
The concern people raise most often is whether their data ends up training a model. The answer depends on how you access the model, and the distinction is worth understanding because it is often reported wrongly.
- Consumer chat products and free tiers generally reserve broader rights over what you submit. This is the tier the alarming headlines are usually about.
- Business API access, which is what an automation uses, is a different agreement. The major providers do not train on API inputs by default, and retain them only briefly for abuse monitoring. Zero-retention arrangements are available from some providers on request.
We do not ask you to take that on trust. During scoping we name the exact provider and tier, point you at the current terms, and where it matters we get the retention setting in writing before anything is built. If a provider's terms are not acceptable to you, the model is swappable: we choose per task on measured accuracy, not preference, so changing provider is a configuration change rather than a rebuild.
Do not send fields the task does not need. An agent triaging support email needs the message and the account reference; it does not need the customer's payment details or date of birth. Restricting the payload at the source is more effective than any assurance about what happens downstream, and it costs nothing.
What we can see, and how to remove us
To build in your accounts we need access to them. Here is the shape we ask for and why.
- Named accounts, not shared logins. Each of us gets our own, so the audit trail attributes actions to a person and removal is one action.
- Scoped permissions. Access to the systems in scope, at the level the build needs, rather than administrator everywhere because it is quicker.
- Credentials in your vault. The automation authenticates using connections stored in your platform account. They are not held on our machines and they do not leave with us.
- Revocable without breakage. Removing our user accounts stops us working on it. It does not stop the automation running, because the automation does not authenticate as us.
That last point is the one to check with any firm. If revoking a contractor's access breaks production, the build was wired through their identity, and you have a dependency you did not agree to. See what happens if we stop working together.
Regulated data: what changes
If you handle health, card or certain financial data, the constraint arrives before the design, not after.
Health data
Every component that touches protected health information needs a business associate agreement. That requirement rules out several mainstream automation platforms and AI providers at their standard tiers, and establishing a compliant stack is part of scoping. It sometimes means self-hosting. This shapes what gets built rather than being a disclaimer added at the end. Healthcare administration goes through it properly.
Card data
The correct answer is almost always to keep card numbers out of the automation entirely. Work with tokens and references from your payment processor. An automation that never sees a card number cannot leak one, and it keeps your PCI scope where it is.
Personal data generally
The questions that matter are where it is processed, how long the platform retains execution logs, and whether you can delete a record on request across every system it reached. The third is the one that gets missed, because a deletion in the CRM does not reach a copy that an automation filed somewhere else. It is designable, but it has to be designed.
The risks that actually cause incidents
In practice, problems come from operational hygiene rather than from platforms being breached.
- Over-broad permissions. An integration granted full administrative scope because it was faster than working out the minimum. It then has far more reach than the task requires, permanently.
- Credentials tied to an individual. The connection authenticates as a person, that person leaves, and now the automation either dies or, worse, keeps running under the account of someone who no longer works for you.
- A shared login in a spreadsheet. Still the most common finding in inherited automations.
- Execution logs nobody configured. Months of payloads retained by default, including fields the workflow only passed through.
- Test data that was real. A build tested against a copy of production, left in a staging account, forgotten.
None of these is exotic and all of them are avoidable at build time. They are also exactly what a takeover assessment looks for in automations built by somebody else, and that assessment is free.
What to ask any firm you are considering
- "Whose accounts will this run in?" If the answer is theirs, understand what happens when you leave.
- "If I revoke your access tomorrow, does anything stop working?" The answer should be no.
- "Which third parties will see our data, and at which tier?" They should be able to name each one without checking.
- "What is the execution log retention set to, and why that number?" A firm that has not thought about it will not have an answer.
- "What permissions do you need, and what is the minimum that would work?" A gap between the two is worth discussing.
Want this checked against what you already have?
The takeover assessment inventories existing automations, maps what each one touches and which credentials it uses, and tells you what is fragile. It is free, and the documentation is yours to keep.
You will talk to Fayez or Kareem. Nobody else.