Defense Contractor AI: ITAR Compliance for Technical Data Protection
Defense contractors are under pressure to use AI for faster drawing review, engineering change summaries, supplier coordination, manufacturing troubleshooting, and proposal support. The operational value is real, but so is the risk. Controlled technical data does not stop being controlled because it appears inside a meeting summary, a defect explanation, or a draft email to a teammate. Once engineers, program managers, quality teams, and subcontractors are all using AI in parallel, the weak point is usually not the model itself. It is the lack of a clear runtime boundary. Keeptrusts is useful here because it gives defense teams an enforceable control layer around who can use a route, what export-control terms are blocked, which providers are even eligible to receive traffic, and how evidence is preserved for later review through controls such as RBAC, ITAR/EAR Filter, Data Routing Policy, and Audit Logger.
Use this page when
- You are using AI inside a defense prime, subcontractor, or defense-industrial-base engineering workflow.
- You need to reduce the chance that controlled technical data reaches an unauthorized model provider or user role.
- You want a route pattern that lines up with export review, evidence export, and day-to-day engineering operations.
Primary audience
- Primary: Technical Leaders
- Secondary: export-control officers, Technical Engineers
The problem
Most contractor AI failures are boundary failures. A team starts with a harmless use case such as summarizing a nonconformance report or drafting a supplier clarification. Then someone pastes a controlled drawing excerpt, a subsystem tolerance table, or a program-specific test note into the same route because the assistant already feels convenient. The route has no required identity headers, the provider path is broad, and the event trail is not set up for export-control review. At that point the organization has already made the hard mistake.
Defense contractors also have role sprawl. Design engineering, manufacturing engineering, supplier quality, proposal operations, and program management do not need identical AI access. When every user reaches the same route with the same credentials, there is no technical distinction between a public-domain research request and a request containing technical data from a controlled program. That makes internal policy hard to prove and even harder to enforce.
There is a second problem that is easy to underestimate: derived content still matters. A clean-room summary can still reveal program architecture, subsystem function, export classification assumptions, or release-sensitive performance details. That is why a governance story based only on user training is fragile. Defense contractors need a route that can block obvious export-control terms, restrict who can invoke sensitive lanes, narrow provider eligibility before routing happens, and leave behind evidence that an empowered official or compliance lead can actually review.
The solution
The strongest pattern is to stop treating contractor AI as one universal assistant. Create separate lanes. Keep a public-domain research lane for standards, public filings, and open literature. Put internal program review, drawing support, manufacturing troubleshooting, and subcontractor coordination behind a stricter route. That stricter route should require explicit identity through RBAC, block obvious export-control markers through ITAR/EAR Filter, and reduce the provider set with Data Routing Policy so only targets that declare the right retention and processing posture remain eligible.
This matters because export control is not just a content question. It is also a routing and accountability question. Even if a user avoids the most obvious blocked terms, the provider path still has to match the sensitivity of the work. The documented data-routing-policy lets you exclude targets that do not declare zero-data-retention, training opt-out, in-memory processing, or local-only execution. That is the difference between hoping users make the right provider choice and making the gateway enforce it.
Then add Audit Logger with honest expectations. The current policy is an allow-only audit marker, not a magical immutable archive. That is still useful. It makes the active control visible in the decision stream and pairs cleanly with Export Compliance Evidence when the program needs to show what the route was configured to do and what decisions it emitted. If a subcontractor or government customer asks how technical-data handling is controlled, the answer can move from narrative assurance to route behavior and exported evidence.
Implementation
For a contractor-only technical-data review lane, keep the route simple and defensible. The point is not to encode an entire export-control program in YAML. The point is to make the gateway enforce the first line of runtime discipline every time the route is used.
pack:
name: defense-contractor-technical-data
version: 1.0.0
enabled: true
providers:
targets:
- id: local-engineering-review
provider: ollama
model: llama3.1:70b
base_url: http://localhost:11434
data_policy:
zero_data_retention: true
training_opt_out: true
retention_days: 0
in_memory_only: true
sanitized: true
allow_internet_egress: false
local_only_processing: true
policies:
chain:
- rbac
- itar-ear-filter
- data-routing-policy
- audit-logger
policy:
rbac:
deny_if_missing:
- X-User-ID
- X-User-Role
itar-ear-filter:
blocked_terms:
- technical data
- usml
- export controlled
- missile guidance
fuzzy_matching: true
max_distance: 1
data-routing-policy:
require_zero_data_retention: true
require_no_training: true
max_retention_days: 0
require_in_memory_only: true
allow_internet_egress: false
local_only_processing: true
on_no_compliant_provider: block
log_provider_selection: true
audit-logger: {}
This example does a few important things without pretending to do more than the current runtime supports. It requires identity headers. It blocks clear export-control markers. It filters providers before selection, instead of trusting users to remember which target is acceptable. And it makes audit logging visible in the chain. After that, the cheapest proof loop is operational: run kt policy lint --file ./defense-contractor-technical-data.yaml, start the gateway, tail itar-ear-filter events, and export the resulting decision stream for review. That creates a repeatable compliance motion around the route instead of a one-time architecture memo.
Results and impact
The immediate benefit is fewer accidental spills from ordinary engineering work. Teams can still use AI for internal acceleration, but the route stops obvious controlled terms and blocks non-compliant provider paths before an analyst has to remember the rule manually. That reduces the odds that a convenience workflow turns into an export incident.
The longer-term value is evidence. Contractor compliance teams, empowered officials, and customer reviewers need more than screenshots of a settings page. A route built around ITAR/EAR Filter, Data Routing Policy, and Audit Logger gives them a practical review surface: linted config, event history, and exportable artifacts. That is a much better starting point for supplier governance and program oversight than policy language alone.
Key takeaways
- Defense contractor AI is safest when technical-data lanes are separated from public-domain research lanes.
- RBAC and Data Routing Policy are as important as term filtering because export control is also an access and provider-routing problem.
- ITAR/EAR Filter is a technical guardrail for clear markers, not a substitute for export counsel.
- Audit Logger should be used as an audit marker that feeds evidence workflows, not as a claim of policy-local immutability.
- The best contractor rollout is a small, reviewable route with a repeatable lint, tail, and export loop.