I had a client ask me recently, quite reasonably, about insurance. Levels, certificates, whether I carried cyber cover. I sent the numbers. But the question sent me off on a different train of thought, because insurance is what you reach for after something has gone wrong, and the thing I was actually worried about was a design flaw, not a coverage gap.

Here is the flaw, stated plainly. When a business brings in outside help for AI and automation, the helper usually ends up with broad credentials to the back of the business. API keys in a spreadsheet. A service account with more permissions than anyone remembers granting. An admin login “just to set things up”. All of it sitting on a laptop, in a cafe, on the same machine that opens email attachments.

If that laptop is compromised, the thief does not have the consultant’s data. They have yours.

The one sentence that fixes it

I wrote it down for myself in the middle of a working day and I have not found a better version since: my machines hold, at most, the credentials of one ordinary user in the client’s business, never a system credential.

Everything else follows from that. If it is true, then a compromised machine of mine exposes exactly what a compromised laptop of one of your own staff would expose, and actually less, because my user has no admin rights, has been in the business for a fortnight, and can be switched off by your IT person in a minute without asking me.

That is what I mean by making the scary question boring. “What happens if their laptop is stolen?” should have the same answer as “what happens if Sarah’s laptop is stolen?”, and the answer should already be written down in your existing security practice.

How it works in practice

A few pieces, none of them exotic.

I am provisioned like a member of staff. Your admin creates me an ordinary user in your Google Workspace or Microsoft tenant and a seat on your AI plan. Everything I do inside your business, the forms, the shared folders, the connectors, lives in your tenant, is logged there, and is revoked there.

The desk is not my computer. Development happens in a remote environment attached to a repository your organisation owns. Secrets are injected into that environment when it runs and never touch my disk. My laptop is a window onto it. Close the window and nothing remains. If I am working from a cafe, the cafe gets a view of a browser tab.

The runner is not my computer either. Scheduled automations run in your own GitHub organisation and cloud project, in a fresh container each time, with keys pulled from a secret store that nobody, including me, can read back after they are set. Between runs, the automation does not exist anywhere.

Read at the desk, write in the runner. The interactive environment where analysis happens gets read-only keys. Write keys, the ones that could move money or email a supplier, exist only inside the scheduled runner, where every outward action is written as a draft and waits for a named person to approve it.

Two switches, both yours. Remove me from the GitHub organisation and the desk, the runner and the repository are gone. Deactivate the Workspace user and the mail, the files and the AI seat are gone. Neither switch needs my cooperation. Either takes a minute.

What this costs

Nothing, really, which is the surprising part. All of the pieces above are standard features of tools a business your size already pays for or can have for the price of a couple of coffees a month. The only cost is discipline: deciding at the start that this is how it will work, and not taking the shortcut of “just give me the admin login for now” in week one. The shortcut is how every one of those spreadsheets full of keys came to exist.

There is a residual risk and I would rather state it than pretend otherwise. An open session on a compromised machine is a path to the remote desk and whatever it can read. That is exactly the risk of any employee’s open laptop, and it is mitigated the same way: two-factor authentication, sessions that expire, read-only access at the desk, and instant revocation. Where it ends is where it ends for your own staff. It is not a special consultant risk any more.

The other reason to insist on it

I have come to think this design is not only about security. It is the concrete form of a promise I make to every client, which is that nothing depends on what is in my head and everything they pay for is theirs.

If the code lives in their repository, the keys live in their accounts, the runs are logged in their database and my access is one revocable user, then the day they no longer need me is cheap. A second provider reads the documentation and carries on. Their own team, once it is confident, picks it up. That is what portable means, and it is the thing the big-firm model can never quite offer, because the big-firm model needs you to need them.

If you have outside help in your systems today, from anyone, me included, it is worth asking the boring question. What do they hold, where does it live, and which switch turns it off? If the answer takes more than a minute to give, send me what you have and I will tell you what to change first.