How to be more secure with Copilot: an SMB owner's checklist

Most of the security conversations we have with SMB leaders about Copilot start in the wrong place. They start with the tool. 'Is Copilot secure?'. 'Does it train on our data?'. 'Could a competitor see our files?'. The answers are reassuring (yes, no, no), but they miss the real point. Copilot is almost always more secure than the spreadsheet of passwords, the over-shared SharePoint site, and the personal Gmail forwarding rule that already live inside your tenant. The risk is not the AI. The risk is that the AI makes existing problems visible.

Copilot does not invent new permissions. It inherits the ones you already have. If a salesperson can already open the finance folder because somebody shared it with 'everyone in the company' three years ago, Copilot will happily summarise its contents. If a junior employee has been added to a Teams site they should not be in, Copilot will surface what is there. The good news is that fixing this is normal IT hygiene, not a special AI project. The better news is that the same fixes make the business more secure regardless of whether anyone ever uses Copilot.

Start with the over-sharing problem

The single highest-impact security action for an SMB rolling out Copilot is a 'who can see what' audit of SharePoint and OneDrive. Run the SharePoint Advanced Management reports, or just have someone spend a day clicking through the top 20 sites. You are looking for three things: sites shared with 'Everyone except external users', folders shared with anonymous links that should have expired, and personal OneDrives being used as de facto team libraries.

Tighten the obvious ones. Add expiry dates to sharing links by default. Move anything genuinely sensitive (payroll, contracts, board papers, M&A) into a dedicated site with a small named membership. Eighty percent of the Copilot data risk in a typical SMB lives in the gap between 'who should see this' and 'who can see this'. Close that gap and most of the worry goes away.

Use sensitivity labels for the small set of things that really matter

Sensitivity labels in Microsoft Purview are the lever most SMBs ignore and then wish they had used. You do not need a 40-label taxonomy. Three or four labels is enough: Public, Internal, Confidential, Highly Confidential. Apply them to the categories where leakage would genuinely hurt, not to every document in the business.

Labels do real work. They can stop Copilot from including a Highly Confidential document in a generated summary, prevent external sharing of Confidential files, and watermark anything that leaves the tenant. They also give you an audit trail. Spend a day setting up three labels and auto-labelling rules for obvious patterns (anything in the Finance site, anything containing 'commercial in confidence', anything in the HR Personnel folder), and you have closed off most of the realistic worst cases.

Lock down the agents and the connectors

If your team is starting to use Copilot Studio or Copilot agents, the security conversation shifts slightly. Agents inherit the permissions of the user calling them, which is good. They also use connectors to talk to other systems, which is where most of the new risk sits. A poorly configured connector that pulls data from a CRM, or a custom agent that calls an external API with embedded credentials, is the modern equivalent of an unmanaged macro.

The fix is governance, not paranoia. Restrict who can publish agents. Keep a register of approved connectors. Require a named owner for every published agent. Review the agent inventory quarterly and retire anything that nobody is using. This is the same discipline you would (or should) apply to Power Automate flows. It is not a big programme. It is a 30-minute meeting once a quarter with whoever owns IT.

Train people on the two prompts that cause incidents

Almost every Copilot security incident we have heard about in an SMB traces back to one of two user behaviours. The first is pasting sensitive content into a public AI tool (ChatGPT, Gemini, Claude) instead of using the secured Microsoft 365 Copilot inside the tenant. The second is asking Copilot to email a summary of something to an external recipient who should not have had it.

Both are addressed with a 20-minute briefing, not a security platform. Tell the team: if it is about a customer, a deal, a person, or a number, use Copilot inside the tenant, never a public chatbot. And before you hit send on anything Copilot drafted, look at the To line. That is roughly the entire user-side AI security programme an SMB needs in year one.

Turn on the audit logs and actually look at them

Microsoft 365 keeps a detailed audit log of Copilot interactions. Most SMBs never look at it. You do not need to read it daily. You do need to know how to query it when something feels off. Spend an hour setting up two or three saved queries: 'Copilot interactions referencing the Finance site', 'agents created or modified this month', 'external sharing events on Confidential-labelled files'. Knowing you could look, and occasionally doing it, is most of the deterrent value.

Write the policy in one page, not forty

The acceptable-use policy that actually changes behaviour in an SMB is one page long. It says what tools are approved, what data must never leave the tenant, what to do if you think you have made a mistake, and who to ask if you are not sure. Forty-page policies get filed and ignored. One-page policies get read.

The honest summary

Copilot is a competent, well-engineered tool with a strong security model. The risk in deploying it inside an SMB almost never comes from the AI itself. It comes from the unaddressed sharing sprawl, the missing labels, the unmanaged agents, and the small handful of user behaviours nobody has talked about. Fix those four things and you will be more secure with Copilot than you were without it. Skip them and the AI will quietly, efficiently, and entirely legitimately surface every problem your file estate has been hiding for years.