AI is everywhere in the Microsoft stack now. Copilot for Microsoft 365, Copilot Chat, Azure OpenAI, Fabric, Security Copilot, custom agents built in Azure AI Foundry.

Pick almost any client, and at least one of these is either live or “under evaluation.” In my experience, “under evaluation” usually means someone in finance has been using it for three months already, and nobody in IT knows.

Here’s the bit nobody wants to hear: AI doesn’t introduce a brand-new category of security problem. It shines a very bright light on the mess that was already there.

Identity, permissions, data governance. If your tenant was leaky before Copilot arrived, Copilot will find the leak for you. Faster and more thoroughly than any auditor ever could.

So “securing AI” isn’t really a separate project. It’s getting the tenant right first, then switching AI on. Do it the other way round, and you’re just automating your existing problems, at speed.

What you’re actually worried about

Strip away the marketing language and the concerns are pretty consistent across every client I’ve worked with:

• Oversharing of sensitive information
• Confidential data turning up somewhere it shouldn’t
• Unauthorised access surfaced through AI-generated answers
• Data leaking out through prompts and outputs
• Shadow AI — people using tools nobody signed off on
• Prompt injection
• Data poisoning
• Excessive permissions sitting quietly in Microsoft 365
• Unmanaged AI apps connecting to corporate data
• Regulatory exposure

Nine times out of ten, when I go digging, it’s the same story. Copilot didn’t create a new vulnerability. It just surfaced a permissions problem that’s been sitting there for years.

If someone has access to a SharePoint site, a Teams channel or a OneDrive folder, Copilot can potentially pull that content into an answer. It’s not being clever or malicious. It’s just doing exactly what it was given permission to do.

Which gets you to the one line worth remembering out of this whole post:

AI can only protect data as well as the permissions protecting that data already do.

Everything else is detail.

Build the foundation before you flip the switch

Before any AI service goes near production data, get the basics solid.

Identity first. It’s still the primary boundary, AI or not. Conditional Access, MFA everywhere, phishing-resistant MFA for admins, Privileged Identity Management, Identity Protection risk policies, Continuous Access Evaluation.

None of this is new advice. It’s the same list I’ve been giving clients for years. AI just raises the stakes if you get it wrong.

Concretely: MFA for every user. Preferably phishing-resistant MFA where possible. Legacy authentication blocked outright. Device compliance enforced. Access from risky locations restricted.

Skip this step, and AI just becomes another door for an attacker to walk through with a stolen password.

Data protection is the control that actually matters most. Microsoft’s AI services respect the permissions and labels you already have in place. Which is good news, but only if those permissions and labels are worth respecting.

Get Purview Information Protection properly configured — Public, Internal, Confidential, Highly Confidential — and make the labels do something, not just sit there as metadata. Encrypt content, restrict sharing, apply markings, block downloads where it matters, control external access.

Before you switch anything on, use Purview Data Map and Data Classification to find out where your personal data, financial records, IP, source code and customer data actually live. You cannot protect what you haven’t located.

And tidy up your data lifecycle while you’re at it. Retention labels, retention policies, records management, deletion schedules. Less stale data lying around means less for AI to accidentally expose.

This is unglamorous work, and it’s exactly the kind of thing that gets deprioritised until it causes an incident.

Securing Microsoft 365 Copilot specifically

Copilot is usually the first AI service through the door. Because it reads organisational content directly, permissions become the whole ballgame.

Run a proper permission assessment before deployment: SharePoint permissions, OneDrive sharing, Teams memberships, Microsoft 365 Groups, external sharing settings.

I have never once done this exercise for a client and come away empty-handed. There’s always an “Everyone” permission somewhere. An overshared library nobody remembers creating. Guest access granted for a project that ended two years ago. A Teams membership list that’s basically a company history lesson.

Fix these before Copilot goes live, not after.

Target SharePoint oversharing specifically—anonymous links, “Anyone” links, legacy sharing settings, broad access groups. SharePoint Advanced Management, Purview and Access Reviews will all help you find the excessive access. Use them together rather than relying on one.

Then configure Copilot itself through the Microsoft 365 Admin Centre, Purview and Entra ID: control which groups get Copilot, monitor usage, apply DLP policies, and restrict plugins and connectors where you need to.

On connectors specifically, treat every one as a new data source, because that’s exactly what it is. Check the permissions, who owns the underlying data, the access scope and the sensitivity of what’s exposed.

Only turn on connectors you’ve actually assessed. “We’ll review it later” is how shadow data sources happen.

Purview as the backbone of AI governance

If there’s one platform I’d tell you to invest in properly, it’s Purview. It sits underneath almost every other control in this post.

Set up DLP policies for financial data, personal information, healthcare records, IP and source code. Apply them across Microsoft 365, Teams, SharePoint, Exchange, and Copilot interactions. This is what stops sensitive information from leaking out through an AI conversation rather than an email.

Use Insider Risk Management to watch for the patterns AI can accelerate — data exfiltration, unusual access, mass downloads, access to sensitive files. AI doesn’t create insider risk, but it can make an insider a lot faster.

And use Communication Compliance to monitor prompt content, user interactions, and policy violations. This matters more the more regulated your industry is. I’d treat it as close to mandatory in financial services or healthcare.

Locking down Azure OpenAI

Plenty of organisations are building custom AI applications on Azure OpenAI. That’s a different conversation to Copilot, because you’re now responsible for the architecture, not just the configuration.

Network security first: Private Endpoints, Azure Virtual Networks, Network Security Groups, Azure Firewall. Avoid public exposure wherever possible.

The pattern I want to see is:

Users → Application → Private Endpoint → Azure OpenAI

Not:

Users → Internet → Azure OpenAI

That second pattern still turns up more often than it should.

For authentication and authorisation, use Managed Identities, Entra ID authentication and RBAC. Shared keys, hardcoded credentials and overly generous permissions have no place here. And yes, I still find hardcoded keys in application code more often than I’d like to admit.

Handle prompts properly: input validation, output filtering, prompt inspection, content filtering. This is your main defence against prompt injection.

Turn on Azure AI Content Safety to catch harmful content, malicious prompts, offensive language and unsafe outputs. For anything customer-facing, I’d consider this non-negotiable.

Prompt injection deserves its own section

Prompt injection is the AI-specific threat that keeps coming up in client conversations, and for good reason. It’s genuinely new, genuinely tricky, and genuinely underestimated.

It looks like this: “Ignore previous instructions.” “Reveal confidential information.” “Access hidden data.” Simple wording, sometimes buried inside a document the AI is asked to summarise rather than typed directly by a user.

Mitigating it takes layers: strong system prompts, content filtering, retrieval validation, clear data access boundaries, and human approval for anything consequential.

The rule I give every client is simple. Never assume an instruction generated by AI is trustworthy just because it came from AI. Validate before you act, every time.

Zero Trust applies to AI too

Microsoft has been banging the Zero Trust drum for years, and the same three principles hold up for AI without needing much translation.

Verify explicitly — user identity, device health, location, risk signals, every time. Use least privilege — RBAC, PIM, Just-in-Time access, regular Access Reviews. Assume breach — monitor AI interactions, user behaviour, data access patterns and application activity as if something has already gone wrong, because eventually it will.

Treat AI workloads as an attack surface, not as a trusted internal tool. That mental shift alone changes how a lot of these deployments get designed.

Actually watching what’s happening

None of the above matters if you can’t see it happening.

Defender XDR gives you visibility over user activity, identity threats, endpoint risks and cloud application access.

Defender for Cloud Apps is where you’ll find shadow AI, and I mean that literally. Every single engagement I’ve run this discovery exercise on has turned up employees using public AI tools nobody in IT knew about. It’s never zero.

Feed AI logs into Microsoft Sentinel and monitor prompt activity, access events, authentication anomalies and data access behaviour. Set alerts for large-scale data access, unusual prompt activity, high-risk sign-ins and sensitive data exposure.

If you’re not alerting on these, you’re relying on hope as a strategy.

Governance is not optional paperwork

Technical controls only get you so far. You need an actual governance framework sitting alongside them.

Write an Acceptable Use Policy that says plainly which AI tools are approved, which use cases are off-limits, what the data handling rules are, and what’s expected of users.

Run risk assessments — data sensitivity, regulatory obligations, business impact, security requirements — before a solution goes live, not as a retrospective exercise.

The more mature organisations I work with have stood up an AI review board to look at new AI projects, risk assessments, data access requests and compliance questions before they get approved. It sounds bureaucratic. It saves an enormous amount of pain later.

Don’t forget Security Copilot itself

It’s easy to focus entirely on the AI tools users touch and forget that Security Copilot needs governing too.

RBAC permissions, least privilege, audit logging and data access controls all apply here just as much as anywhere else. Keep an eye on prompt usage, generated outputs and analyst activity, and make sure Security Copilot is bolted into your existing security processes rather than left running as its own island.

A sensible order to do all this in

If you’re starting from scratch, this is roughly the sequence I’d follow:

1. Secure identities with Entra ID and MFA.
2. Implement Conditional Access policies.
3. Classify and label sensitive data.
4. Review SharePoint and Teams permissions.
5. Implement DLP policies.
6. Deploy Defender for Cloud Apps.
7. Enable monitoring through Defender XDR and Sentinel.
8. Pilot AI services with a limited group of users.
9. Expand based on what the pilot and your governance process actually tell you.

Follow that order, and you dramatically cut the chances of AI exposing risks you didn’t know about.

My Final thoughts

Securing AI in a Microsoft tenant comes down to securing identities, data and access. The same fundamentals that were true before Copilot existed.

Yes, AI brings genuinely new threats like prompt injection and model abuse. But in practice, the biggest risks I see are still poor permissions, overshared content and weak governance. The AI just makes them visible faster.

If you’ve already invested properly in Entra, Purview, Defender XDR, Sentinel and a Zero Trust approach, you’re in a good position for AI adoption. The hard part was never really “turn on Copilot” or “stand up Azure OpenAI.” It’s making sure the tenant underneath is ready for a world where AI is becoming the main way people interact with corporate information.

The organisations that get this right are the ones treating AI as part of their existing security architecture, not as a bolt-on. Same rigour, same governance, same monitoring you already apply to identities, endpoints and data. Just extended to cover the newest thing sitting on top of them.