How We Built an AI-Augmented MSP Without Shipping Controlled Unclassified Information to OpenAI

Most Managed Service Providers (MSPs) rushing to adopt AI tooling are doing something that should disqualify them from federal work: they are piping customer data directly into commercial cloud AI services like ChatGPT, Claude, and Microsoft Copilot with no documented controls, no audit trail, and no assessment of what those services do with the data they receive. For commercial clients, this may be a privacy concern. For federal clients handling Controlled Unclassified Information (CUI) or data covered by ITAR (International Traffic in Arms Regulations), it is an architecture that fails compliance requirements before the first ticket is ever resolved. For a comprehensive overview, see CMMC Compliance for Small Defense Contractors: The Complete Guide.

We built something different. This post describes the architecture and explains why federal buyers, CMMC (Cybersecurity Maturity Model Certification) assessors, and SDVOSB (Service-Disabled Veteran-Owned Small Business) primes evaluating their own tooling should care about the difference between getting this right and getting this wrong.

Why Is the Industry Default Broken for Federal Work?

The problem is not that AI is being used. The problem is where in the workflow it touches customer data. When a technician pastes a ticket description, a log excerpt, a network diagram, or an email thread into a consumer AI chat interface, that content crosses into the AI provider's infrastructure under that provider's terms of service, not under the federal contract's data handling requirements.

CUI has specific handling requirements defined by the National Archives and Records Administration under the CUI Program established by Executive Order 13556. Content that is CUI-adjacent, such as a support ticket mentioning a contract number, a network diagram showing a federal agency's subnet layout, or an email thread referencing personnel access, carries the same risk even if the technician does not recognize it as CUI in the moment. Most commercial MSP technicians have not been trained to make that distinction on a ticket-by-ticket basis, because their commercial clients do not enforce it.

DFARS (Defense Federal Acquisition Regulation Supplement) 252.204-7012, which applies to any contractor handling covered defense information, requires that cloud services used to process, store, or transmit covered defense information meet NIST SP (Special Publication) 800-171 Revision 2 security requirements. Consumer-tier offerings from major AI providers are not FedRAMP (Federal Risk and Authorization Management Program) authorized at the level required for CUI. An MSP that cannot tell you which AI services process customer data and under what authorization cannot produce the audit artifacts DFARS 252.204-7012 requires.

What Architecture Actually Solves This?

The solution is a separation of concerns between the AI reasoning layer and the execution layer. We built our operations on a framework we call WAT: Workflows, Agents, and Tools.

The design principle is explicit: separate probabilistic AI (reasoning and orchestration) from deterministic code (execution). Here is what each layer does and, critically, what data each layer touches.

Workflows are Markdown-formatted SOPs (Standard Operating Procedures) that define objectives, inputs, tools to use, outputs, and edge cases. Workflows contain no customer data. They are operational playbooks describing what the AI should do, not raw data feeds describing what a specific customer's environment looks like. A workflow might say "when a ticket is classified as a P1 life-safety alert, escalate within 15 minutes and page the on-call technician." It does not say which customer the ticket came from or what the network topology looks like.

Agents are the AI reasoning layer. The AI reads workflows and orchestrates tool execution based on them. When the AI needs to make a decision, it receives a structured summary prepared by deterministic code, not raw data directly from a customer system. The AI decides what action to take. It does not hold raw ticket contents, log files, or network credentials in its context window.

Tools are deterministic Python and PowerShell scripts that perform the actual API calls, file operations, and data transforms. This is where customer data lives. Tools run on infrastructure under our control, against APIs with defined authentication and audit logging. A tool that queries a PSA (Professional Services Automation) system returns structured data to the orchestration layer. A tool that generates an invoice calls the QuickBooks API with pre-validated parameters. Customer data flows through audited code paths, not through an AI model's unpredictable context window.

How Does Model Routing Become a Data Minimization Control?

Our model routing discipline was built as a cost control, but it has a direct compliance benefit. We route AI tasks to the lowest-cost model capable of handling them. File searches and directory lookups go to Claude Haiku. Code generation and content drafting go to Claude Sonnet. Multi-system architecture design and compliance document drafting go to Claude Opus. For automated workflows, we use a Sonnet executor with an Opus advisor that escalates only when the Sonnet tier cannot resolve the decision confidently.

From a data minimization standpoint, this matters because the lighter the model, the less context it requires. A Haiku sub-agent doing a file pattern search does not need ticket contents, client network data, or any operational context beyond the file path it is searching. A Sonnet drafting a status update receives a structured summary from the Tools layer, not a raw dump of a client's system state. Minimizing what crosses the model boundary is not just a cost discipline. It is a NIST SP 800-171 control 3.1.3 (control the flow of CUI) compliance discipline.

The NIST AI Risk Management Framework published in 2023 calls for organizations to "map, measure, and manage" AI risks, including the risk that AI systems process data in ways that violate data governance requirements. Routing decisions that explicitly constrain what data each model tier receives are a concrete implementation of that governance requirement. Most MSPs using AI tooling have no documented routing policy at all.

What Does This Mean for CMMC and NIST SP 800-171?

Four specific NIST SP 800-171 controls are directly implicated by MSP AI governance decisions.

Control 3.1.3 requires controlling the flow of CUI in accordance with approved authorizations. An MSP whose AI tooling cannot document what data crosses into which external service cannot demonstrate compliance with this control. Our architecture documents it by design: the Tools layer is the only layer that touches raw customer data, and every API call the Tools layer makes is logged.

Control 3.13.1 requires monitoring, controlling, and protecting organizational communications at external boundaries. A consumer AI service is an external boundary. Communications that cross it without authorization controls are a finding. Under NIST SP 800-171 Revision 3, published in 2024, this boundary protection requirement is more explicit about cloud services than the prior revision was.

Control 3.13.11 requires employing FIPS-validated cryptography when used to protect the confidentiality of CUI. This applies to data in transit, including data sent to an AI API endpoint. Consumer AI service endpoints may use TLS, but FIPS validation of the cryptographic implementation is a separate requirement that most commercial AI providers cannot confirm.

Control 3.14.6 requires monitoring organizational systems to detect attacks and indicators of potential attacks. A CMMC Level 2 assessor who asks what monitoring is in place on an MSP's AI tooling pipeline should receive a specific answer: which calls are logged, where the logs go, how long they are retained, and what alerts exist on anomalous usage. An MSP running consumer AI chat tools has none of this instrumentation.

The OMB (Office of Management and Budget) M-25-21 memo on AI governance issued in February 2025, which rescinded and replaced M-24-10, reinforces the same point from the buyer side: agencies are required to document and govern AI use in their operations. Federal buyers who are implementing that requirement have an obvious follow-on question for their MSP subcontractors: are you governed too?

What Should Federal Buyers Ask Their MSP?

These questions are not hypothetical. They are the questions a CMMC assessor will ask when evaluating the MSP as part of the prime contractor's supply chain posture review. Federal program managers and primes evaluating SDVOSB subcontractors should ask them first.

1. Which AI services do you use in your operations? The answer should be a specific list, not "we use AI tools where appropriate." Vagueness here is a red flag.
2. Does customer data cross into those services? If yes, under what contract terms? Is the AI provider operating under a BAA (Business Associate Agreement) or equivalent data processing agreement? Is the provider FedRAMP authorized at the Moderate or High baseline?
3. Where are the audit logs showing what was sent? If the MSP cannot produce logs demonstrating what data crossed into an AI service and when, they cannot satisfy the audit artifact requirements of controls 3.3.1 and 3.3.2.
4. How do you handle CUI-tagged tickets differently from commercial tickets? If the answer is that all tickets flow through the same pipeline regardless of classification, the architecture does not support CUI handling. Segmentation at the data handling layer is a minimum requirement.
5. Can you demonstrate a ticket being processed without any customer content leaving your boundary? A technically capable MSP should be able to walk through a specific ticket from ingestion to resolution and point to each step where data stayed inside the boundary and each step where a structured summary was passed to an external reasoning service. If they cannot demonstrate this, the architecture does not exist in the form they are describing.
6. What is your process for staying current on FedRAMP authorization status of AI services you use? The FedRAMP marketplace changes. A service that was not authorized last year may be authorized today, and vice versa. An MSP with no process for tracking authorization status is one procurement cycle away from an unintentional compliance failure.

The MSP industry is moving fast on AI adoption and slow on AI governance. For commercial clients, the gap is a risk management question. For federal clients, it is a compliance question with FedRAMP, DFARS, and CMMC implications that flow directly to the prime contractor's authorization status. Federal buyers are right to ask these questions, and subcontractors who cannot answer them are candidates for a closer look before the next option period exercise.