The future of AI governance control

Identity is the root trust layer. Every governance control above it depends on knowing which actor is taking an action — a user, a device, or increasingly an AI agent acting on someone's behalf — from which device, and under which access policy.

For AI governance specifically, identity controls determine which users can access which AI tools, which tools can be licensed through managed procurement channels, and whether AI-driven actions can be attributed to a responsible individual or agent identity for audit purposes.

MSP delivery today: SSO enforcement, MFA, conditional access, and RBAC through Microsoft Entra and M365 are standard MSP delivery. AI content policies are driven by existing Entra ID security groups, a confirmed product requirement from MSP field interviews.

Where this is heading: identity is becoming the control plane for non-human actors too — AI agents, OAuth grants, and MCP servers — converging this layer with L5. The tooling is real (Microsoft Entra Agent ID, Conditional Access for agents, non-human-identity governance from Okta, SailPoint, and Ping), but it sits in E5, the Entra Suite, and preview tiers above the Business Premium licensing most SMBs hold. For the clients MSPs serve, security groups remain the deliverable primitive; the distance between that enterprise control plane and what an SMB can license is itself the governance gap to close — with evidence and process, not premium SKUs.

Without classification, governance is binary: allow everything or block everything. Classification creates the graduated control that proportionality requires.

Where the data comes from:

• M365 environments: Microsoft Purview provides sensitivity labels and DLP policies across SharePoint, OneDrive, Exchange, and Teams — and is extending into data security posture management and AI observability for Copilot and agents.
• Outside M365: backup content classification delivers PHI/PII detection across files stored in managed backup environments, including NHS identifiers, US SSN, DOB patterns, and sensitive personal categories, without requiring Microsoft E5 or Purview licensing. This Purview-independent view also supports breach-impact analysis, recovery prioritisation, cyber-insurance evidence, and regulatory reporting.

The classification engine is live in production across UK, US, EU, ZA, and CH regions, delivering three severity tiers (Non-sensitive, Sensitive, Highly-sensitive) with supporting evidence — which detector fired, at what confidence, in which category and jurisdiction.

Where this is heading: the market is converging on classification as a continuous, AI-aware posture signal (data security posture management). The richer "data-risk graph" — sensitivity plus permission exposure and which AI app or agent can retrieve a file — depends on Purview DSPM and E5-tier tooling. The backup-resident slice (sensitivity, category, jurisdiction, evidence) stays independent of that licensing, and feeds the enforcement points above rather than standing alone.

The policy engine is where governance decisions are made and recorded: which tools are approved, for what purposes, with what data-handling constraints, and what happens when a user wants something that is not on the approved list. It is the system of record and decision point; the actual enforcement happens at the control points below it (L3 proxy, L5 agent and tool governance), and the evidence flows up to L8.

MSP delivery today: this is the current commercial core of MSP AI governance delivery. Policy documentation, tool registers, and exception workflows routed through the MSP's PSA platform are fully deliverable — and the PSA remains the workflow and evidence backbone even as enforcement matures in the layers around it.

The AI proxy is the highest-value architectural control point. It sits between users and external AI providers, inspecting what is about to be sent before it crosses the model boundary.

DNS filtering, which most MSPs already deploy, approximates this for tool-level access control. It can block a browser request to an unapproved AI domain. It cannot inspect the content of a request to an approved one.

Important constraint: DNS alone cannot distinguish a user logged into a personal ChatGPT account from a corporate OpenAI Enterprise account; the domain is identical. Distinguishing account context requires SSL/TLS inspection at the proxy, CASB or API integration, a managed enterprise browser, or provider-side identity enforcement — not DNS alone. Even single sign-on is not sufficient by itself: a user on a verified domain who is not provisioned in the enterprise workspace can still reach a personal account. And unmanaged AI browser extensions are themselves a shadow-AI surface, not a control — only managed, enterprise-controlled browser instrumentation belongs in this layer.

Front-loaded controls matter, but they are not a silver bullet. The UK NCSC warns that prompt injection may never be mitigated the way SQL injection was, so this layer should classify, redact, route, log, and enforce policy deterministically rather than promise to "stop" prompt injection. For agents, the highest-value control point shifts from before the prompt to before the tool call (L5).

Governance must exist before data reaches a provider. At the provider layer the MSP's role is no longer simple vendor validation: it is maintaining provider eligibility and producing the evidence for it. The approved-provider list becomes an approved provider + product/SKU + feature + data class + region + retention register, because contractual eligibility now turns on which exact surface is in use.

For healthcare clients, PHI/ePHI may be routed only through AI services and features covered by a signed Business Associate Agreement. "The vendor has a BAA" is unsafe shorthand: coverage is product- and feature-specific — an enterprise plan's BAA commonly excludes free, team, console, and beta surfaces, and a BAA-covered model is no help if a connector, plugin, or agent path moves PHI somewhere uncovered. The forcing function is real: in a 2026 survey, 15% of doctors and 19% of administrators admitted using unsanctioned AI tools, one in ten for direct patient care — usually because the sanctioned path was unclear or slow.

MSP delivery today: the eligibility register and the evidence behind it — approved tools, exceptions, denied attempts, PHI detections, and BAA coverage by feature — are deliverable through the PSA. Runtime enforcement of those decisions lives in L3 and L5.

When AI moves from answering questions to taking actions, the risk profile changes fundamentally. An AI agent with access to email, CRM, file storage, and scheduling can read, write, send, and delete on behalf of a user.

Model Context Protocol (MCP) has consolidated as the standard for connecting AI agents to external tools and data — now under the Linux Foundation, with thousands of published servers and adoption across Microsoft 365 Copilot, Claude, ChatGPT, and Gemini. It standardises how agents discover and call tools; it does not answer whether an agent should be allowed to call one, under which identity, with which data, and with what audit trail. That governed-execution gap is the unresolved problem.

This is the highest-risk emerging area in AI governance because the control problem is fundamentally different from prompt governance. You are not governing what someone says to an AI. You are governing what the AI does to your systems on their behalf.

Deliverable today vs emerging: at the MSP tier, the deliverable slice is discovery (agent and MCP inventory, shadow-MCP detection), approval thresholds expressed as policy, turning on providers' own per-tool approval prompts, and collecting the action evidence providers expose. The runtime control plane — agent identity, delegated and scoped authorization, MCP gateways, and kill switches — is enterprise- and E5-tier, which is why this layer stays early-stage for the SMB market. The frontier is already moving past tools to agent-to-agent (A2A) and agent-led payments (AP2): the governance object becomes the mandate, not just the tool call.

MSPs consistently identify configuration drift as one of their biggest ongoing pain points. Policy gets set up correctly. Then it drifts: approved tool lists go stale, sensitivity labels lose coverage, exception approvals expire without review, and new AI capabilities appear inside tools the client already uses.

Signal sources available today:

• DNS telemetry (tool-level access signal)
• RMM events
• Purview DLP alerts
• SIEM integration through Microsoft Sentinel or equivalent
• Backup content classification (PHI/PII detection on file content)
• Backup malware detection (two-stage LightGBM pipeline with 14 named family categories, severity tiering)

Emerging: agent and MCP telemetry — tool-call traces and OpenTelemetry-based observability of agent actions — is becoming a signal source as agentic use grows, though it is not yet mainstream at the SMB tier.

Human oversight does not mean a human reviews every AI interaction. It means human judgment is applied at the points where uncertainty, risk, or regulatory obligation require it — proportionate oversight of exactly the kind regimes like the EU AI Act (Article 14) require. The operative question is shifting from "may users use this tool?" to "what may an AI system do without asking?" — the organisation's automation boundary.

The operational expression of human oversight in an MSP context is the exception workflow. Every exception request is a human judgment point — and increasingly a structured decision record (requestor and owner, tool or agent, data class, action type, permission scope, expiry, and supporting evidence) that doubles as audit evidence at L8. Routed through the PSA, this is a recurring managed-service operation, not a one-off consulting deliverable.

The audit and evidence layer is where AI governance becomes visible to clients' auditors, insurers, enterprise counterparties, regulators, and boards. The QBR evidence pack — how many AI tools moved from shadow to sanctioned status, how many exceptions were processed, the current posture trend — is a client-readable extract from a continuous evidence stream, not a once-a-quarter artefact. Shadow-AI exposure is now a board- and insurance-relevant risk indicator: in IBM's 2025 breach research, one in five organisations reported a breach due to shadow AI, and 97% of those breached lacked proper AI access controls.

The evidence model is multi-purpose by design: the same control events serve client-facing QBR proof, enterprise procurement, cyber-insurance review, and the MSP's own SOC 2 or ISO 27001 control evidence — one evidence stream, many assurance consumers. SOC 2 and ISO 27001 remain the security and assurance backbone (they are not AI-specific); AI-specific frameworks — ISO/IEC 42001, the NIST AI RMF, the CSA AI Controls Matrix, CIS AI guidance, and the EU AI Act — provide the AI governance language the same evidence maps onto.