The moment a government team decides to deploy an AI agent, a sales cycle starts. Vendors appear with an “AI governance platform,” a compliance dashboard, a model-risk module, all priced per seat per month and all promising to make the auditors happy. Most of the time you do not need any of it. What you need is to map your AI deployment onto the security controls you already own and already pay for inside M365 GCC.
Done right, government AI governance under NIST 800-171 and zero trust is not a product you buy. It is a set of design decisions you make before the first agent ships, expressed in tools that are already in your tenant. Here is the starter framework I use, and the controls it maps to.
Two Documents Set the Bar
NIST SP 800-171 protects Controlled Unclassified Information in non-federal systems. Revision 3, published in May 2024, trimmed the requirement count from 110 to 97 and added three control families. Worth a note for defense work: the DoD issued a class deviation keeping Revision 2 and its 110 controls as the standard under DFARS 252.204-7012 and CMMC Level 2 for now, while civilian-agency contractors look to Revision 3. Either way the control objectives that matter for AI are stable, and that is what you design to.
OMB M-22-09, the federal zero trust strategy issued in January 2022, set milestones for civilian agencies around five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. It technically binds Federal Civilian Executive Branch agencies, but its expectations flow down through contracts constantly, so if you build for government you build to it. An AI agent is just another application and workload that has to live inside those pillars. It does not get an exemption for being clever.
Start With Inventory, Because You Cannot Govern What You Cannot Name
Before a single control, answer three questions for every agent. What data does it read? What actions can it take? Under what identity does it run? If you cannot answer those crisply, you do not have a governance gap, you have a design that is not finished. NIST 800-171’s configuration management and system integrity families assume you know what your system is and does. An AI agent whose data access and action scope are vague fails that assumption on day one.
This inventory is also the document an assessor will ask for. Writing it first means you are not reconstructing the system’s behavior under audit pressure later. You are describing a thing you designed on purpose.
Identity: Scope It, Never Let It Stand
The Identity pillar of M-22-09 and the access control family of 800-171 land in the same place for AI: the agent runs under its own scoped identity, not a user’s token and not a standing privileged account. In practice that is a managed identity or app registration with only the Graph permissions its functions require, governed by conditional access, with phishing-resistant authentication for the administrators who manage it.
The discipline here is no standing broad permissions. An agent that classifies documents has no reason to hold mailbox-management rights, so it does not. You scope the identity to the operations and the operations to the mission. Every tool you need for this, Entra ID, conditional access, managed identities, already ships in your GCC tenant. There is nothing to procure.
Data: Ground Retrieval, Label Sources, Stop Invention
The Data pillar is where AI governance gets specific. An agent should retrieve only from authorized, labeled sources, and its answers should be citation-bound, traceable back to the document they came from rather than improvised by the model. In a setting where the output is legally load-bearing, a personnel manual answer, a records determination, an unsourced answer is not a feature. It is a liability.
Purview sensitivity labels and DLP, already in your tenant, do the heavy lifting. Labels define what the agent is allowed to surface. DLP policies stop sensitive content from leaving the boundary through the agent. Retrieval is constrained to the corpus you authorized, so the agent cannot ground an answer in something it should never have read. This is also how you keep the agent inside the data-handling objectives of 800-171 without bolting on a separate tool.
The AI governance product you were about to buy is mostly already sitting in your tenant, unconfigured.
Accountability: Log Everything, Make It Queryable
The audit and accountability family of 800-171 wants a complete, reviewable record of what the system did. For an AI agent that means logging the request, the resolved intent, the action, the parameters, the identity, and the result, then routing it into your existing audit logging and Purview. The cross-cutting capabilities in the zero trust model, visibility and analytics, automation and orchestration, and governance, are satisfied by the same trail.
The test is simple. When someone asks why the agent took an action, can you produce the answer in minutes from logs you already keep? If yes, you are audit-ready. If the honest answer is “we would have to guess,” your governance is theater regardless of what dashboard you bought.
Consequential Actions Keep a Human
Governance is not only about what the agent reads. It is about what it is allowed to do unsupervised. Reversible, low-risk operations can run on their own. Anything consequential gets a confirmation step and a named approver. Anything irreversible is not the agent’s decision to make and routes to a person with the context assembled. This is least privilege expressed as workflow, and it is the line between an automation that helps and one that becomes the incident.
Write Down the Mappings
The last step is documentation that an assessor can follow. For each control objective you care about, write one or two lines tying it to a concrete design choice: this 800-171 access-control requirement is met by this scoped identity, this data objective by this Purview configuration, this audit requirement by this logging path. That mapping is the difference between a system that is secure and a system that can be shown to be secure, and in government those are two different deliverables.
An Honest Boundary
One thing this framework is not: it is not a FedRAMP authorization or a passed CMMC assessment, and nobody should sell it to you as one. What it gives you is an AI deployment architected to operate within Microsoft’s FedRAMP-authorized GCC boundary and aligned to NIST 800-171 and CMMC control objectives, with the evidence to prove the alignment. That is alignment, not certification, and the distinction matters. Anyone who blurs it is selling you risk.
If you want a governance starter framework built into your AI from the first design decision instead of audited onto it later, that is the foundation of how I work. The companion piece on running tier-three M365 admin safely shows these controls in a working build. When you want to map your own deployment, let’s talk.