The official Cybersecurity Maturity Model Certification program overview describes a tiered model for protecting Federal Contract Information and Controlled Unclassified Information across the defense industrial base. It also emphasizes assessment and the flow-down of protection requirements to subcontractors.
AI does not create a separate category of contract information. It creates new processing paths. A prompt, uploaded file, retrieval index, model endpoint, observability platform, or support workflow may copy data into systems that were never part of the original enclave or assessment scope.
Start by classifying the workflow's information
Federal Contract Information is information not intended for public release that is provided by or generated for the government under a contract, subject to the applicable definition and exclusions. Controlled Unclassified Information is government-created or government-possessed information, or information created or possessed on its behalf, that requires safeguarding or dissemination controls under law, regulation, or government-wide policy.
A proposed AI use case should begin with the contract, security classification guidance, CUI markings and categories, and the organization's established data-handling process. Do not infer that content is safe for a public AI service because it lacks a marking, or that synthetic and summarized content can never reveal protected source information.
Map every copy, transformation, and administrative path
The obvious path is the user prompt to the model. The complete path may include browser plugins, API gateways, request logs, safety filters, retrieval pipelines, embeddings, vector databases, model serving, output stores, analytics, backups, and vendor support access.
For each component, record the hosting environment, region, identity model, encryption, retention, backup behavior, administrative access, subcontractors, and whether customer data may be used to improve a service. Confirm those details in contractual terms and technical configuration rather than relying on a product label such as private or enterprise.
Choose a boundary the organization can defend
Some workflows may be suitable for an approved managed service; others may require a dedicated cloud boundary, isolated tenant, or on-premises deployment. The correct choice follows the information, contract, threat model, and operating capability. Self-hosting can reduce certain external paths, but it also transfers patching, hardening, monitoring, capacity, and incident response responsibilities to the contractor.
Keep the initial scope bounded. One use case, one approved corpus, and a small set of authorized users are easier to assess than a general assistant connected to shared drives, email, ticketing, and engineering systems.
Carry identity and least privilege through the AI layer
An AI application should not flatten existing access controls. Retrieval must enforce the requesting user's authorization, and tool calls should use identities scoped to the permitted action. Service accounts shared across users can expose information that the front-end application never intended to reveal.
Administrative access also matters. Model operators, platform engineers, support personnel, and external providers may gain visibility into prompts, retrieved content, outputs, or logs. Include those roles in the system boundary and access-review process.
Build evidence as the system is built
Assessment evidence is easier to produce when controls are designed into delivery. Maintain architecture and data-flow diagrams, inventories, access matrices, configuration baselines, change records, evaluation results, training records, incident procedures, and relevant supplier documentation.
AI-specific evidence should identify model and prompt versions, retrieval sources, tool permissions, evaluation thresholds, approval gates, logging behavior, and the process for changing or retiring the system. This does not replace CMMC or NIST SP 800-171 evidence; it shows how an AI workflow fits into the existing control environment.
Defense AI boundary checklist
- Confirm the contract, information type, markings, and applicable handling requirements with qualified personnel.
- Map prompts, files, retrieval data, embeddings, outputs, logs, backups, telemetry, and support access.
- Identify every provider and subcontractor that stores, processes, transmits, or administers workflow data.
- Verify service terms, data-use restrictions, retention, deletion, location, and incident-notification commitments.
- Preserve user authorization through retrieval and use least-privilege identities for tool calls.
- Define evaluation, approval, monitoring, change, incident-response, and retirement procedures.
- Collect evidence continuously and connect AI-specific artifacts to the existing system security plan.
- Recheck current CMMC guidance, acquisition clauses, and customer direction before release.
The decision gate
If the team cannot explain where protected information may travel, the use case is not ready for production. The first milestone should be a reviewed data-flow diagram and boundary decision, not a model demonstration using live program data.
A disciplined boundary does more than reduce compliance risk. It gives engineering teams a clear environment to secure, operators a system they can monitor, and program leaders evidence that the AI capability was introduced deliberately.