Skip to main content

US Defense AI: DoD Responsible AI and CMMC Compliance

US defense organizations do not have the luxury of treating AI governance as a branding exercise. They operate under overlapping obligations: DoD AI Ethical Principles and the Responsible AI Strategy and Implementation Pathway expect AI systems to be governable, traceable, and reliable, while CMMC 2.0 and its NIST SP 800-171 foundation push contractors to show disciplined control over access, auditing, configuration, and protected information. Add export-control concerns under ITAR and EAR, plus DFARS handling expectations for covered defense information and controlled unclassified information, and the real issue becomes obvious. The route itself has to be governed.

Keeptrusts is valuable here because it governs runtime behavior instead of stopping at paperwork. It can block export-control reference terms, filter dual-use content, restrict which provider targets are eligible for sensitive workloads, and create a decision trail that supports security review and contractual oversight. That does not mean a gateway alone satisfies CMMC or DoD Responsible AI requirements. It means the gateway becomes a concrete technical control that supports those broader programs.

Use this page when

  • You are deploying AI in a defense contractor, public-sector defense program, aerospace supplier, or national-security environment.
  • You need to protect CUI, export-controlled material, or mission-sensitive data in AI-assisted workflows.
  • You want to translate Responsible AI principles into operational controls rather than abstract principles documents.

Primary audience

  • Primary: security engineers, defense platform teams, compliance managers
  • Secondary: program security, export-control officers, internal audit, mission owners

The problem

Defense AI problems are usually operational before they are philosophical. An engineer pastes technical program context into an assistant. A proposal team uses a model to draft text derived from controlled project material. An analyst agent is allowed to call tools, search internal repositories, and summarize outputs for a user who assumes the system understands classification boundaries. If the route is weak, sensitive material can cross the provider boundary before anyone decides whether it should have been allowed.

That weak route conflicts with both governance and certification expectations. DoD Responsible AI asks whether the system is traceable and governable. CMMC asks whether access is controlled, activity is auditable, and protected information is handled inside a disciplined security program. Neither question can be answered well if teams cannot identify which provider path handled a request, which terms caused a block, or whether a human had to review the result.

Another common problem is overgeneralization. Organizations sometimes try to solve every defense use case with one blanket “secure” configuration. That tends to fail because public research, internal productivity, export-controlled engineering support, and CUI-adjacent mission workflows do not need the same provider posture or the same response handling. The better model is to define a small number of lanes with different assumptions and enforce them explicitly.

The solution

Start by separating low-sensitivity traffic from CUI-adjacent and export-controlled traffic. Public or nonsensitive research can use a more flexible route. Anything touching defense program details, export-control terms, or high-consequence operational content should move to a stricter lane.

Keeptrusts provides the building blocks for that stricter lane. prompt-injection protects the request boundary from hostile instructions hidden in retrieved or pasted content. itar-ear-filter blocks clear export-control terms in requests and buffered outputs. dual-use-filter adds broader capability-focused screening for terms that may not be purely ITAR or EAR labels but still indicate proliferation or weapons-related risk. data-routing-policy narrows the eligible provider set to targets whose declared data-handling posture matches the program requirement. human-oversight introduces an explicit stop when output should inform a cleared reviewer rather than flow directly to an end user.

This aligns well with the Responsible AI idea of governability. A governable system is not only one with good intentions. It is one where the organization can constrain what the system is allowed to do, detect when the route should stop, and reconstruct why a decision occurred. That same route evidence also helps support CMMC-oriented auditing and control validation, even though the certification program itself remains broader than the gateway.

Implementation

Use a controlled validation loop before any defense lane is promoted beyond testing.

kt policy lint --file policy-config.yaml
kt policy test --json
kt gateway run --listen 0.0.0.0:41002 --policy-config policy-config.yaml
kt events tail --since 24h --json
kt export-jobs create --since 30d --format json --wait

That loop gives you a concrete baseline. Lint catches configuration errors. Policy tests confirm that known export-control or dual-use phrases trigger the expected verdict. Live event review confirms the route is actually seeing the traffic you intend to govern. Evidence export gives security, audit, or contract-review teams a package they can work from.

Use ITAR/EAR Filter and Dual-Use Filter as the request and output screening layer for defense-sensitive language. Add Data Routing Policy whenever provider posture matters for a program boundary. The most practical companion references are Defense Template, Zero-Trust AI, and Tutorial: Export Compliance Evidence.

Results and impact

The immediate benefit is better boundary discipline. Teams can distinguish a general-use route from a route that handles defense-sensitive work instead of assuming all traffic carries the same risk. That reduces accidental leakage and makes change control much more explicit.

The second benefit is better traceability. Responsible AI discussions often stall because nobody can connect principle language to a real system behavior. Once the route is governed, the organization can point to blocks, escalations, provider restrictions, and exported evidence instead of relying on design claims alone.

The third benefit is more credible certification support. CMMC evidence still comes from the broader security program, but a governed AI route provides concrete material for audit conversations about access, monitoring, configuration, and protected-information handling.

Key takeaways

  • DoD Responsible AI and CMMC both become more practical when the AI route itself is governed.
  • Defense AI should use separate lanes for public, CUI-adjacent, and export-controlled workflows.
  • itar-ear-filter, dual-use-filter, data-routing-policy, and human-oversight are complementary rather than interchangeable.
  • Keeptrusts can strengthen traceability and control evidence, but it is one part of a larger defense compliance program.
  • Runtime evidence is what turns Responsible AI from principle language into inspectable behavior.

Next steps