Secure client data automation for consultants is a custodian count problem, not an encryption problem.

It means three things, in order. First, the data path: every byte of client information your automation handles either stays inside the tool that already holds it (Gmail, your CRM, QuickBooks) or it gets copied somewhere else. Second, the custodians: how many separate parties end up holding a copy of the same client conversation, and which ones you signed an NDA with. Third, the audit trail: when something goes wrong six months from now, can you tell exactly what was written, where, and when. Most security pages on this topic only cover the first item (encryption in transit) and skip the other two. The custodian count is where consultants actually take risk.

Because the cloud tool is a separate company, with a separate database, a separate retention policy, and a separate breach surface. When you connect Zapier to Gmail, Zapier reads your inbox via OAuth and stores the message body, attachments, and metadata in their own database (their own SOC 2 auditor, their own data residency, their own subprocessor list). The same thing happens with Make, with hosted n8n, and with HoneyBook when you import a contact. Your tools (Gmail, HubSpot) are one custodian. The automation platform is a second one. If the second one is breached, your client data is in the breach; the fact that Gmail was not breached does not help.

It is different. Clone reads your Gmail thread or your Zoom transcript on your machine, decides what to do (draft a follow-up, log a note in HubSpot, send an invoice), and executes those actions using the same OAuth tokens you would use yourself. The thread body, the transcript, the action plan, and the audit log all live on disk under your home directory. The only network traffic is to the apps you would have hit anyway (Gmail, HubSpot, QuickBooks). Clone does not store a copy of the email thread on a remote server. There is no Clone-side database that holds your client data. That is what the local-first claim means in concrete terms.

Two directories under your home folder. ~/.clone/memory/ holds plain-text handler files: post-call.md, invoice.md, dunning.md, onboarding.md, weekly-report.md, monthly-bookkeeping.md, quarterly-pipeline.md. Each one declares its trigger event, the target apps, and the action steps. ~/.clone/log/<date>.json is the action log: one JSON entry per action Clone took, with the timestamp, handler name, target app, action, the activity id stamped by the target service, and a rollback pointer. You can read both directories in TextEdit. You can grep them with the same tools you already use. You can delete them and start over.

By default Clone uses a hosted LLM for planning, and the planning prompt does include the relevant context (the email body Clone is responding to, the call transcript snippet, the CRM record being updated). For consultants whose engagements forbid that, Clone supports connecting a local or private LLM, so model inference runs on your machine or inside your private cloud. This is the design principle from src/components/architecture.tsx: “your data stays local” is a configurable boundary, not a marketing claim. If you have a llama.cpp or Ollama instance running on your laptop, point Clone at it and the model layer is on-device too.

Most of the questionnaire fields collapse from “we rely on subprocessor X with their own SOC 2 report” to “the data does not leave the consultant’s machine.” Subprocessor list: empty (or just the apps the consultant already discloses). Data residency: wherever the consultant’s laptop is. Data retention: whatever the consultant configures on disk. Breach notification: governed by the consultant’s own policy, not a vendor’s. Two questionnaire fields remain: the planning-LLM provider (configurable, can be set to local) and the OS-level access Clone needs (accessibility APIs and browser control on the consultant’s own machine, audited via the on-disk log). For most boutique-firm engagements those two answers are easier to defend than the long subprocessor lists a Zapier or HoneyBook deployment generates.

Each action written to ~/.clone/log/<date>.json has the activity id stamped by the target service (the HubSpot engagement id, the Gmail draft id, the Stripe invoice id). When a client asks “who updated my pipeline note at 2:14pm yesterday?” you grep the log for the timestamp and you have: which handler ran, which trigger fired it, what fields were touched, what record id the change carries. That is more granularity than most cloud automation platforms surface in their UI, and it lives on your laptop, not behind their support portal.

Use full-disk encryption (FileVault on Mac, BitLocker on Windows). With FileVault on, a stolen laptop is a brick to anyone without your password, and ~/.clone/ inherits the same protection as the rest of your home folder. The threat model improvement is real: a stolen laptop is one device, recoverable through Find My, with a known custodian (you). A breach of a cloud automation vendor is many devices, often discovered months later, governed by their disclosure timeline. Disk encryption + a recent backup is a stronger posture than “trust the vendor” for most boutique consulting engagements.

Yes. Every entry in the audit log carries a rollback pointer: for a Gmail draft, delete_draft with the draft id; for a HubSpot engagement, delete_engagement with the engagement id; for a Stripe invoice, void_invoice with the invoice id. One click in the review surface reverts a single action. You can also revert an entire morning’s worth of actions in one pass by selecting a time range. The architectural commitment is: every action Clone takes is logged and reversible. The reversibility comes from those rollback pointers, written at the moment the action is taken.

Three knobs cover most of those. First, configure the planning LLM to a local model so prompt content stays on your machine. Second, exclude specific clients with a tag in ~/.clone/memory/policy.md so handlers skip threads, calls, or records flagged sensitive. Third, run Clone with no log retention beyond the current day if your engagement requires it (the log file is just a JSON file under your home directory, you can rotate it on cron). That is enough to satisfy most engagement-specific data-handling clauses without giving up automation on the rest of the book.