← Blog

AI Audit Trail for Aerospace: DFARS Evidence When CUI Reaches a Model

Parminder Singh
Parminder Singh··5 min read
Summarize with AI

DFARS 252.204-7012 obliges a defense contractor to report a cyber incident within 72 hours and to preserve relevant monitoring data for at least 90 days. Both obligations assume the traffic was monitored. This article maps those clauses onto authenticated requests from engineers and agents to language models, and sets out the per-request record that makes the obligations answerable.

Compliance & Regulationai-complianceaerospacedfarscuidefenseaudit
AI Audit Trail for Aerospace: DFARS Evidence When CUI Reaches a Model

Paragraph (e) of DFARS 252.204-7012 tells a contractor to "preserve and protect images of all known affected information systems" along with "all relevant monitoring/packet capture data for at least 90 days from the submission of the cyber incident report." Now read that clause next to an engineer pasting a fastener stress table into a commercial chat product. No capture of that request exists anywhere, so nothing exists to preserve and the 90-day obligation lands on an empty directory. An ai audit trail aerospace programs can stand behind has to make that traffic visible while the request is still in flight.

I want to work through the three clauses in 7012 that AI usage strains, where the usual monitoring stack goes quiet, and what a per-request record has to hold for a contracting officer's question to have an answer.

TL;DR

  • DFARS 252.204-7012 paragraph (e) requires at least 90 days of preserved monitoring data after an incident report, which presumes the AI traffic was captured in the first place.
  • The 72-hour reporting clock in paragraph (c) starts at discovery, and prompt-layer disclosures of covered defense information are frequently never discovered at all.
  • Paragraph (b)(2)(i) pulls in NIST SP 800-171, so the audit and accountability controls apply to the system carrying the request, not only to the file share holding the drawing.
  • The record that answers all three has to name the cleared individual, the destination model and the data classification, and it has to be written where the calling application cannot edit it.

The clause that assumes capture

Paragraph (b)(2)(i) of the clause states that a "covered contractor information system shall be subject to the security requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171." NIST SP 800-171 Revision 3, "Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations," became final in May 2024 and superseded Revision 2. Contractors have spent years mapping those requirements onto file shares, engineering workstations and the PLM system.

An outbound HTTPS request to a model provider rarely appears on that map. On the wire it looks like ordinary web traffic. The proxy logs a domain and a byte count, and the body carrying a tolerance stack or a supplier qualification memo passes without classification.

That gap matters more in this sector than in most, because the covered defense information tends to live in exactly the artifacts an engineer wants help summarising.

The 72-hour clock needs a trigger

Paragraph (c) requires a contractor to rapidly report any cyber incident, which the clause defines as reporting within 72 hours of discovery. The clock runs from discovery rather than from occurrence.

Discovery is where prompt-layer events fail. A misdirected email produces a bounce, a mail gateway alert or a recipient who replies. A prompt containing export-controlled technical data produces a helpful answer and a satisfied engineer. Months can pass before anyone asks a question about it. Discovery, when it comes, often arrives through a provider's security notice or a subcontractor's disclosure rather than through anything the contractor saw.

I will say plainly what a lot of programme security officers already suspect: the 72-hour clock is not the hard part of 7012 for AI, because discovery is. A contractor who can detect a disclosure the same afternoon has a manageable reporting task, and a contractor who learns about it from a third party has a much worse conversation with the contracting officer regardless of how fast the form gets filed.

What the preserved evidence has to contain

Paragraph (d) directs the contractor to submit isolated malicious software to the DoD Cyber Crime Center. Paragraph (e) sets the 90-day preservation floor for images and monitoring data. Neither clause specifies fields, because both assume a conventional intrusion where packet capture and disk images carry the story.

A prompt-layer disclosure needs a different artifact. Per request, the useful record holds the timestamp, the authenticated individual resolved through the company identity provider, that person's clearance and programme access at the moment of the request, the calling application or agent, the destination provider with model name and version, the classification applied to the request body, the policy version that governed the decision, the outcome, and a hash covering request and response.

Two design points carry the weight. Storage has to sit outside the reach of the application that issued the request, so an investigator can treat the record as an independent witness. And retrieval has to run by programme, by contract number and by time range, because the scoping question after an incident asks which contracts were touched, not which users were busy.

Ninety days is a floor well below what programmes actually need. Programme record schedules and the underlying contract usually push the real retention much further out, and our note on audit trail requirements by regulation covers how those horizons stack.

Agents change the identity question

Autonomous agents now file change requests, draft supplier correspondence and query engineering archives inside defense primes. Each of those actions reaches a model over HTTP, generally on a service credential.

A service credential satisfies authentication and destroys attribution. The record shows that a workflow ran, but it cannot show which cleared engineer's instruction set it running, which means the incident scoping question has no answer beyond the name of a microservice. Binding the agent request back to the initiating human, and recording both, keeps the chain intact. We covered the underlying pattern in agentic AI audit trail.

Subcontractor flow-down compounds this. Paragraph (m) obligates the prime to flow 7012 down, so the prime's own record helps only for its own traffic. A tier-two supplier pasting the same drawing into a chat window sits outside the prime's visibility entirely, and the only practical lever there stays contractual.

DeepInspect

DeepInspect is a stateless proxy between authenticated users or agents and any LLM endpoint. Identity resolution, classification of the request body, model routing and policy enforcement run inline on the HTTP request before it leaves for the provider, so the capture that paragraph (e) assumes actually exists.

Each decision writes a signed record holding the authenticated individual, the role and access context, the classification applied, the destination model and version, the governing policy version, the outcome and the timestamp. Records commit to append-only storage before the response returns, retention runs well past the 90-day floor, and retrieval by individual, programme, model version or time range completes in seconds. The enforcement boundary covers authenticated HTTP traffic between your people or agents and the models they call. System security plan ownership, CUI marking decisions, contracting officer communication and the incident determination itself stay where they sit today.

If your 7012 evidence for AI usage currently depends on proxy logs that record a domain and a byte count, the scoping question has no answer waiting for it. Book a demo today.

Frequently asked questions

Does DFARS 252.204-7012 mention artificial intelligence?

No. The clause predates general enterprise LLM use and speaks about covered contractor information systems and covered defense information. AI traffic falls in scope through those definitions instead of by name, which is why the scoping decision belongs in your system security plan and not in a vendor's marketing claim.

If an engineer used a personal account, is it still a reportable incident?

The account type does not decide it. What decides it is whether covered defense information ended up on a system that was not authorized to hold it. A personal account makes that more likely and makes your evidence position worse, since no company-side record of the request exists.

Can the model provider's logs satisfy the 90-day preservation requirement?

They rarely can. Provider logs attribute activity to an API key rather than to a cleared individual, they sit under a retention policy the provider changes at will, and they live outside the boundary the clause describes. Treat them as corroboration for a record you hold yourself.

Does NIST SP 800-171 audit and accountability apply to prompts?

The audit and accountability family applies to systems processing controlled unclassified information. Where an AI request carries CUI, the request path becomes part of that scope, and the audit record needs enough content to reconstruct who did what.