US / United States / revised 6 Nov 2026

ITAR and FedRAMP Boundaries for AI Inference

ITAR controls who may receive defense technical data, not only where it is stored, so a prompt containing it can become an export the moment a foreign person, or a server abroad, can read it. FedRAMP answers a different question, whether a cloud service meets federal security baselines, and an authorization does not settle who operates the service. AI inference for defense and federal work has to satisfy both, which in practice means US-located endpoints in environments run by US persons, with the gateway inside the same boundary.

Test a sovereign route Talk to a sovereign architect

Citation: International Traffic in Arms Regulations, 22 CFR Parts 120 to 130 (including 120.33, 120.50, 120.54, 120.56 and 120.62); FedRAMP Authorization Act, 44 U.S.C. 3607 to 3616; DFARS 252.204-7012
Regulator: Directorate of Defense Trade Controls (DDTC), US Department of State, for ITAR; the FedRAMP Board and the FedRAMP Program Management Office at GSA for FedRAMP
In force: 6 September 2022 (restructured ITAR Part 120 definitions); 23 December 2022 (FedRAMP Authorization Act)
Maximum penalty: ITAR civil penalties under 22 CFR 127.10 of more than USD 1.2 million per violation (adjusted annually for inflation) or twice the value of the transaction, whichever is greater; criminal penalties under 22 U.S.C. 2778(c) of up to USD 1 million and 20 years' imprisonment per violation; debarment

Statutory text

Technical data, exports and releases

Technical data under 22 CFR 120.33 includes information required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance or modification of defense articles, such as blueprints, drawings, plans, instructions and documentation, as well as classified information relating to defense articles and services. General scientific, mathematical or engineering principles commonly taught in schools, and information in the public domain, are excluded.

Under 120.50, an export includes sending or taking technical data out of the United States and releasing or otherwise transferring it to a foreign person inside the United States, the deemed export. Section 120.56 defines release to include visual or other inspection by a foreign person that reveals technical data, oral or written exchanges, and the use of access information to let a foreign person access unencrypted technical data. A US person under 120.62 is a US citizen, a lawful permanent resident, a protected individual, or an entity incorporated to do business in the United States; anyone else is a foreign person under 120.63.

For a language model, each of those definitions has a direct counterpart. A prompt asking a model to explain a test procedure for a USML-listed component carries technical data. If the model runs abroad, the request is an export; if a foreign national on the provider's operations team can read the prompt in a log or a support console, that can be a release.

The encryption carve-out, and why inference cannot use it

Section 120.54(a)(5) provides that sending, taking or storing technical data is not an export if the data is unclassified; secured with end-to-end encryption; protected by cryptographic modules compliant with FIPS 140-2 or its successors, or by means of at least comparable security strength to AES-128; not intentionally sent to a person in, or stored in, a country proscribed in section 126.1; and not sent from such a country. Under 120.54(c), the ability to access technical data in encrypted form that meets those criteria is not a release or an export.

That carve-out is what makes compliant file storage on commercial clouds workable. It does not carry over to inference. End-to-end encryption, as the rule defines it, keeps data unreadable between the originator and the intended recipient, with no third party holding the means of decryption, while a model can only process plaintext. At the moment of inference the technical data is decrypted on the provider's hardware, and the analysis returns to where that hardware is and who can access it.

Enforcement

DDTC enforces the ITAR through civil penalties, consent agreements that frequently impose an external special compliance officer and audits, and debarment; criminal violations are prosecuted by the Department of Justice. Manufacturers and exporters of defense articles must register with DDTC under Part 122, and a voluntary disclosure under 127.12 is treated as a mitigating factor. A misrouted prompt is exactly the kind of event a voluntary disclosure procedure has to anticipate.

FedRAMP: impact levels and what an authorization proves

FedRAMP standardises security assessment and authorization of cloud services used by federal agencies. The FedRAMP Authorization Act, enacted on 23 December 2022 as part of the FY2023 National Defense Authorization Act, put the program into statute. Authorizations follow the FIPS 199 impact levels of Low, Moderate and High, each tied to a NIST SP 800-53 baseline; Moderate covers most controlled unclassified information, and High is for systems where a loss of confidentiality, integrity or availability would have a severe or catastrophic effect.

A FedRAMP authorization is not an ITAR determination. Whether foreign persons can access a service depends on how the provider staffs and operates that particular environment, which is why major providers run separate government environments with US-person operations for export-controlled work. Defense contractors face a further layer: DFARS 252.204-7012 requires cloud services that store, process or transmit covered defense information to meet security requirements equivalent to the FedRAMP Moderate baseline.

FedRAMP 20x

In March 2025 GSA announced FedRAMP 20x, which replaces document-heavy, control-by-control assessment with automated validation built on Key Security Indicators and continuous monitoring. FedRAMP reports that 20x is in Phase 3, wide-scale adoption: certification Classes A, B (Low) and C (Moderate) are available, Class D for High impact is to be developed in Phase 4, and FedRAMP will stop accepting new Rev5 certifications on 11 June 2027. Since August 2025 FedRAMP has also prioritised authorization of AI cloud services that give federal staff access to conversational AI.

For buyers the practical consequence is that authorization status, and the class or level granted, must be read from the FedRAMP Marketplace when a route is approved and re-checked over time. The set of AI services available inside authorized environments is changing faster than it used to, and a route that was out of bounds last quarter may be in bounds now, or the reverse.

Technical requirements for the inference path

01
US-person operations as an endpoint attribute
Record for each endpoint whether it is US-located, whether its environment is restricted to US-person operators, and who can reach its logs and support tooling. Government environments such as AWS GovCloud (US) and Azure Government exist for this purpose; a commercial US region generally carries no such restriction.
02
Put the gateway inside the boundary
The gateway reads every prompt, so it is part of the export analysis too. ITAR workloads run on YTT Secunet Sovereign Dedicated, deployed in the customer's GovCloud account, Azure Government subscription or on-premises enclave and administered by the customer's US-person staff. YTT Secunet personnel, many of whom are foreign persons, have no access to traffic, logs or keys.
03
Label at the source, not by guesswork
Classifiers can spot export control markings and distribution statements, but jurisdiction and classification decisions belong to the export control function, not to a model. Label traffic by project or enclave at the source, and treat unlabelled requests from an ITAR project as ITAR by default.
04
No retention and no offshore review
Hosted providers may keep prompts for abuse monitoring and route flagged content to human reviewers. For ITAR endpoints, require zero data retention and confirm in the provider's terms for the government environment that any human review is performed by US persons, or not at all.
05
Outputs, embeddings and fine-tunes
A completion that explains or extends technical data may itself be technical data, and so may embeddings or fine-tuned weights built from it. Keep those artefacts inside the boundary and handle them as controlled until the export control function has reviewed them.

Prescribed YTT Secunet routing rules

#	Rule	Legal rationale
01	ITAR-labelled requests resolve only to endpoints that are US-located, in an environment with US-person operations, and running with zero data retention.	Prevents both a physical export and a release to a foreign person under 120.50 and 120.56.
02	ITAR traffic is accepted only by a Sovereign Dedicated data plane inside the customer's authorization boundary, never by the multi-tenant service.	The gateway sees the plaintext prompt, so it must sit where only US persons can administer it.
03	Federal data resolves only to endpoints whose FedRAMP level or class meets or exceeds the data's impact level.	Agencies may use a cloud service only at the impact level its authorization covers.
04	Covered defense information requires at least a FedRAMP Moderate equivalent endpoint.	DFARS 252.204-7012 sets that minimum for cloud services storing, processing or transmitting covered defense information.
05	Government endpoints fail over only to another endpoint inside the same authorization boundary; otherwise the request fails closed.	A fallback to a commercial region during an outage would be an unauthorized export or an out-of-boundary disclosure.

Policy pack excerpt

us-itar-fedramp-boundary

The rules above, written as Open Policy Agent Rego (v1 syntax). The gateway evaluates the pack in-process in every regional data plane before forwarding a request; YTT Secunet measures median evaluation under 3 ms in production.

Packs are versioned and signed. The version that decided each request is named in the residency receipt, so an auditor can match the decision to this exact text.

How the policy engine works

regous-itar-fedramp-boundary.rego

package yttsecunet.policies.us_itar_fedramp_boundary

import rego.v1

levels := {"low": 1, "moderate": 2, "high": 3}

itar_ok if {
	input.endpoint.country == "US"
	input.endpoint.environment == "government"
	input.endpoint.us_person_operations
	input.endpoint.zdr
	input.dataplane.deployment == "sovereign_dedicated"
	input.dataplane.boundary == input.tenant.authorization_boundary
}

deny contains "ITAR technical data outside a US-person-operated boundary" if {
	input.request.label == "itar"
	not itar_ok
}

deny contains "endpoint has no FedRAMP authorization on record" if {
	input.request.label in {"federal", "cdi"}
	not levels[input.endpoint.fedramp_level]
}

deny contains msg if {
	input.request.label in {"federal", "cdi"}
	required := object.get(input.request, "impact_level", "moderate")
	levels[input.endpoint.fedramp_level] < levels[required]
	msg := sprintf("endpoint authorized at %s, data requires %s", [input.endpoint.fedramp_level, required])
}

deny contains "failover may not leave the authorization boundary" if {
	input.route.is_failover
	input.endpoint.boundary != input.route.primary_boundary
}

default allow := false

allow if count(deny) == 0

ITAR and FedRAMP: frequently asked questions

Is a FedRAMP High service automatically suitable for ITAR data?

No. FedRAMP High is a security baseline. ITAR turns on whether foreign persons can access the technical data and where it is processed, so the question is how that specific environment is staffed and operated. Providers run separate government environments for this reason.

Can we rely on the ITAR encryption carve-out for prompts?

Not for inference. Section 120.54(a)(5) covers sending, taking and storing technical data that stays end-to-end encrypted. A model has to decrypt the prompt to process it, so inference must run where no foreign person can access the plaintext.

Does YTT Secunet hold a FedRAMP authorization?

No. Federal and ITAR workloads run on Sovereign Dedicated inside the customer's own authorized environment, so the authorization boundary is the customer's GovCloud, Azure Government or on-premises system, operated by the customer's US-person staff.

What does FedRAMP 20x change for AI services?

It moves assessment toward automated, continuous validation and shorter timelines, and FedRAMP has prioritised AI services that give federal staff access to conversational AI. Authorization status and level still have to be checked for each service and environment before data is routed to it.

Sovereign route ready

Stop risking 4% global turnover GDPR fines on AI inference.

Deploy sovereign, cryptographically proven AI routing in 15 minutes.

Schedule an architecture demo Start 14-day trial