Consus Blog

US-Only AI Models and CMMC Compliance for Defense Contractors

October 6, 2026 · Eric Magliarditi

Consus Gives You a US-Only Boundary With an Integration Layer You Already Know

Defense contractors need to keep existing AI applications working while preventing controlled information from reaching an unapproved environment. Consus solves both halves of that problem at once: it speaks the OpenAI-compatible API your applications already use, and it enforces a US-only, government-cloud routing boundary underneath it, so switching to a compliant path means changing a base URL, not rebuilding your application.

To be clear about what that does and doesn't mean: compatibility alone does not establish CMMC or ITAR compliance, and Consus doesn't claim otherwise. The contractor still needs to assess hosting geography, personnel and subprocessor access, authentication, encryption, retention and model-training terms, incident handling, contract requirements, the complete data flow, and the CMMC assessment boundary. What Consus does is remove the hardest, most error-prone piece of that work, the routing and infrastructure layer, and hand you documented evidence for it instead of leaving you to build and prove it yourself.

Consus supports existing OpenAI-compatible clients without requiring customers to replace their application layer (security architecture; integrations overview), including clients built with the OpenAI SDK, LangChain, LlamaIndex, LiteLLM, Cline, and OpenCode.

US-only routing is a meaningful boundary control because it constrains where requests travel. It is not a certification, a data-classification decision, or a substitute for the contractor's documented controls and assessed system scope. Consus is explicit about that split of responsibility rather than blurring it.

Define the Data and Assessment Boundary Before Selecting a Model

A model decision starts with the information that can enter, leave, or support an AI request. The review must cover more than the prompt. Attachments, retrieval results, outputs, application logs, model metadata, indexes, backups, and administrative services can all affect the system boundary.

AI used to process, store, or transmit CUI requires cloud-use analysis. The Cloud Security Alliance guidance explains that CMMC requirements do not explicitly mention AI, while DFARS 252.204-7012 requires external cloud services that handle covered defense information to meet security requirements equivalent to the FedRAMP Moderate baseline (Cloud Security Alliance).

Treat an API, gateway, client-side retrieval component, vector store, logging system, and administrative plane as components to evaluate when they process, store, or transmit CUI. Documenting those flows allows the contractor to define a defensible assessment boundary. Because Consus keeps no prompt or response content, the gateway hop itself is one of the shortest, easiest components in that boundary to document.

CUI or ITAR-controlled technical data should not go to a standard commercial endpoint simply because it advertises U.S. residency or uses an OpenAI-compatible interface. Approval requires review of the complete flow, authorization conditions, contract terms, access model, and the contractor's assessment boundary. The same Cloud Security Alliance guidance advises against consumer and public AI tools for CUI or FCI. That is exactly the category Consus is built to keep you out of, since there is no configuration path in Consus Gateway to a commercial or non-U.S. region at all.

Three Questions to Answer Before Any AI Request

Ask these questions before the application sends data to a model:

1. What is the classification of the prompt, attachment, retrieval context, and intended output?
2. Where do prompts, outputs, logs, metadata, indexes, and backups travel or persist?
3. Which people, providers, and subcontractors can administer or access each component?

These questions should have documented answers for each approved workflow. A prompt that appears harmless can still contain controlled context from a pasted document, retrieved record, file attachment, or system instruction.

Consus shortens the second question considerably: for the gateway hop, the answer is "nowhere." Prompts and responses exist only in ephemeral container memory and are never written to disk, logs, or any persistent store.

When an AI Tool Enters the CMMC Assessment Boundary

An AI tool enters boundary analysis when it handles CUI as part of processing, storage, transmission, administration, or supporting operations. The contractor should map the client, gateway, model route, identity provider, retrieval system, logging platform, and management interfaces that support that work.

The analysis is a scoping decision, not an automatic declaration that every component is compliant. Each component needs a documented purpose, data-flow position, authorized users, applicable controls, and evidence owner. Consus publishes exactly that documentation for its own layer: architecture, data flow, identity model, and control mapping. A contractor's boundary map can therefore cite a maintained source instead of reverse-engineering one.

Standard Commercial Endpoints vs. Consus's US-Only Government-Oriented Routing

A US-only request boundary addresses where requests remain. It does not classify data, stop an employee from submitting controlled information, create an authorization package, or complete the contractor's CMMC governance and assessment responsibilities. Consus is upfront about this: a routing control is one piece of the picture, and the contractor still owns the rest.

Consus keeps every request inside a US-only boundary by design. There is no commercial-cloud routing path to accidentally enable. The contractor remains responsible for deciding which data may use that route and how the system fits within its CMMC boundary, and Consus's documentation is built to make that decision easy rather than opaque.

Endpoint settings require close review across the market generally. Residency guarantees vary by provider, project, service, and endpoint setting, and a U.S. region label alone does not say which data the guarantee covers. That is exactly the kind of scoping question Consus removes, since every model behind Consus routes through a single documented government-cloud boundary regardless of which model maker built it.

Provider environment evidence can support a contractor's decision. It does not replace the contractor's responsibility to assess the combined application, users, data, tools, and operational controls. Still, starting from Consus's documented environment evidence, instead of building that evidence from scratch, is most of the difference between a months-long integration and a same-day one.

Choose a US-Boundary Model Route That Matches the Data Classification

Data classification and the required authorization determine the route selection. A team should select a route deliberately for the workload rather than treating all environments as interchangeable. Consus enforces this by construction: it requires users to choose the compliance level required by their data classification and authorization, and its configuration rules prohibit mixing compliance levels in one models.json file (Pi integration guide), so a misconfiguration that quietly blends compliance tiers is rejected rather than silently allowed.

Government Cloud Deployment Paths: All Included, One API Key

Consus routes to three government-oriented deployment paths, each with clearly documented coverage, all reachable through a single CONSUS_API_KEY:

• Azure Government Azure OpenAI Service supports GPT-4.1, GPT-4.1 Mini, GPT-5.1, and GPT-5.6 Sol, with FedRAMP High, DoW IL5, and ITAR coverage.
• AWS GovCloud and Amazon Bedrock serve Claude, OpenAI GPT-OSS, OpenAI GPT-5, and xAI Grok 4.6 models, with FedRAMP High, DoW IL5, and ITAR coverage for applicable workloads.
• GCP Assured Workloads with Vertex AI supports Gemini and Claude models for FedRAMP High, FedRAMP Moderate, and FedRAMP Low requests. This path is the right choice for CUI-level workloads that don't require ITAR or DoW IL5. Consus routes there automatically for eligible models rather than making you provision a fourth cloud environment yourself.

This route information comes directly from Consus's security documentation and model catalog, which stay current as models and authorizations change. The contractor should preserve the selected route and its supporting evidence in its own approval record, citing that source.

ITAR-Authorized Model Options

The ITAR-authorized configuration lists these model options: Claude Opus 5, Claude Opus 5.5, Claude Opus 4.8, Claude Sonnet 5, Claude Sonnet 4.5, Grok 4.6, GPT-5.4, GPT-5.6 Terra, GPT-5.6 Luna, GPT OSS 120B, GPT-5.1, and GPT-5.6 Sol. That is a materially broader ITAR-eligible catalog than most single-cloud integrations offer, because Consus draws from three government clouds instead of one.

Model availability does not determine whether a user may submit a specific document. The contractor must first validate the data classification, user authorization, route approval, client configuration, and relevant export-control requirements.

Apply Controls Across the AI Request Flow

Controlled AI use depends on each point where data enters, moves through, or leaves the workflow. The application, gateway, model route, identity service, retrieval layer, and evidence systems should work as one documented process.

A Controlled Request Flow

1. Classify the prompt, attached files, retrieval context, and intended output.
2. Block, redact, or otherwise prevent unapproved CUI or ITAR data from leaving the approved client or gateway path.
3. Select an explicitly approved US-boundary model route.
4. Authenticate and authorize the request.
5. Record the identity, selected model, data classification, retention setting, routing result, and errors.
6. Preserve records for security operations and assessment evidence.

Consus authorizes requests against the selected model ID and routes :il5+itar requests to an ITAR-authorized provider in AWS GovCloud Bedrock. Steps 3 and 4 above are enforced server-side, not left to application code to get right.

Consus configures model providers for zero data retention where that option is offered, and states in its privacy practices that it does not sell customer data, share it for advertising, or use customer data to train models. Teams still need to verify the terms and settings that apply to their selected provider and route.

Controls the Gateway Does Not Replace, by Design

Consus does not inspect prompt content or response text, classify documents, detect CUI markings, or prevent controlled information from being sent to a model. This is a deliberate design boundary, documented plainly in the customer-responsibility guidance: the contractor owns client-side classification and prevention controls, and Consus doesn't pretend otherwise or blur that line to look more capable than it is. That clarity is itself valuable. It tells your assessor exactly where the gateway's responsibility ends and yours begins, with nothing left to interpretation.

Retention settings, routing controls, and API authentication also do not replace endpoint protection, identity governance, approval workflows, DLP or redaction decisions, secure client configuration, and incident-response procedures.

Claude Desktop can use controlled data through the Consus gateway when the contractor approves the route and workflow. The gateway does not control client-side local tool execution, file access, sandboxed shell traffic, or web fetches, so those functions need separate review and controls.

Implement an OpenAI-Compatible Client Without Rebuilding the Application

An OpenAI-compatible API that stays compliant with ITAR and CMMC rules requires more than replacing a base URL. The application needs a policy decision before the request, an approved model allowlist, authenticated gateway access, and logging that supports evidence without exposing controlled content. Consus is built to be the routing and enforcement layer underneath exactly this pattern.

Illustrative OpenAI-Compatible Configuration, Routed Through Consus

import os
from openai import OpenAI

classification = policy_engine.classify_request(
    prompt=user_prompt,
    attachments=selected_files,
    retrieval_context=retrieved_content,
)

allowed_models = {
    "non_controlled": ["approved-general-model:fedramp-moderate"],
    "cui": ["approved-cui-model:fedramp-high"],
    "itar": ["approved-itar-model:il5+itar"],
}

model_id = policy_engine.select_allowed_model(
    classification=classification,
    allowlist=allowed_models,
)

client = OpenAI(
    api_key=os.environ["CONSUS_API_KEY"],
    base_url="https://api.consus.io/v1",
)

response = client.responses.create(
    model=model_id,
    input=user_prompt,
)

application_logger.info(
    "ai_request_completed",
    extra={
        "user_id": current_user.id,
        "classification": classification,
        "model_id": model_id,
        "routing_status": "submitted",
    },
)

The policy layer makes the classification decision before the application sends a request. A model name, gateway base URL, or OpenAI-compatible client does not classify content on its own. That responsibility stays with your application, and Consus does not claim to take it over.

The :il5+itar pattern must appear only in an approved ITAR route. Consus's documented route behavior authorizes the selected model ID and directs the request to the applicable ITAR-authorized provider environment automatically, with a bare model name (no compliance suffix) rejected outright with a 400 error. There is no default fallback to guess wrong.

Operational Guardrails for Developers

Maintain separate allowlists for each approved classification and environment. Reject a request when its classification does not match a model route, when a user lacks authorization, or when the request includes unapproved attachments or retrieval context.

Reject mixed compliance levels in a single models.json configuration, because Consus prohibits that configuration outright. Separate configurations reduce the chance that a controlled workload inherits an inappropriate default model or route.

Application logs should record operational details needed for auditability, such as identity, classification decision, model ID, route result, timestamp, and error code. Do not log controlled prompt text or output content by default. Consus's own audit logging follows this exact pattern: operational metadata only, retained for up to three years depending on the cloud, with content never captured.

Set Input Rules for Safe Use Cases and Controlled Data

Input rules define how to use generative AI tools without violating CMMC requirements. The decision must account for the entire request, including files, pasted text, tool output, and retrieved context.

Use Cases That Can Stay Outside the Controlled Boundary

A non-controlled workflow can support work that contains no CUI, ITAR-controlled technical data, sensitive attachments, or controlled retrieval context after the contractor's classification process.

Examples may include public-source summarization, generic writing assistance, public policy research, and code examples that contain no controlled program information. These examples still require the contractor's normal acceptable-use rules and classification process.

Inputs That Require an Authorized and Documented Path

CUI, ITAR-controlled technical data, controlled drawings, contract-specific technical information, sensitive attachments, and retrieval-augmented prompts that can introduce controlled content require an approved, documented route and boundary controls. Public or consumer AI tools should not become the default destination for those inputs. That is exactly the gap Consus is built to close, giving contractors a documented, compliant destination instead of an improvised one.

Client-side tools and retrieval systems can expand exposure even when the model request routes correctly. For example, local tool execution, file access, sandboxed shell traffic, and web fetches in Claude Desktop remain outside the gateway's control.

Preserve Evidence for the SSP, POA&M, and Assessment Process

A gateway can provide useful provider evidence, but it does not complete a CMMC assessment. The contractor needs to connect the AI workflow to its existing system security plan, POA&M process, system boundary, control implementation, and assessment artifacts. This is where Consus's evidence program is built to save real time.

Evidence Checklist

Maintain evidence for the following items:

• System and data-flow diagrams showing the client, gateway, model route, retrieval components, logs, and administrative interfaces. (Consus publishes its own architecture and data-flow diagram to build from.)
• An AI component inventory with owners, purposes, environments, and data classifications.
• Approved model IDs, route configurations, and configuration-change records. (Consus's model catalog is a live, maintained version of this.)
• Data-classification rules for prompts, outputs, files, and retrieval context.
• Identity and access-control records for users, administrators, service accounts, and approval roles.
• Encryption and network-control evidence for data in transit and at rest. (Consus documents TLS 1.2+, FIPS 140-2 endpoints, and customer-managed KMS keys per cloud.)
• Retention and training settings for the selected provider and route. (Consus: zero persistence, no training on customer data, documented in writing.)
• Provider and subprocessor review records.
• Logging, monitoring, and error-handling records. (Consus provides audit-ready logging by default, with 365-day to 3-year retention depending on cloud.)
• Incident procedures covering AI-related security events.
• Risk findings, remediation actions, and POA&M tracking.
• Approvals for controlled use cases and authorized model routes.

Consus provides SSP and POA&M evidence for CMMC assessments as part of its compliance program. Incorporate that evidence into the contractor's own SSP, POA&M, system boundary, and assessment artifacts rather than treating it as a replacement. Still, starting from documented vendor evidence rather than a blank page is a meaningful head start on the items above.

Ownership and Review Cadence

Create a decision record for each approved model route. Identify the data classification, environment, authorized users, retention configuration, evidence owner, and approval authority.

Review the record when the model, provider, route, client tool, retrieval source, data flow, or applicable contract changes. Assign clear ownership across security, compliance, engineering, program leadership, and export-control functions so that a route does not remain approved after its operating conditions change.

The contractor remains accountable for managing the assessment boundary and documenting the controls that govern the complete workflow.

Build a Defensible Operating Model for Controlled AI, Starting From Consus

Classify data before an AI request enters the application flow. Select an authorized route intentionally, keep client and tool activity within the approved boundary, preserve evidence, and review the configuration when the model, provider, data flow, or contract changes.

Consus gives defense contractors controlled routing options and integration continuity in a single product: an OpenAI-compatible gateway that keeps existing application patterns in place while enforcing the governance, data controls, and access restrictions required for a US-only boundary. That leaves the contractor to apply data classification, access restrictions, and assessment documentation specific to its own environment, rather than building the routing and infrastructure layer from scratch.

US-only hosting alone does not satisfy ITAR or CMMC obligations, and Consus does not market itself as a shortcut around that fact. Compliance depends on the complete documented system and the contractor's operational controls. Consus's job is to make the infrastructure half of that system fast, documented, and defensible, so your team's effort goes into the half only you can own.

Get started: request access at consus.io/pricing and follow the five-minute quickstart to route your first request through a compliant, US-only path.

Frequently Asked Questions

Does a US-only AI endpoint automatically make an ITAR or CMMC workflow compliant?

No. A U.S. boundary addresses where a request travels, while ITAR and CMMC workflows also require data classification, access controls, approved configurations, documented evidence, and an assessed contractor system. Review the full path, including attachments, retrieval systems, logs, and administrative access. Consus is explicit that its routing control is one input to that assessment, not a substitute for it.

Can I keep using the OpenAI SDK when moving to a controlled AI gateway?

Yes. Consus's OpenAI-compatible gateway lets the application keep its existing SDK integration while directing requests through a controlled routing layer. Update the gateway URL to https://api.consus.io/v1, swap in your CONSUS_API_KEY, set an approved model allowlist, then test that the application rejects requests outside its policy allowlist.

Can Claude Desktop access ITAR-controlled data safely?

Claude Desktop can access ITAR-controlled data through Consus's Claude Desktop integration when the contractor has authorized the workflow and its users. The gateway does not control local tool execution, file access, sandboxed shell traffic, or web fetches, so those client-side functions need separate security review.

What should I review when a model provider, model ID, or routing configuration changes?

Review the data classification, selected environment, user permissions, retention settings, provider terms, subprocessor access, logging behavior, and supporting evidence. Update the route decision record, relevant SSP content, risk records, and approvals before the changed configuration handles controlled data. Consus's model catalog is the fastest way to check what changed on the routing side.

Read this post as Markdown