How should a small business control who can connect AI tools to email, files and CRM data?

9 October 2026

Start with a simple rule: nobody approves their own AI connection

The practical answer is to treat an AI connection like giving a new contractor a key to your office. The person who wants the tool should explain the job it will do, but somebody else should approve the access. In a business with fewer than 20 people, that approver might be the owner, operations lead or data protection contact. In a slightly larger firm, use a two-person check involving the system owner and whoever is responsible for data protection or security.

Record five things before approving anything: the tool and supplier, the named business owner, the exact data it can reach, the actions it can take, and the date access will be reviewed. A spreadsheet is adequate at first. It should list connections such as Microsoft 365 Copilot reading a defined SharePoint site, an AI note taker joining selected meetings, or a CRM assistant drafting but not sending follow-up emails. If nobody will own the entry and review it, do not connect the tool.

This is more urgent than many owners realise. The National Cyber Security Centre reported in September 2026 that one study found 71% of employees had used AI tools not approved by their employer. The NCSC calls this shadow AI and warns that it can expose sensitive information, reduce visibility over where data is stored and give attackers new routes into business systems. Its advice is not to ban AI. It is to understand what staff need and provide secure alternatives. Read the NCSC guidance on shadow AI.

Your first control is therefore organisational, not technical: staff must know which tools are approved, who can approve a new connection and where to ask. A blanket ban often drives use underground. A response within two working days, with a safe route to trial useful tools, gives people a reason to follow the process.

What permissions should an AI tool actually receive?

Grant the minimum access required for the smallest useful version of the task. This is the principle of least privilege. If an assistant only needs to summarise messages sent to [email protected], do not give it access to every director's mailbox. If it needs product documentation, point it to one approved folder rather than the whole company drive. If it drafts CRM notes, do not also let it export the entire contact database or delete records.

Use a permission ladder. Level one is manually pasting non-sensitive text into an approved tool. Level two is read-only access to a specific folder, mailbox or CRM view. Level three allows creating drafts or suggested updates that a person must approve. Level four allows automatic changes, sending messages or triggering workflows. Level five covers administrator access, financial actions, bulk exports or changes to security settings. Most early small-business use cases should stay at levels one to three. Levels four and five need documented testing, monitoring, a rollback method and explicit senior approval.

The NCSC's identity and access management guidance says policies should define who gets access to which systems, data or functions, why they need it and under what circumstances. It also recommends multi-factor authentication, separate privileged accounts, regular reviews and a joiners, movers and leavers process. Those controls apply to AI integrations as much as they apply to human users.

Prefer connections created through a managed business account using OAuth or the supplier's official integration. Avoid shared passwords, personal accounts and copied API keys. Check the permission screen line by line. Words such as manage, modify, delete, send, offline access or access all files deserve scrutiny. If the supplier bundles broad permissions and will not explain why they are needed, choose a narrower integration or a different supplier.

How should you assess the data and the supplier?

Permissions tell you what the tool can reach. You must also understand what happens to the data after it is reached. Ask whether prompts, files and outputs are retained, where they are stored, whether they are used to train models, which subprocessors receive them and how quickly they are deleted after the contract ends. A supplier saying that it is GDPR compliant is not a complete answer.

Classify your information into three practical groups. Green data is public or low sensitivity, such as published web copy and generic templates. Amber data includes ordinary internal documents, routine commercial information and customer details needed for a defined process. Red data includes passwords, payment details, health information, legal privilege, employee records, confidential acquisition plans and large exports of personal data. Green can be used in approved tools under normal controls. Amber needs a clear purpose, limited access and a checked supplier agreement. Red should be blocked by default and approved only after specialist review.

Under UK data protection law, your business remains accountable when a supplier processes personal data on your behalf. The ICO's guidance on AI and data protection highlights accountability, governance, lawfulness, transparency, accuracy and fairness across the AI lifecycle. The guidance is under review following the Data (Use and Access) Act, so check current ICO material when a project handles personal data or automated decisions.

Do not confuse a famous brand with a safe configuration. Microsoft, Google, Salesforce and HubSpot provide mature business controls, but an administrator can still approve an over-permissioned app or expose the wrong workspace. Conversely, a smaller supplier may be suitable if it offers a clear data-processing agreement, UK or appropriate international hosting, short retention, strong access controls, audit logs and a credible deletion process. Judge the service, contract and configuration together.

What technical controls are proportionate for a small business?

You do not need an enterprise security department to establish a strong baseline. Require business-owned accounts, multi-factor authentication and single sign-on where your systems support it. Disable the ability for ordinary users to approve third-party applications without review. Create dedicated service accounts for important automations rather than tying them to an employee who may leave. Never give an AI tool a global administrator account for convenience.

Separate reading from acting. An AI service that analyses a CRM should use a read-only role. If it needs to propose updates, write them to a review queue or staging field. A human can approve changes until accuracy and failure handling have been demonstrated. Email assistants should draft before they send. File assistants should use a dedicated knowledge folder rather than inherit the permissions of a director's entire drive. For agentic tools, restrict which tools they can call, how many records they can process and which hours they can operate.

The NCSC's May 2026 guidance on careful adoption of agentic AI says organisations should start with tightly bounded, low-risk pilots. It recommends least privilege, limited scope, short-lived credentials, monitoring, threat modelling and incident planning. Its clearest test is useful for every owner: if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment.

These basics matter in a wider threat environment. The UK Government's Cyber Security Breaches Survey 2025 found that 43% of businesses had identified a breach or attack in the previous 12 months, equivalent to about 612,000 businesses. Only 40% of businesses used two-factor authentication and 30% used user monitoring. The official survey also found restricted administrator rights at 68%. Connecting more tools without improving those controls increases exposure unnecessarily.

How do you test, monitor and remove access?

Approve a pilot with a start date, end date and success measure. Use test records or a restricted live sample first. For a CRM assistant, that might mean 50 low-risk contacts and draft-only updates for four weeks. For an email tool, use one shared mailbox and prevent automatic sending. For a file assistant, expose a curated folder containing approved documents and planted test information that should not appear outside the intended workflow.

Test normal work and failure. What happens when a prompt contains malicious instructions, a customer attaches the wrong document, an employee asks for information they should not see, the supplier is unavailable or the AI produces a confident but incorrect action? Confirm that a person can stop the workflow, revoke its token and restore changed records. Keep an audit trail showing which user or service account read or changed what. Logs that nobody reviews are not a control, so assign a named reviewer.

Review connections after 30 days, then at least quarterly. Check whether the tool is still used, permissions have expanded, the supplier's terms have changed, unusual access appears in logs, the business owner has changed role, or the promised benefit has materialised. Revoke unused connections. Include AI tools in the normal leaver process so a departing employee's personal integration does not remain attached to company data.

Set three incident triggers that staff can recognise: data was sent to the wrong tool, an AI service took an unexpected action, or an unknown connection appears in an account. The immediate response is to pause the integration, preserve logs, change or revoke credentials, assess affected data and escalate to the accountable owner. If personal data may have been breached, assess whether the incident must be reported to the ICO within 72 hours. Do not hide mistakes. Fast reporting limits harm and makes your control process better.

A practical approval checklist you can use this week

Use a ten-point check before anyone selects Allow on an AI integration: name the business problem; identify the accountable owner; list the exact data involved; classify that data as green, amber or red; list requested permissions; reduce them to the minimum; review supplier retention, training and subprocessors; test with a narrow scope; enable logs and an off switch; and set a review date. A no answer does not always mean reject. It may mean reduce the scope or choose a safer design.

For example, suppose a sales manager wants an AI tool to read every mailbox and update every CRM record so it can produce follow-up emails. The safe first version is smaller: connect one shared sales mailbox, expose only open opportunities, let the tool produce drafts, require the account owner to approve each update, and review the results after 30 days. If it saves five hours a week with no material errors, expand one permission at a time. If it creates rework or accesses unrelated messages, stop it.

Budget realistically. For a very small firm, configuring existing Microsoft 365, Google Workspace or CRM controls may take half a day to two days of competent support, plus internal time to document the register and brief staff. A broader review across several systems may take three to ten days, especially if accounts are shared or permissions are already messy. The software licence is often the cheapest part. Ownership, configuration, testing and staff habits determine whether the connection is safe.

The final rule is simple: access should follow the task, not the ambition of the product demo. Give an AI tool the smallest view and the weakest action rights that still produce measurable value. Make expansion something the tool earns through evidence. That lets a small business use AI quickly without treating its inbox, files and customer database as one unrestricted experiment.

Is This Right For You?

This approach is right for a UK small business that wants staff to use AI productively but has no dedicated security team. It works particularly well when people already use Microsoft 365, Google Workspace, HubSpot, Salesforce, GoHighLevel or another cloud CRM and are beginning to test assistants, meeting tools or AI agents.

It is not enough for highly regulated, safety-critical or large enterprise environments. Financial services, healthcare, legal services and organisations processing high volumes of special category data may need a formal data protection impact assessment, specialist security testing, procurement controls and legal advice. It is also not right for a business looking for a one-page policy while continuing to share administrator passwords or letting every employee approve third-party apps. Fix identity, account ownership and basic cyber hygiene first.

If you want an independent view of one proposed connection, start with a narrow access review. Map the data, permissions, actions and failure modes before buying a wider implementation. No pitch and no pressure, just a clear decision about whether the connection is proportionate.

Frequently Asked Questions

Should staff be allowed to connect AI tools using their work email address?

Only for approved services. Where possible, block ordinary users from granting third-party access and use an administrator approval process. A work email address can create a company-linked account even when no integration is visible, so include account creation in your policy.

Is read-only AI access safe?

It is safer than write access, but it is not risk-free. A read-only connection may still copy, retain, summarise or expose sensitive information. Limit the records it can read, check retention and model-training terms, and monitor use.

Can we let an AI assistant send emails automatically?

Not as the first step. Begin with draft-only access and human approval. Automatic sending may become reasonable for narrow, low-risk messages such as appointment reminders, with templates, recipient checks, volume limits, logs and an immediate stop control.

Who should approve AI connections if we have no IT manager?

Use the business owner or operations lead plus the owner of the affected system. For personal data, involve whoever handles data protection. Use external IT or data protection advice for high-risk access, but keep accountability inside the business.

How often should AI permissions be reviewed?

Review a new connection after about 30 days and all active connections at least quarterly. Review sooner after a role change, supplier update, security incident or material expansion in the data or actions involved.

Do we need a data protection impact assessment?

You may need one when processing is likely to create a high risk to people's rights, particularly with sensitive data, systematic monitoring, profiling or automated decisions. Use the ICO's screening guidance and seek specialist advice where the answer is unclear.

What should we do about AI tools staff have already connected?

Do not begin with blame. Ask staff to declare tools and business uses, inventory permissions, pause high-risk connections, preserve useful workflows and replace unsafe services with approved options. Revoke abandoned tokens and document the connections that remain.