32 CFR 170 · DFARS 252.204-7012 · NIST SP 800-171
ESP / SPA Scoping
Updated 06 Sep 2026
Insights · AI Governance
Are AI vendors ESPs or SPAs under CMMC?
The question assumes the two are competing labels for the same thing. They aren’t — and the classification follows the data flow, not the product category.
AI is moving into the defense industrial base faster than most organizations can update their architecture diagrams. Employees summarize documents with AI assistants. Developers adopt AI coding tools. Security teams evaluate AI-powered SOC platforms and vulnerability management products. Business units connect copilots to internal data, usually without telling anyone in security.
For organizations preparing for CMMC that raises an immediate question: is an AI vendor an External Service Provider, a Security Protection Asset, or something else? My answer is that you should not start by classifying the vendor at all. Start with the service, the data, and the data flow.
There is no special AI vendor category in CMMC. A service does not become an ESP because it uses a model, and not every AI tool touching a CMMC environment is an SPA. The classification follows what the service actually does, and that distinction has real consequences for your assessment scope.
Framing
The wrong question
I keep hearing some variation of “Can we use this vendor — are they CMMC compliant?” It is an understandable question and it skips about five steps.
Before I care about a vendor’s certification posture, I want to know what we are sending to the service. Does it receive CUI? Does it receive security information used to protect the CUI environment? Does it store that information, even temporarily? Where is inference performed, are prompts retained, are uploaded files retained, does the provider use customer data for model improvement, and which subprocessors participate? And underneath all of it: does this meet the definition of a cloud service under the rules that already apply to us?
Answer those, and the CMMC analysis usually resolves itself.
Definitions
Start with the definitions
The regulatory starting point is 32 CFR Part 170, which distinguishes between External Service Providers, Cloud Service Providers, Security Protection Assets, and Security Protection Data. The most common mistake I see is treating ESP and SPA as two competing labels for the same thing. They are not.
| Concept | What it describes | What triggers it |
|---|---|---|
| CUI | The controlled information itself | Contract, marking, or derivation from marked material |
| Security Protection Data | Information used to protect the CMMC environment | Logs, configurations, vulnerability findings, authentication data |
| External Service Provider | A provider relationship — who you are dealing with | External people, technology, or facilities delivering a service to you |
| Cloud Service Provider | A subset of external service meeting the cloud definition | Multi-tenant, on-demand, network-accessible shared resources |
| Security Protection Asset | An asset’s function — what a thing does in your scope | Provides a security function or capability for the environment |
One describes who you are dealing with; the other describes what a thing does in your environment. That sounds academic until you try to classify an actual product. Take an external AI-powered monitoring platform: the company falls into the ESP analysis while the service it delivers performs security protection functions inside your boundary. Both determinations can be true at once.
So the better question is not ESP or SPA. It is: what role does this provider, and this specific service, play in protecting or processing information within our scope?
Method
Follow the data
This is where every AI security review should begin. Set the AI label aside and draw the data flow.
When a user enters information into a prompt, uploads a document, connects a repository, or lets an agent query an internal application, where does that information actually go? If the answer includes CUI, the conversation changes immediately.
DFARS 252.204-7012 matters here. Where the clause applies, covered contractor information systems are subject to NIST SP 800-171. And if a contractor intends to use an external cloud service provider to store, process, or transmit covered defense information, 252.204-7012(b)(2)(ii)(D) requires the contractor to ensure the provider meets security requirements equivalent to the FedRAMP Moderate baseline, along with the specified cyber incident reporting obligations. That requirement predates the generative AI boom by years. AI did not eliminate it — it made it much easier to create data flows that trigger it without anyone noticing.
Application
Three services that classify differently
| Service | Likely trigger | What decides it |
|---|---|---|
| Generative assistant | CUI transmitted to an external system | Whether it meets the cloud definition; retention and subprocessor model |
| AI security platform | Security Protection Data and SPA analysis | Whether it provides a security function for the environment |
| AI coding assistant | Depends entirely on whether source code is CUI | Volume of code sent, indexing behaviour, agent permissions |
The generative assistant
An engineer copies a paragraph from a controlled technical document into a commercial AI assistant and asks for a summary of the engineering risks. The relevant question is not whether the model trained on public data or whether the product is marketed as a copilot. It is whether CUI has now been transmitted to an external system, and if so, whether that system is a cloud service provider subject to the DFARS analysis above.
Answering that means examining where the prompt is processed, whether it is logged, whether it is retained, where uploaded files are stored, which vendor personnel can access them, which subprocessors participate, what the contract actually obligates, and what happens to the data when the session ends. A zero-retention statement is relevant but not dispositive. Data can be processed without being retained.
Why this matters: a policy that says “do not upload CUI into public AI” is necessary and insufficient. Policy without technical enforcement is a control you cannot evidence, and an assessor will ask you to evidence it.
The AI security platform
Now take a product that analyzes endpoint alerts, authentication activity, firewall events, and vulnerability data. It may never see the engineering drawing that constitutes your CUI. But it receives information used to protect the systems that hold it, which brings Security Protection Data and Security Protection Assets into the analysis.
This is the category organizations miss, because security tooling usually sits outside the obvious CUI boundary. SIEM platforms, managed SOC services, identity security platforms, vulnerability scanners, EDR consoles, and now AI security assistants all process information about the posture of your environment without necessarily processing CUI. “Does this system contain CUI?” is only half the test. The other half is whether it provides a security function or handles security protection information for the CMMC environment.
The AI coding assistant
A developer runs an AI coding tool against a repository containing source code developed under a DoD contract. Before approving that, determine whether the source code is CUI or covered defense information. If it is, architecture decides everything: how much code leaves the environment, whether retrieval augmented generation is in use, whether the vendor retains prompts or snippets, whether the service indexes the full repository and where that index lives, and whether an agent can retrieve files outside the intended project.
The phrase “AI coding assistant” tells you almost nothing about CMMC impact. The data flow tells you almost everything.
Requirements
What NIST already requires
The principle is not unique to CMMC. NIST SP 800-171 Rev. 3 addresses both external systems and external system services.
| Requirement | Covers | Practical effect |
|---|---|---|
| 03.01.20 | Use of external systems | Conditions that must be met before authorized individuals process, store, or transmit CUI on them |
| 03.16.03 | External system services | Define security requirements for providers, document shared responsibilities, monitor compliance |
Neither requirement mentions AI, and neither needs to. They are architecture-neutral by design, which is exactly why they still work against systems that did not exist when they were written.
Process
A working decision tree
Five steps before an AI service enters a CMMC environment
- Does the service process, store, or transmit CUI? If yes, stop treating it as ordinary SaaS procurement. Determine the system boundary, determine whether it meets the cloud service definition, and apply the CMMC, DFARS, and NIST requirements that follow.
- If not, does it handle Security Protection Data? Security logs, vulnerability findings, configurations, and authentication data all count. If yes, work through the ESP and SPA scoping rules.
- Does it provide a security function for the environment? Evaluate the Security Protection Asset implications even where the service never touches your CUI.
- If neither CUI nor SPD is involved, what connectivity exists? API access, plugin permissions, agent credentials, browser integrations, repository access, and identity permissions all change the architecture and the risk.
- Document the decision. Not in an email thread between security and procurement. Record the data flow, the classification, the shared responsibilities, the contractual requirements, the technical restrictions, and the reasoning.
When an assessor asks why a service sits inside or outside your scope, that last record is the answer. Everything before it is analysis; only the documentation is evidence.
Diligence
What to ask every AI vendor
Vendor security review — minimum question set
- Can the service process, store, or transmit CUI?
- Where does customer data reside, physically and logically?
- Are prompts, outputs, embeddings, or uploaded files retained, and for how long?
- Is customer information used to train or improve models?
- Which subprocessors can receive customer information?
- Does the product meet the definition of a cloud service?
- What FedRAMP authorization or equivalency evidence exists, where applicable?
- Which security responsibilities belong to the vendor and which to us?
- Can administrators technically prevent users from submitting CUI?
- What logging is available to demonstrate those restrictions?
- How are security incidents involving customer information handled and reported?
- Can we retrieve the evidence we need to support our own assessment?
I ask about agents separately. A chatbot that accepts text is one risk model. An agent that can authenticate to SharePoint, GitHub, an ERP system, email, or an engineering repository is a different architecture entirely, and authorization boundaries matter there as much as prompt security.
Vendor claims
“We don’t train on your data” is not a compliance strategy
Enterprise AI vendors lead with this, and it is worth having. It is a meaningful privacy and intellectual property protection. It does not answer the CMMC question.
A provider can process CUI without training on it. A provider can temporarily store CUI without training on it. A subprocessor can receive CUI without training on it. An inference service can move information between components without adding any of it to a foundation model. Training is one data use among many, and it is not the one that determines your scope.
The analysis you actually need is: where can our controlled information go, what systems process it along the way, who can access it, and what security requirements apply to those systems?
References
Primary sources for this brief
- 32 CFR Part 170 — CMMC Program, definitions and scoping
- DFARS 252.204-7012 — safeguarding covered defense information; cloud service provider requirements
- NIST SP 800-171 Rev. 3 — 03.01.20 (external systems) and 03.16.03 (external system services)
- CMMC Level 2 Scoping Guidance — asset categorization
- FedRAMP authorization boundary guidance
FAQ
Common questions
Is every AI vendor an ESP?
No. ESP describes an external provider relationship under the CMMC framework. Whether a particular AI vendor falls into that analysis depends on what service they deliver and what information crosses the boundary — not on whether the product uses a model.
Can a vendor be both an ESP and provide an SPA?
Yes, and this is the point most people miss. The provider relationship and the function of the service are separate determinations. An external AI security platform can sit in the ESP analysis while the capability it delivers is a Security Protection Asset in your scope.
Our AI tool never touches CUI. Are we finished?
Not necessarily. If it processes Security Protection Data or provides a security function for the environment, it still warrants analysis. And if it holds API access, agent credentials, or repository permissions, the connectivity itself may change your architecture even where no controlled data flows through it.
The vendor says they’re FedRAMP authorized. Does that settle it?
Check the specific service against the authorization package rather than relying on the provider’s overall status. Providers add services continuously, and newer AI offerings often sit outside the authorization boundary for a period after launch.
Is a zero-retention guarantee sufficient?
It is relevant and it is not dispositive. Data can be processed without being retained, transmitted between components without being stored, and passed to a subprocessor without ever entering a training set. Retention is one question in a longer analysis.
Where does this sit relative to CMMC scoping generally?
Exactly where every other external service sits. If it processes, stores, or transmits CUI, or provides a security function to the environment, it is in scope and gets categorized like anything else. See the scoping brief for the categorization method.
Evaluating an AI service for a CUI environment?
We review the data flow and the contract together — boundary, classification, retention, subprocessors and shared responsibility — and give you a written determination you can hand to an assessor.
Book a scope call. Thirty minutes, no charge.
Related briefs
This brief reflects published guidance as of 6 September 2026. Scoping treatment of external service providers has changed between rule versions; verify specifics against the current 32 CFR Part 170 text and applicable CMMC scoping guidance before relying on them. Advisory content, not legal advice.
Sofia advises defense and technology companies on CMMC readiness, NIST SP 800-171 implementation and privacy programs, with a focus on the parts of compliance that only work when people outside IT own them. She holds a law degree along with CMMC-CCP, CISA, CISM, CIPP/E and CIPP/US.
Cyber DSC · Insights · Vendor Brief 01 · 06 Sep 2026