RMFInsider

If you are trying to figure out how to get an ATO for an AI system in the DoD, the first thing you need to unlearn is the idea that the model itself gets authorized. It doesn’t. The large language model, the fine-tuned classifier, the predictive tool your program office just licensed — none of that goes through a traditional Risk Management Framework authorization on its own. What gets an ATO is the system that hosts it: the infrastructure, the pipeline, the boundary the model sits inside. The model rides through a separate lane called Assess Only. Confusing the two is the fastest way to stall a package or, worse, submit the wrong body of evidence to your AO.

This split isn’t a technicality. It changes who owns what evidence, which eMASS record the AI component lives in, and what your continuous monitoring plan has to cover going forward. Here’s how it actually works, and what to do if your program bought an LLM tool last week and nobody has explained any of this yet.

How to Get an ATO for an AI System: The Model vs. Infrastructure Split

Under the DoD AI Cybersecurity Risk Management Tailoring Guide, an AI model is treated as a component that inherits its operating environment’s security posture rather than standing up its own authorization boundary. The hosting system — the servers, the containers, the API gateway, the identity and access controls wrapped around the model — is what receives a standalone ATO, and it follows the RMF or cATO path you already know: categorize, select, implement, assess, authorize, monitor.

The model itself routes through the Assess Only construct instead. That means it gets evaluated on its own merits — performance, bias, data lineage, output integrity — without being forced through a full six-step RMF cycle as if it were a standalone information system. Assess Only produces a body of evidence that the hosting system’s AO then considers as part of the overall risk picture, but the model doesn’t get its own authorization decision separate from the system it lives inside.

If you’re the ISSO on this, that means two different evidence streams landing on two different timelines, and you need to know which one is your responsibility and which one belongs to whoever stood up the Assess Only evaluation for the model.

What Actually Needs Authorization: Hosting Infrastructure

Your ATO boundary is the infrastructure the AI model runs on top of. That’s not a new category of system — it’s the same categorization exercise you’d run for any information system, with a few AI-specific wrinkles layered in:

• Data flow boundary. Where does data enter the model, where does inference output go, and does either path cross a classification or CUI boundary the current SSP doesn’t already account for?
• API and integration surface. Every endpoint the model exposes or consumes is part of your attack surface and needs to show up in your control implementation, not just the compute layer underneath it.
• Identity and access to the model itself. Who can query it, who can retrain or fine-tune it, and is that access logged the same way you’d log access to any other privileged function?
• Inherited controls from the platform. If the model runs on a cloud.mil enclave or an existing DevSecOps pipeline, you inherit a chunk of your control baseline — but you still have to document the inheritance, not assume it.

None of this is exotic if you’ve built an ATO package before. The hosting system still needs a System Security Plan, a control baseline appropriate to its categorization, and a POA&M for anything that doesn’t fully implement on day one. The AI-specific piece is making sure your SSP explicitly names the model as a component and describes how the Assess Only body of evidence factors into the AO’s risk determination — don’t let it sit as an undocumented dependency.

Mapping the Tailoring Guide to Actual eMASS Steps

Here’s roughly how this plays out inside eMASS, translated from guidance language into the workflow you actually click through.

Step 1: Register the hosting system, not the model

The registration record in eMASS belongs to the infrastructure. If you’re new to standing up a system record from scratch, the mechanics are the same ones covered in eMASS for Beginners — you’re not doing anything different because AI is involved, you’re just adding a component.

Step 2: Document the model as a component with a pointer to its Assess Only record

Inside the system’s hardware/software list, the model gets logged as a component. Its Assess Only evidence — performance testing, data provenance, output validation — doesn’t live in the same control implementation narrative as your infrastructure controls. It’s referenced, not duplicated.

Step 3: Select and tailor the control baseline for the hosting system

You’re still picking a baseline off your categorization, same as always. If this is your first time walking that process end to end, How to Get an ATO Step by Step covers the categorize-through-authorize sequence in more depth than this post needs to repeat.

Step 4: Build the combined body of evidence

Your AO wants two things side by side: the infrastructure’s control assessment results, and the model’s Assess Only package. Neither replaces the other. If your test team hands you only the infrastructure SAR and calls the package done, you’re missing half of what the authorization decision needs.

Step 5: Authorize the system, monitor both halves

The ATO gets issued to the hosting system. Continuous monitoring afterward has to track infrastructure drift the way it always has, plus whatever cadence the Assess Only sponsor set for re-evaluating the model — retraining, data drift, new fine-tuning runs. Put that cadence in your continuous monitoring plan explicitly, because nobody else is going to track it for you.

If your organization is already moving toward continuous authorization for this system, the AI component doesn’t exempt you from that model — it just adds another thing your monitoring plan has to watch.

My Program Just Bought an LLM Tool. What Do I Do Monday?

This is the question that actually lands in most ISSO inboxes, so here’s the short version:

• Find out where it’s hosted. Is this running inside an existing authorized boundary, or does it need a new system record entirely? That answer determines whether you’re amending an SSP or starting from zero.
• Ask who owns the Assess Only evidence. If the vendor or a DoD AI office already ran an Assess Only evaluation, get that package. If nobody has, that’s a gap you need to flag to your AO before the tool goes into use, not after.
• Update your SSP to name the model as a component. Don’t let it sit as shadow IT inside a system that’s already authorized — undocumented AI components are exactly the kind of finding that turns into a CAT II on your next assessment.
• Flag data flow changes. If the tool sends queries or data outside your existing boundary — including to a vendor’s cloud endpoint — that’s a new interconnection that needs its own documentation and possibly its own risk acceptance.
• Loop in your AO early. AOs are still building comfort with what an AI component means for their risk decision. Don’t let them find out about it during your next annual assessment.

None of these steps require you to become an AI specialist. They require you to treat the model the way you’d treat any new component landing inside your boundary: document it, figure out what evidence exists, and close the gap on what doesn’t.

Where This Framework Is Headed

This isn’t a finished framework yet. The Secretary of Defense was tasked with standing up a cross-functional team to build this out further by June 2026, with the fuller framework expected complete by June 2027. That means the exact mechanics of Assess Only — what documentation it requires, how often models get re-evaluated, how it interacts with cATO — are still being formalized. What’s already settled, and what you can act on now, is the core split: model goes through Assess Only, hosting infrastructure gets the ATO. Build your package around that boundary and you won’t have to redo the structural work when the rest of the guidance lands.

It also means AOs are making judgment calls right now with incomplete guidance. If your system’s AI component doesn’t fit neatly into what’s published so far, that’s not a sign you’re doing it wrong — it’s a sign this framework is still under construction.

If Your Program Is Navigating This Right Now

AI components are showing up inside ATO boundaries faster than most eMASS guidance can keep pace with, and getting the Assess Only split wrong in your SSP is the kind of thing that surfaces during assessment, not before. If you want a second set of eyes on how your program is structuring an AI-in-the-boundary package before it goes in front of your AO, that’s exactly the kind of problem I work through in 1:1 coaching.

The infrastructure-versus-model split is the one concept that keeps ISSOs from wasting weeks routing an AI tool through the wrong authorization path. Get it right at the start of your package, and everything downstream — the SSP language, the eMASS component record, the continuous monitoring plan — falls into place around it instead of getting rebuilt after the fact.