How to secure AI workloads and agents

The inventory is the start, not the answer. Record per AI workload who owns it, which data sources it touches, which identities it runs as, which tools it may call, where it logs and who gets called during an incident. Do that before the workload reaches production, not after.

The three Zero Trust principles hold without change, but what they mean shifts. Verifying explicitly now also covers an agent acting on someone's behalf. Least privilege covers the tools an agent is allowed to call. And assuming breach means this: assume that at some point a model receives an instruction that did not come from you.

Four things go wrong here in practice, and they reinforce each other:

• No registry. Without central registration, shadow agents proliferate just as fast as shadow SaaS, and nobody knows how many there are. Agent 365 is the layer that observes, governs and secures agents.
• No owner. An agent without a sponsor keeps running after the project ends and the risk sits with nobody.
• No least privilege. An agent with broad permissions increases the blast radius of every incident it is involved in. Entra, Conditional Access and agent lifecycle controls are the knobs here.
• No view of tool use. An authorised tool can be abused too; the question is not whether the agent may call it but whether this pattern of calls makes sense. That is what runtime detection is for.

The order is the point. Classify and label with Microsoft Purview, turn on DLP and make sure lineage is right, and only then set up the grounding. The other way round does not work: a label applied afterwards changes nothing about the answers already given.

For Microsoft 365 Copilot the SharePoint and OneDrive legacy comes on top of that. Copilot sees what the user may see, so every item shared too widely is an answer waiting for the right question. Oversharing is not created by AI, but it is made visible by it, and then at AI speed.

For registered models in Azure Machine Learning there is AI model security, and you enable it where it is available. Without model scanning an unsafe model simply reaches production, and from then on data security is only guarding the damage.

Prompt injection is the attack most often misunderstood. It is not phishing where a human does something wrong; it is an instruction arriving through a channel the model reads and the user does not. Email is the most underestimated channel here: if an assistant reads mail, every inbound message is a possible instruction. Defender for Office 365 has detection for that, and you enable it the moment AI reads along in the mail flow.

Also look explicitly at which AI endpoints are reachable from outside. Every externally reachable endpoint widens the attack path; authentication and least privilege come before every other control there.

That cuts both ways. Capturing without governance is itself a risk: you create a new collection of personal data with no owner, no retention period and no role restriction. So enable suspicious prompt evidence only once you have worked through the privacy and compliance consequences and restricted the roles allowed to read it.

Record three things per capability before you sign off a design: the release state, the licence it requires and the clouds it exists in. Do that as a table attached to the design and not as a footnote in a deck, because it is exactly the information that has to be rechecked six months later.