.svg){kind=icon}
Learn
Accredited AI deployment is the process of fielding AI in U.S. government environments under the Risk Management Framework, so the system earns an authorization to operate at a specified DoD cloud impact level with documented, audit-ready controls.
Why it matters to your mission. AI that cannot earn an authorization to operate never reaches the people who need it, no matter how strong the model is. Deploying under the Risk Management Framework with documented, audit-ready controls is what gets it fielded at the right impact level. The outcome is capability in operators' hands sooner, on a repeatable accreditation path instead of a one-off scramble.
Accredited AI deployment is the process of fielding AI in U.S. government environments under the Risk Management Framework, so the system earns an authorization to operate at a specified DoD cloud impact level with documented, audit-ready controls.
Accreditation is a process, not a product feature. AI that handles mission data must inherit the same authorization discipline as any other government system: assessed controls, a named authorizing official, and a defined authorization boundary. Fragmented data already increases decision risk; deploying unaccredited AI on top of it adds compliance risk and can block fielding outright. Treating accreditation as an engineering requirement from day one, not a certification chased after the build, is what makes AI usable in the environments where the mission actually runs.
Key takeaways
Standard software accreditation assesses a fixed set of controls against a stable system. AI breaks three of those assumptions at once, which is why "we will accredit it later" is where most defense AI efforts stall.
First, the system changes. A model retrained on new data is, from a control-assessment standpoint, a new system state. An accreditation approach built for annual re-authorization cannot keep pace with a model that updates on a mission timeline. Second, the data is load-bearing. Training and reference data carry their own provenance, classification, and releasability, so the authorization boundary has to cover the data pipeline and not only the application. Third, the output has to be defensible. An authorizing official accepting risk on an AI system needs to see why it produced a given result, which means traceability and an audit trail are accreditation requirements, not nice-to-haves.
The U.S. government has made clear it intends to field AI at scale while holding it to this discipline, which is exactly the tension accredited deployment resolves: get the model into the mission environment without lowering the authorization bar.
The Risk Management Framework is the disciplined, repeatable process the federal government uses to authorize a system to operate. It is defined in the National Institute of Standards and Technology's NIST Special Publication 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations, which sets out categorizing the system, selecting and implementing controls, assessing those controls, and then authorizing the system. The authorization decision is the authorization to operate (ATO): a named authorizing official formally accepts the residual risk of running the system within a defined boundary.
RMF also names the mechanism that makes modern AI deployment viable. SP 800-37 Rev. 2 describes continuous monitoring and ongoing authorization, giving senior leaders the near-real-time information to keep making risk decisions as the system changes rather than only at a point in time. That ongoing-authorization idea is the doctrinal root of continuous ATO.
Impact levels classify the sensitivity of the data a system is authorized to host, and they decide where AI can run. Under the DISA Cloud Computing Security Requirements Guide (CC SRG), IL5 covers higher-sensitivity controlled unclassified information and unclassified National Security Systems, while IL6 covers classified information up to SECRET and must run on dedicated, isolated infrastructure rather than shared commercial cloud. TS/SCI data sits in a tier above IL6 and is not an official named impact level, so it should not be labeled "IL7."
For AI, the impact level is not a formality. It determines which mission data the system is allowed to reason over, what infrastructure it can be hosted on, and therefore what the capability can actually do. An AI accredited only at IL5 cannot be pointed at SECRET holdings; fielding against classified data means an IL6 authorization on isolated infrastructure.
A traditional authorization to operate is a point-in-time decision that expires and has to be renewed. Continuous ATO (cATO) replaces that periodic re-authorization cycle with ongoing monitoring, automated control checks, and a continuously maintained security posture, so authorization keeps pace with code and model changes rather than lagging them. It is the operational expression of the ongoing authorization described in NIST SP 800-37 Rev. 2.
cATO is not a shortcut around controls; it is a higher bar. It depends on a mature DevSecOps pipeline, continuous visibility into the authorization boundary, and active monitoring of the system's security state. For AI specifically, cATO is what lets a model be updated and re-deployed without dropping out of authorization, which is the difference between a system that evolves with the mission and one frozen at the state it was first accredited in.
Zero trust assumes no implicit trust based on network location and verifies every access request. The DoD Zero Trust Reference Architecture and the CISA Zero Trust Maturity Model both describe a shift from a location-centric model to a data-centric one, where protection follows the data itself and access is a least-privilege, per-request decision.
For AI, that principle is decisive. A reasoning system that can see data has to enforce authorization at the data layer, not just at the network perimeter, so it only surfaces what a given user and mission are cleared to see. Zero trust is what keeps an accredited AI system from becoming an aggregation risk: the model reasons across sources, but entitlement is checked on every request rather than assumed once at the boundary.
Transfer between separate security domains is governed, not ad hoc. Per DoD Instruction 8540.01, Cross Domain (CD) Policy, any transfer of data between security domains must use an accredited cross domain solution (CDS) operating under defined controls. An AI deployment plan that spans classification boundaries has to account for this control rather than assuming data can flow freely between an IL5 environment and an IL6 one.
This is a common blind spot in AI fielding plans. A model that needs both unclassified open-source reporting and classified holdings does not get to merge them casually; the data path across domains is itself an accredited component, and the deployment design has to show it.
Torch.AI builds government-owned reasoning infrastructure designed to deploy and accredit in mission environments, and to complement existing systems of record rather than replace them. ORCUS is the government-owned data-availability layer that runs in accredited environments; NEXUS makes data meaningful; and HALO makes relationships understandable. Every determination preserves an audit trail, which is exactly the traceability an authorizing official needs to accept risk on an AI system.
Because the infrastructure is government-owned and auditable, the authorizing official retains ownership of the authorization boundary and the control evidence rather than depending on a vendor to produce them. The reasoning layer enforces entitlement at the data layer, consistent with zero trust, and is built to operate at the appropriate impact level rather than assuming a single pooled environment. You can see how this is packaged as a capability on the Torch.AI software page.
STIG hardening and a DevSecOps software factory support this work by producing consistently configured, continuously scanned builds that feed the RMF evidence package and make a path to continuous ATO realistic. The result is AI that can be authorized, and re-authorized as the model changes, not just demonstrated.
The terms above are often used loosely. The table separates them so each can be cited on its own.
| Element | What it is | Why it matters for AI deployment |
|---|---|---|
| RMF | The Risk Management Framework control process (NIST SP 800-37 Rev. 2) | The path to an ATO; accreditation is this process |
| ATO | Authorization to operate: an official accepts residual risk within a boundary | Without it, the AI cannot be fielded, regardless of model quality |
| IL5 | Sensitive unclassified and unclassified National Security Systems | Hosts most mission data outside the classified tier |
| IL6 | Classified up to SECRET, on dedicated isolated infrastructure | Required to field AI against SECRET data |
| cATO | Continuous authorization via ongoing monitoring and automated checks | Keeps authorization current as the model and code change |
| Zero trust | Data-centric, verify-every-request access model | Enforces authorization at the data layer, not the perimeter |
| Cross domain solution | Accredited transfer between security domains | Required to move data across classification boundaries |
A defensible accreditation plan is built in from the start. Require these:
Scoping an accreditation path? The seven requirements above are the backbone of an accredited-AI-deployment evaluation. Bring them to a scoping call and we will walk each one against your environment and target impact level: request a technical walkthrough.
Because the system changes when a model is retrained, the training and reference data carry their own provenance and classification, and the output has to be explainable to the authorizing official. The authorization boundary therefore has to cover the data pipeline and the reasoning, not only the application code.
RMF is the federal process for authorizing a system to operate, defined in NIST SP 800-37 Rev. 2: categorize, select and implement controls, assess them, then authorize. The authorization to operate (ATO) is the decision in which a named authorizing official formally accepts the residual risk of running the system within a defined boundary.
Under the DISA Cloud Computing Security Requirements Guide, IL5 covers higher-sensitivity controlled unclassified information and unclassified National Security Systems, and IL6 covers classified information up to SECRET on dedicated, isolated infrastructure. TS/SCI data sits in a tier above IL6 and is not an official named impact level.
Continuous ATO replaces periodic re-authorization with ongoing monitoring, automated control checks, and a continuously maintained security posture, so authorization keeps pace with code and model changes. It is the operational form of the ongoing authorization described in NIST SP 800-37 Rev. 2 and depends on a mature DevSecOps pipeline.
Zero trust verifies every access request and shifts protection from the network perimeter to the data itself. For AI it means enforcing authorization at the data layer, so a reasoning system surfaces only what a given user and mission are cleared to see, rather than trusting a single perimeter decision.
Per DoD Instruction 8540.01, any transfer of data between separate security domains must use an accredited cross domain solution operating under defined controls. An AI deployment that spans classification boundaries has to design that data path in as an accredited component, not assume data can flow freely.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
