How Do You Give AI Access To Your Business Without Losing Control Of It?

Security is the number one thing stopping builders from going further with AI.

When we asked the builders in APB's Elite Mentoring cohort what was holding them back at our first AI Mastermind, several had already given their coach the same answer before the session started.

It's a fair worry, and a lot of AI commentary makes it worse by getting you excited about what's possible and then finishing on a warning about how dangerous it all is.

APB runs AI agents across its own accounts, CRM and project management every day. An agent is an AI tool plugged directly into one of your systems so it can read and change records, and what makes that safe is controlling exactly what each one can reach.

How Much Access Should You Give An AI Tool?

An AI tool can only affect what you've given it access to, which turns security into a list you control. At APB that list has three levels of access, and no system skips a level.

Read-only is where every system starts. The agent can look at your accounts, your CRM and your project management software but can't change anything, and it stays at that level until you trust what it gives back.

Read-and-write is the level most building companies will need, because it's where an agent can update a record for you. Before you grant it, set your systems up so every change an agent makes leaves an audit note on the record, showing what changed and why.

Delete comes last, and plenty of companies never grant it. A wrong delete means rebuilding whatever was lost, and what you get in return is a bit of time saved.

At APB, access is issued to each person and each agent separately. New users start on read-only, most of the team works at read-and-write, and delete sits with a small number of senior people who use AI every day and understand what a wrong delete costs.

How Do You Know You're Still In Control?

To check you're in control of an agent, rather than just comfortable with it, ask three questions about every system it can reach.

What did it change this week? The audit note on every record it touches answers this one.

Is anything happening that should never happen? Exception reports answer this. If an automation is meant to make A + B = C, the exception report lists every record where C doesn't match, and in a healthy system it reads zero. APB runs hundreds of them, and every new automation gets its own report built alongside it.

Can I undo it? Only if you saved a copy before the change. Every agent should take a snapshot before it changes anything.

Those three questions cover the systems an agent can reach. The people using AI need rules of their own.

Why Isn't An AI Policy Enough On Its Own?

APB's AI policy is 11 rules on one page, and everyone in the company signs it once a year. It's one page because nobody reads the second one.

A signed policy still relies on people remembering it. The rules that matter most also need to sit in the AI tool's own settings, the standing instructions it loads at the start of every conversation, so they apply whether or not anyone remembers the policy.

If you only enforce three rules, make them these.

• Approved accounts only. Nobody on your team uses a free AI account for company work, including on their own phone. What's typed into a free account can be used to train the model, which means your emails and contracts have left the business.
• Never paste a secret. An API key is the password one piece of software uses to connect to another, and it usually carries more access than a staff login. Paste one into an AI chat and it's compromised, because the conversation is recorded. 
• A person checks anything before it reaches a client. It's why APB's agents write emails as drafts for someone on the team to review and send.

Write the rules tighter than you need and loosen them as problems come up. If you haven't written company policies before, how policy works in a building company covers the basics.

Should Every AI Connection Have Its Own Key?

Yes. When you connect your first agent, it's tempting to hand it the admin key, because it's quicker and it stops the constant permission requests. The problem is that you then can't tell whether a change came from the agent, from a person, or from someone who got hold of the key.

Give each person and each agent its own key, for one tool, at one access level. When a key leaks, you switch off that one key and the rest of the business keeps running.

Keep a register as well, whatever size your company is. One sheet is enough, showing who's connected to what, at what level, and who approved it, and the day someone leaves, it's the list of what you switch off.

Where To Start

Book a 15-minute chat with our team and we'll help you work out where your business is exposed right now, and which workflow is safe to hand over first.