What access should an AI assistant have in your business?

An AI assistant should have its own login, with the narrowest access that lets it do its one job, and nothing else. Most small businesses do the opposite by default, connecting the assistant to the owner's account because that is the fastest way to make it work. That single shortcut is what turns a useful tool into something you cannot audit, cannot narrow and cannot switch off cleanly.

Why is the login the real question?

Because it is the question that decides whether a project can proceed, and almost nobody asks it first.

The conversation I have most often starts with whether AI is good enough yet to do the job. That is the wrong end. The more useful question is whose login it is using while it does it, and unlike the capability question you can answer it today, without any technical knowledge.

The wider industry has reached the same conclusion from the enterprise direction. Security guidance through 2026 has converged on treating AI agents as identifiable entities inside your identity system rather than anonymous automation running on shared credentials, with a dedicated identity per agent, a narrow list of tools it may touch, and access that expires when the task does. One 2026 analysis put the growth of AI agents operating inside enterprise environments at over 400 per cent year on year, with governance nowhere near keeping pace.

Small businesses have the same problem with fewer people to notice it.

What actually goes wrong with a shared login?

Three things, and none of them are dramatic. That is why they get missed.

You lose the audit trail. Everything the assistant does looks like you did it. If something goes out wrong, there is no way to establish afterwards whether a person or a tool produced it, which is exactly the question that matters.

You cannot narrow its reach. The assistant's access and your access are the same thing. Tightening one tightens the other, so in practice nobody tightens either.

You cannot switch it off cleanly. Turning it off means changing the credentials your business runs on, which is a job nobody wants to do on a Tuesday. So it stays connected long after anyone is actively using it.

None of that is a story about rogue AI. It is the ordinary problem of a shared login, which every business already understands, wearing new clothes. If shared logins are already a known bad idea in your business, you have already agreed with the argument.

The Handiwork test: two questions per tool

For every AI tool already running in your business, write down two things.

1. Which account does it use? 2. What can that account reach?

That is the whole audit. It takes an hour for most small businesses and it produces a list that answers most of its own questions. If the answer to the first is your login, that is your next job, ahead of whatever you were planning to add.

This pairs directly with the inventory step in AI governance that fits on one page. The inventory tells you what is running. These two questions tell you what each thing can touch. Together they are most of what a small business actually needs before anyone writes a policy.

How does this change which project to start with?

It changes the criteria, and usually for the better.

The instinct is to start with the most valuable use case. The better instinct is to start with the one where the narrowest possible access still does something worth having, because that is the project you can switch on this week without a governance conversation you are not ready for.

So when we scope a first build at Handiwork, we would rather give a client an assistant that sees one folder and does one job properly than a general-purpose one wired into everything. The first can be widened later, once you have watched it behave. The second can only be unpicked.

That is the same logic behind designing guardrails rather than relying on trust: the constraint is not a lack of confidence in the tool, it is that a bounded system is one you can reason about and an unbounded one is not.

What does narrow access look like in practice?

For a small business, usually something like this.

• Its own account, named so it is obvious what it is. Not a person's, not a generic admin.
• One data source, not all of them. One folder, one mailbox, one table. Add the second only when the first has proved itself.
• Read-only until it earns write. Most useful first projects only need to read. Sending, posting and deleting are separate decisions, and they should be made separately.
• A named owner. One human who is accountable for what it does and would notice if it stopped.
• A review date. Somewhere to catch the assistant nobody has used since March but that still has access to everything.

None of this requires software you do not already have. Microsoft 365 and Google Workspace both do accounts and permissions perfectly well; the gap is almost always a decision nobody made, not a capability nobody bought.

If you want more on the behaviour side of this rather than the access side, using AI agents safely covers the checks worth running before you let one act on its own. Our services page sets out where this fits in a roadmap.

Ready to find out where you stand?

If you want a straight look at what AI is already running in your business and what it can reach, our free AI Readiness Check covers exactly that. No cost, no pitch.