Microsoft Copilot Isn't a Chatbot — Most Organisations Are Securing It Like One
The top 6 mistakes organisations are making with Microsoft Copilot and the risks that comes with them in a real world environment.
Microsoft Copilot is not a chatbot. It is not another SaaS tool you enable through the admin portal and drop into your acceptable use policy.
It is an AI system with deep, privileged access to your entire Microsoft 365 environment — emails, files, chats, calendars, meetings — and most organisations are treating it like the former while running it like the latter. That gap is where the exposure lives.
I've led end-to-end security transformations for Copilot and agentic AI deployments across multiple organisations — working alongside engineers, operations, SOC teams and Microsoft leads. I've taken environments from out-of-the-box chaos to genuinely matured governance, and I've stepped into organisations where the cat was already out of the bag, brought in to help security catch up after the business had moved without them. Both experiences taught me the same lesson from different angles: the mistakes that create the most damage are rarely exotic. They are foundational, predictable, and avoidable — if security is in the room early enough.
This is what most organisations get wrong.
Mistake 1 — Enabling licenses with no boundaries
Trial licenses get switched on. Copilot licenses get assigned. Nobody segments by role, by use case, or by data sensitivity. Everyone gets the same access, the same capability, the same blast radius.
What this creates on the backend, especially in larger organisations, is chaos. And here is the part most people don't anticipate — once that chaos exists, putting boundaries in place afterward does not automatically clean it up. New rules do not retroactively apply themselves to damage already done. If oversharing has already happened, if agents have already been built against the wrong data, if access has already sprawled past where it should be, someone now has to manually review and repair what already exists before the new policy means anything in practice.
That's the trap. Organisations think enabling the controls is the fix. It's only the starting point. The cleanup is the real work, and it is rarely budgeted for because nobody planned for needing it.
Mistake 2 — Bringing security in after the fact
Here is the pattern I've seen repeated across multiple organisations: procurement approves Copilot, IT deploys it, business units run training sessions to get users comfortable, and security gets the call somewhere after all of that has already happened.
Even in organisations where user training never happened — and training matters, because it's what stops well-meaning misuse before it starts — the absence of security at the very beginning is its own problem. Security needs to be aligned to policy and standards from day one, not invited in once the business is already moving.
When security arrives late, it's a bit like trying to fix a train and lay new track while the train is already moving at full speed. The simple changes that would have taken an afternoon to implement before launch — segmentation, scoped permissions, basic guardrails on what agents can do — now have to be retrofitted onto a live system actively generating incidents for real users. What would have been prevention becomes incident response.
Mistake 3 — No DLP, no data classification, the foundation problem
This is the mistake that catches even organisations that think they've done their homework. Some have sensitivity labels. Some have DLP policies. And they still suffer significant oversharing problems, because labels and DLP rules only matter for the data they actually cover — and most organisations have years of files and resources sitting outside that scope entirely.
Copilot does not care whether your governance program has gotten around to labelling something yet. It surfaces whatever a user is technically permitted to access, labelled or not, clean or not, forgotten or not. Recent research shows over 15% of business-critical files are at risk from oversharing and inappropriate permissions — and that's before factoring in how AI changes the speed and reach of that exposure. Metomic
If the foundation of your data isn't prioritised and cleaned up first, Copilot will leverage exactly what's already broken. That doesn't just raise your everyday risk. It raises insider risk specifically, and it raises the impact rating of something as ordinary as a phishing breach — because now the blast radius of a single compromised account includes everything Copilot can retrieve and summarise on that user's behalf.
Mistake 4 — Agent sprawl and the capability nobody assessed
This is where it gets serious, and it's worth slowing down for.
I've walked into organisations where close to three thousand agents were already live in the default production environment. No governance strategy. No team with the depth of AI knowledge required to actually understand what these agents were capable of doing. What existed instead were a handful of firewall rules trying to block some third-party sites — and that's about it.
It's the equivalent of trying to hold down one tentacle of an octopus while the other seven are already eating and sharing food, completely unnoticed. The organisation feels like it has a handle on the situation because one visible thing is being managed. Meanwhile there is no real visibility into how bad the actual exposure is. And the requests keep coming — users asking for more agents, more capabilities, more access — because from where they're sitting, nothing has gone wrong yet.
This is the gap most security-as-an-afterthought conversations miss entirely. It's not just about whether Copilot itself is secured. Agent Builder, Copilot Studio, and Foundry are all separate surfaces generating separate sprawl, and most organisations don't have visibility into any of them until someone is brought in specifically to map it. 97% of organisations that experienced an AI-related breach reported a lack of proper AI access controls — which tracks exactly with what shows up on the ground. WitnessAI
Mistake 5 — The illusion of having blocked it
This is personal, because I've seen the moment organisations realise they were wrong.
Many of these same organisations believed they had shadow AI under control. They'd blocked certain URLs. They had proxy rules in place. On paper, the unauthorised AI tools were locked out.
What they hadn't accounted for is that many third-party agents embed third-party LLMs directly into their service, exchanging data on the back end while the user simply interacts with what looks like a single, approved interface on the enterprise side. The blocking rules were aimed at the front door. The actual data exchange was happening through a door nobody knew existed.
It raises an uncomfortable question worth sitting with: how many organisations have unknowingly helped train multiple external LLMs simply by allowing this kind of architecture to operate inside their walls, unexamined?
This isn't a hypothetical risk category anymore. IBM's 2025 Cost of a Data Breach Report formally introduced Shadow AI as a material breach category for the first time. The average organisation now has roughly 8.2 GB of data being uploaded to AI apps per month, spread across more than 1,550 distinct GenAI applications. And the structural risk isn't theoretical either — researchers discovered a zero-click prompt injection vulnerability in Microsoft 365 Copilot, where hidden instructions buried in an ordinary email or spreadsheet could hijack Copilot's behaviour and silently exfiltrate corporate emails to an attacker-controlled server, with no user interaction required at all. It took five months to patch after responsible disclosure. The underlying vulnerability class — AI systems processing untrusted content alongside privileged internal data — isn't going away with one patch. CurrentWare + 2
Mistake 6 — Treating static frameworks as a finish line
To be fair to the frameworks — they're trying to keep pace. ISO 42001 is a good example of the standards world moving to meet this moment. But even the best-designed framework is a baseline, not a destination, in a space that evolves this quickly.
The organisations getting this right aren't the ones with the thickest policy document. They're the ones who've invested in actually training their security teams on these tools — not just reading about them, but understanding them well enough to start anticipating where the next gap will open before it does. That mindset shift is the real unlock. Security teams that understand agentic AI deeply can foresee problems the framework hasn't caught up to yet.
From there, it becomes about building the right governance: getting stakeholder buy-in early rather than after deployment, establishing the forums and boards that give AI initiatives a repeatable review process, and making sure every new capability passes through proper proof-of-concept testing, risk tiering, documentation, and continuous monitoring before it ever reaches production at scale. The goal isn't to slow the business down. It's to make sure the business can move fast without finding out six months later what it actually exposed itself to.
Where this leaves us
None of this is an argument against deploying Copilot or embracing agentic AI. The technology is genuinely valuable, and the businesses adopting it aren't wrong to want the advantage it offers. The problem has never been the tool. It's the sequence — deploying first, training users second, and inviting security in only once something has already gone sideways.
Every mistake in this piece is fixable. Most of them are fixable _before_ deployment, for a fraction of the cost of fixing them after. That's the piece I'll be writing next — what the right approach actually looks like in practice.
If this resonated, or if you've seen any version of this play out where you work, I'd like to know. Which of these six is the one your organisation is most exposed to right now — and would you actually know if I'm right?
Stay Updated
Get the latest security insights delivered to your inbox.