Defense Contractor AI Audit Trails Need Contract and CUI Context

A design engineer selects a paragraph from a drawing note and asks an approved LLM to rewrite it for a supplier. The model call may finish within seconds. Its compliance history begins earlier. The application identifies the engineer and contract, classifies the text and resolves the destination endpoint, and AI audit trail defense contractors work needs to preserve that decision. A provider log showing one shared API credential cannot explain whose CUI crossed the boundary or which rule permitted it.

The strongest evidence follows the request through the control point and keeps the current CMMC baseline separate from later NIST guidance.

TL;DR

• CMMC scope follows systems that process, store or transmit FCI or CUI, including relevant external services and security protection assets.
• A useful AI record connects the originating person or agent to contract context, information class, destination and policy outcome.
• CMMC Part 170 uses NIST SP 800-171 Revision 2 for its Level 2 baseline. Revision 3 is useful design guidance, but it is not a silent baseline change.
• HTTP request records support assessment sampling for routed LLM traffic. They leave local models, supplier-native inference and the wider CMMC program to other controls.

CMMC scope reaches the model route

The CMMC Program rule in 32 CFR Part 170 defines CUI assets as assets that can process, store or transmit CUI, and it also treats some assets that provide security functions as Security Protection Assets. That language makes the actual data path more useful than the product label.

An assistant working only with public proposal text may sit outside the CUI environment when the systems are properly isolated, while the same assistant becomes part of a different scope analysis when retrieval adds controlled technical information. A commercial endpoint can also become part of the path once the contractor transmits CUI to it.

The audit design should begin with the boundary decision recorded in the system security plan. AI governance for defense contractors covers use-case approval and ownership, while the audit trail supplies dated evidence that production routing matched that approval.

The current baseline and newer guidance have different jobs

Part 170 ties Level 2 assessment work to NIST SP 800-171 Revision 2, so contractors should avoid describing Revision 3 as the CMMC assessment baseline unless the applicable contract or rule says so. A publication date alone never changes an incorporated requirement.

NIST SP 800-171 Revision 3 still provides precise language for designing audit records. Its Audit Record Content requirement names the event type and time, the event location and source, the outcome and the identities associated with it. The Audit Record Generation requirement calls for generated records for selected event types and retention consistent with records policy; the discussion also recognizes distributed transactions across service and cloud architectures.

That is a good description of an LLM request that begins inside a contractor application and ends at an external endpoint. Use Revision 3 as a design reference, while mapping assessment evidence to the requirement set that actually governs the contract.

The request record needs program context

A model provider usually sees the contractor's service credential, while the calling application knows the individual engineer or agent that initiated the request. If that identity disappears at the API boundary, the resulting log proves only that the relay made a call.

The request record should carry the originating principal and calling application, along with the contract or work-package reference and the detected information category. Record the resolved provider and model route. Bind the event to the effective policy and the permit, block, redaction or reroute result, then use a stable request identifier to connect the response without forcing every reviewer to handle raw CUI.

I would reject a CUI audit design that stops at the shared service account because it leaves the assessor staring at a green row with no person attached. Signed audit logs for AI requests explains why the decision record belongs outside the calling application's write path.

Content retention should follow the evidence need

A complete audit record does not require a second uncontrolled archive of every prompt. Full text may contain controlled technical information, export-controlled material or supplier data, and copying it into a general logging platform creates another system that needs scoping and protection.

Record classification results and cryptographic fingerprints where those fields can answer the control question, and keep a protected content reference when an investigator needs retrieval. If full prompt retention is required, place it in an approved repository with access control and a records schedule tied to the contract. The decision record can link to that repository by request identifier.

NIST Revision 3 says organizations may limit additional audit information to what their audit requirements need. Applied to AI requests, that principle keeps the trail detailed enough to reconstruct authorization without spreading CUI across dashboards, email exports and screenshots.

Assessment evidence needs a reproducible sample

A CMMC assessment tests implementation, so the contractor should be able to select a routed AI request and walk it through the approved use case, boundary record and policy configuration. The evidence packet needs the user's access state and the model destination approved for that information category, along with the decision record and retention location.

Run paired tests under named identities. One test should use material allowed on the approved route, while another should carry a safe synthetic marker representing a blocked CUI category or prohibited destination. Preserve the requests, policy revision and resulting records. A six-line terminal export beside the boundary diagram often reveals more than a polished dashboard because the reviewer can follow each identifier.

AI audit trail requirements by regulation covers the reusable event fields. Defense work adds contract lineage and CUI scope, plus the evidence needed to reconcile production routes to the system security plan.

The HTTP boundary leaves important exclusions

An enforcement point can inspect LLM traffic deliberately routed through authenticated HTTP applications, evaluate identity and classification before forwarding, then record its own decision. That covers customer-controlled assistants and agents that use the route.

A local model inside an engineering workstation takes another path, as does inference hidden inside a supplier platform when the contractor cannot redirect the call. Personal browser sessions may bypass the approved application. Endpoint controls and browser policy handle those routes, while supplier review and contractual evidence cover opaque services. IAM remains responsible for identity issuance and group membership.

Model accuracy and engineering approval sit outside the gateway too, because a permitted request proves that the route and information class met policy at that moment. It says nothing about the technical correctness of the generated supplier note. Program reviewers retain that responsibility, and the boundary statement should say so plainly.

DeepInspect

DeepInspect is a stateless proxy for authenticated HTTP traffic between contractor users or agents and LLM endpoints. The calling application supplies the originating identity and contract context. DeepInspect evaluates that context with prompt classification, approved destination and versioned policy before forwarding an allowed request.

Each permit, redaction, reroute or block produces a signed per-decision record outside the calling application's write path, and those records can support CMMC sampling for traffic routed through the proxy. DeepInspect does not set CMMC scope, issue identities, govern local inference or validate engineering output. Book a demo today.