From the Map to the Hike: The Five Controls and the Client Conversations Behind Them

This is Part 2 in a series that covers your AI enablement plan. Part 1 is here if you want the full map.

The Little Agent That Could

An AI assistant had been summarizing sales documents for three weeks. Exactly what it was supposed to do. Somewhere around week two, a member of the team connected it to a broader set of SharePoint folders than the original scope required. The agent, being a diligent piece of software with no opinion about what it should and shouldn't read, said, “I infer I can. I infer I can. I infer I can,” and started pulling from everything in reach: deal terms, employment contracts, a spreadsheet with client payment details. We’re not naming names, but someone was nodding off in data classification class when they discussed the use of sensitivity labels, so nobody had labeled anything as “confidential.”

By the time the data loss alert surfaced, the agent had processed hundreds of documents it was never meant to touch, and at least some of what it read had made its way into summaries that circulated beyond the team that commissioned it. There was no audit trail to follow, no way to know who had seen what.

According to Verizon's 2026 Data Breach Investigations Report, 45% of employees now use AI on corporate devices regularly, up from 15% a year earlier, and two-thirds of them are doing it through personal accounts that bypass enterprise controls entirely. The agent in this story was the institutional version of that same problem, scaled up and automated, and the advisor who owned that client relationship had no answer when it surfaced.

Five controls. Here's what they look like in practice.

Sanctioned Access Only

The decision about which AI tools your clients' employees can use was already made. Just not by anyone on your security team. Microsoft 365's admin center controls which AI providers are available to users inside the Copilot platform, and that list includes third-party models alongside Microsoft's own, with most of them active by default in commercial tenants the moment a license is activated. Many organizations have never audited that setting, which means someone made that decision for them. Your job as a trusted advisor is to help stakeholders make a conscious choice rather than accepting an inherited default.

The policy starts with three questions: which tools are we sanctioning, for which people, and under what terms? Put the approved tools behind single sign-on and use Conditional Access to block personal AI accounts on corporate devices. That's what turns the policy into something real instead of a document. The enterprise tier matters too, because the contract terms that keep client data out of the model's training pipeline live there, not in the consumer version.

What's sanctioned and what's running are rarely the same list, which is why the policy needs an AI inventory behind it. Microsoft's Purview DSPM for AI and Defender for Cloud Apps build and maintain that inventory automatically, surfacing tools people installed in browser extensions and forgot about. Without it, the unsanctioned tools are the ones creating the exposure. IBM's 2025 Cost of a Data Breach Report found shadow AI was a factor in 20% of breaches, adding an average of $670,000 to each one, and 97% of those breaches happened at organizations without proper AI access controls. What you bring back to stakeholders is simple: here are the sanctioned tools, here's who has access, and here's the last date we checked what else is running.

Every Agent Needs a Name and an Owner

Deploying an agent should be a governed process. When an operator submits a request to spin one up, establish ownership before anything else moves forward. An agent that runs under a borrowed user login, with whatever permissions that person happened to have, connected to whatever systems they could reach, is an access control problem wearing a productivity hat. The agent in the opening story had no dedicated identity, no defined scope, and no human accountable for what it did. All three failures trace back to the same missing step.

Accountability must precede capability. Before any agent goes live, it needs its own Entra Agent ID rather than a borrowed user login, a place in a central registry alongside every other agent the organization is running, and one person whose name goes on the risk register and who is reachable when something goes wrong. Microsoft's Agent 365 finds every agent in the environment, including the ones developers spun up without telling IT, which is where the shadow AI problem usually surfaces.

Access scoping is the technical side of accountability. An agent running with full account permissions can reach everything that account can reach, which is almost always more than any single task requires. Least-privilege ensures the agent touches only what the specific workflow needs, with credentials that expire and rotate rather than sitting permanently in a store. Make it a standing requirement that no agent runs without a name, an owner, and defined permissions.

The number you report out is the percentage of agents that meet all three criteria. The ones that don't become the first item on the next agenda.

Logging: Capturing What AI Does So You Can Prove It Later

When an AI incident lands on your desk, the investigation starts with one question: what did the AI do? Without a record of every interaction, that question has no answer. Setting the standard for logging before something goes wrong is the job, and it falls to the advisor to ensure it’s happening.

The practical work involves capturing interactions through Purview Audit, eDiscovery, and Communication Compliance, setting retention policies that explicitly include AI prompts and responses, and routing everything into the SIEM rather than letting logs accumulate across separate consoles nobody opens consistently. That's the technical infrastructure. The leadership question is about why it matters: without a record of what AI systems did, incident response becomes a guessing exercise, and guessing is expensive.

Prompt injection is worth covering here too. It's an attack where hidden instructions get buried in a document, email, or web page the AI was supposed to read, and the AI follows those instructions rather than its own. Turning on Prompt Shields through Azure AI Content Safety addresses this directly. A technique called spotlighting, which separates trusted system instructions from untrusted external content before the model processes a request, drops injection success rates from over 50% to under 2% according to Microsoft Research's own study.

Reconstructing what any AI system did, at any point in time, is the baseline expectation. The number you report to stakeholders is the percentage of AI interactions making it into the SIEM. If that number is zero, the opening story of this piece is a question of when, not if.

Teaching the Detection System What a Bad Tuesday Looks Like

The agent from the opening looked like a productivity win for three weeks before anyone noticed otherwise. By then the damage was already done. Most monitoring systems weren't built with AI behavior in mind, which means anomalous activity from an agent looks identical to normal activity until something downstream goes wrong.

The Netwrix 2026 Data and Identity Security Report found that organizations where AI significantly expanded the number of identities accessing data reported a 43% breach rate over the prior year, compared to 11% at organizations where it didn't. More agents means more identities, and more identities means the monitoring question becomes increasingly urgent.

Feeding AI API traffic, Defender for Cloud Apps data, and DSPM AI activity into the existing SIEM is how you make monitoring useful. Teaching the system what anomalous AI behavior looks like specifically: bulk data pulls, API spikes, activity outside normal hours, agents calling systems they've never touched before, is what turns monitoring into detection. Automated containment through tools like Defender XDR and Sentinel means the response happens fast enough to matter when an alert fires.

The AI incident playbook is the thing many advisors haven't written yet: what are the first three moves when an AI system goes sideways? Revoke the agent's identity and tokens, block outbound traffic, run the same eradication and recovery process as any other breach, then check whether the agent's tool connections were tampered with, because that's often where the trail starts. Writing that playbook before you need it is the same discipline as any other incident response plan, and the logic behind it is identical. The number you bring back is mean time to detect an AI incident, a metric very few organizations have ever been asked to track, and the absence of it usually tells you everything you need to know.

The Five Moves to Make 

Sanction the tools, name the agents, log what AI does, and make sure the detection system knows what to look for. Each of those is a discussion before it's a control, and each one produces a metric. Clients don't build budgets around advisors who talk about intentions. They build them around advisors who show up with a scorecard and a next step.

The advisors who come through this period with stronger client relationships than they went in with aren't the ones who understood every technical detail. They're the ones who showed up consistently, owned the right things, delegated the right things, and brought a number back to the table every time.

The agent that started this piece is still out there somewhere, reading documents, summarizing content, and doing exactly what it was asked to do. Whether anyone knows what it's reading, who authorized it, or where the logs went is a different question entirely. That's the one worth answering before your next client meeting.