Shadow AI is not a future problem. It is a browser tab with your customer data pasted into it, an agent somebody built and forgot, and a model endpoint nobody is watching. We monitor all three, on the Microsoft stack you already own.
They get sold as one because it is easier to sell. They are not one, they do not share a product, and an organisation usually has all three without knowing which it has.
ChatGPT, Gemini, Copilot, and the dozen tools nobody told IT about. The risk is what goes IN: customer data, source code, a contract, an incident report.
Defender for Cloud Apps finds the tools. Purview DSPM for AI sees what is being sent to them, including to third-party sites.
Anything running on Azure OpenAI. The risk is the model itself being attacked — jailbreak attempts, prompt injection, data poisoning, credentials pulled out through a prompt.
Defender for AI Services, enabled in Defender for Cloud. Alerts land in Defender XDR alongside everything else.
Agents with their own identity and their own permissions, created faster than anyone is decommissioning them. The risk is an agent nobody owns still holding access.
Agent 365 for the registry and lifecycle, Entra for what an agent is allowed to reach, Purview and Defender for what it does with it.
A tool for each is not a service. What makes it one is somebody reading the output at three in the morning and deciding whether it matters.
Every one of these produces alerts into Sentinel and Defender XDR, where our SOC works them the same way it works everything else — triaged, investigated, and answered with a verdict rather than forwarded to you.
Nobody can govern AI use they cannot see, so the service starts by establishing what is actually happening rather than by writing a policy about what should be.
Defender for Cloud Apps and Purview are inside a lot of Microsoft agreements and switched off in most of them. The first job is establishing what your licensing already entitles you to, which is regularly more than anyone expected.
Which generative AI services are being reached from your estate, from how many accounts, and how that has been trending. No endpoint agent to deploy for this.
Purview shows what is being sent into those tools — which data, from which people, under which classification. This is the part that changes the conversation with the business.
What agents exist, who owns each one, what it can reach, and which ones are still holding permissions nobody can justify.
Which tools get sanctioned, which get blocked, which need a policy rather than a ban. Made from a picture of real usage rather than from a guess about it.
Most organisations find the honest answer is not "ban it". It is that three tools are fine, one is a problem, and nobody knew which was which.
Discovery alone produces a spreadsheet of things you now know are wrong. What changes the risk is acting on them.
Where an AI tool should not be in use, it can be blocked. Where an agent holds access it no longer needs, that access can be revoked. Where an agent is behaving in a way nobody sanctioned, it can be disabled in the registry. All of it through the Microsoft controls you already own, rather than another console.
None of it happens without your say-so unless you decide otherwise. The same autonomy dial that governs every other agent on the platform applies here: fully autonomous, held for approval, or autonomous above a confidence threshold you set. On something as disruptive as switching off a tool a department depends on, most customers start with approval and move from there.
A tool for each layer is procurement. Somebody accountable for the answer is a service.
These are Microsoft product boundaries rather than ours, and knowing them before you buy is worth more than finding them afterwards.
Most people selling AI agent governance have never had to govern one. Our own SOC runs on agents, which means every problem this page describes is one we had to solve internally before we sold it.
See the 14 agents The CYBERSHIELD AI platform MXDR for Microsoft
CYBERSHIELD AI is an agent per SOC function, each with a defined scope, its own scoped tools and an escalation path it cannot route around. Not because it makes a good diagram, but because an agent with unbounded permissions is exactly the risk this service exists to find in your estate.
The same applies to data: no cross-customer learning, no model training on customer data, no fine tuning, no embedding — enforced architecturally rather than promised in a policy. When we ask what an agent in your environment is permitted to reach and who signed that off, it is a question we have already had to answer about our own.
Governing agents is not a product we resell. It is a problem we had first.
Generative AI being used inside an organisation without IT or security knowing about it — usually staff pasting work into a consumer AI tool to get something done faster. The exposure is not the tool itself, it is what goes into it: customer data, source code, contracts, anything somebody found it quicker to paste than to summarise.
Microsoft Defender for Cloud Apps discovers which generative AI services are being reached from your estate, and Purview DSPM for AI shows what is actually being sent to them — including third-party sites such as ChatGPT and Gemini. Neither needs an agent installing on every endpoint.
If it runs on Azure OpenAI or Azure AI Model Inference, yes — Defender for AI Services detects jailbreak attempts, prompt injection, data poisoning and credential theft against it, and the alerts land in Defender XDR where our SOC works them. Models hosted elsewhere are outside what that product covers, and we will tell you that at scoping rather than afterwards.
Microsoft Agent 365 gives a central registry of the agents in your organisation, what they are doing and who owns them, with Entra governing what each one is permitted to reach and Purview watching the data they touch. The problem it solves is the agent nobody remembers creating that still holds access to something important.
Yes, through the Microsoft controls in your own tenant — blocking an application, revoking an agent’s permissions, or disabling it in the registry. Whether that happens automatically or waits for your approval is a setting you control, and on something as disruptive as removing a tool a team depends on, most customers start with approval.
Knowing, continuously, where AI touches your data and your identities — which AI tools are in use, what is being sent to them, which of your own AI workloads are exposed, and what your agents are permitted to reach. Posture is the standing picture; monitoring is watching it change and acting when it does.
It runs on the same SOC, the same Sentinel workspace and the same escalation path as everything else we monitor, so an AI alert is worked by the same analysts and lands in the same report. Whether it is in scope for your service is a question of what is licensed and switched on, which is settled at scoping.
Sometimes less than you would expect. Agent 365 is licensed per user and Defender for AI Services is billed on tokens scanned, but Defender for Cloud Apps and Purview are frequently already inside agreements organisations hold and have never switched on. Establishing what you already own is part of onboarding.
The first discovery report surprises almost everybody. A demo against your own tenant rather than a canned one, run by an analyst rather than a salesperson.
