Why FedRAMP Isn't Enough for AI: The Case for a Model Authorization Boundary

What FedRAMP is actually for

FedRAMP authorizes a cloud service provider's infrastructure against a defined set of NIST SP 800-53 controls. That is its job, and it does it well. It answers a specific, important question: is this environment secure enough to run government workloads? Access control, encryption, boundary protection, incident response, configuration management, the whole apparatus exists to give an Authorizing Official the evidence to say yes to that question with confidence.

And the program is not standing still. The 2026 overhaul, FedRAMP 20x, consolidated into a single ruleset finalized on June 25, 2026, even retires the old "FedRAMP Authorized" label in favor of "FedRAMP Certified." It is a real modernization, and it is overdue. But notice what did not change. FedRAMP 20x is still, at its core, an infrastructure certification. It tells you the environment is sound. It was never designed to tell you what the model running inside that environment will decide to do next Tuesday. That is not a criticism of the overhaul. It is just the edge of what the framework is for.

The assumption AI quietly breaks

Every authorization has an unspoken assumption baked into it: the system you authorize today will behave tomorrow the way it behaved during assessment. For deterministic software, that assumption holds. The code you assessed is the code that runs. Change it materially and you trigger a review. Clean, and it has worked for decades.

A model does not honor that assumption. It moves after the signature, in at least three ways. It moves when the model is updated or the version is bumped (i.e., a new set of weights is a new system, even when not a single line of surrounding code changed). It moves when the world drifts underneath a static model (i.e., the data distribution the model sees in production stops matching the one it was evaluated against). And it moves when the inputs change what it does in the field (i.e., a prompt or a retrieved context can push behavior into territory no test case covered). The ATO still says "valid." The behavior has already walked off. So what, exactly, is still authorized?

Make it concrete. A model is assessed and lands at, say, 93% on the validation set the AO reviewed. It gets its authorization. Six months later the population it scores has shifted, a vendor has pushed a minor version update, and the false-positive rate on one subgroup has crept up in a way nobody watched for, because nothing in the authorization asked anyone to watch. The infrastructure has not changed. Not one control has failed. The FedRAMP posture is still green, and the ATO is still valid on paper. The only thing that changed is the thing the authorization never actually covered: what the model does. That is not a hypothetical failure mode. It is the normal life of a deployed model, and our authorization paperwork is blind to all of it.

Naming the gap

The gap is the difference between authorizing where a model runs and authorizing what it does. FedRAMP, and the SSP that sits under it, describe the first with real rigor. Nothing in the stack describes the second.

To be fair, the rest of federal policy has started moving toward the problem, and it is worth giving credit precisely. OMB's M-25-21, issued in April 2025, stood up the governance layer: Chief AI Officers, agency AI governance boards, and heightened risk management for high-impact AI. That matters. But it is organizational governance (i.e., who is accountable and what process they follow), not a control boundary drawn around the model's behavior inside an authorization package. It tells you a human owns the risk. It does not tell the AO what specifically was authorized about the model.

The closest thing to what I am describing is NIST's COSAiS effort (i.e., Control Overlays for Securing AI Systems), which adapts SP 800-53 to AI and reached an annotated outline in draft form in January 2026. It is genuinely the right direction, and I am glad it exists. But read carefully, an overlay hardens the controls around an AI system. It treats the model as an asset to be protected. What I am arguing for is one step further: treating the model's behavior as the thing under authorization, not just the thing under protection. Those are related, and they are not the same.

What a model authorization boundary would actually include

So let me be constructive instead of just provocative. If we were going to authorize a model's behavior the way we authorize infrastructure, three things would have to become first-class.

First, model weights as an information asset class. Today a set of weights is treated as a file sitting on authorized storage, no different from any other blob. That is wrong. A weight set has provenance, integrity, and a version identity, and swapping it is a system change even when zero infrastructure changed. Give it an asset class, a lineage record, and a change-control path of its own.

Second, inference-time telemetry as continuous monitoring evidence. Continuous monitoring today watches infrastructure: patch levels, scan results, configuration drift. For AI, the evidence that matters is behavioral: output distributions, allow and refusal rates, confidence bands, and the variance signals that flag when a model starts answering differently than it did at assessment. The model's runtime behavior is not a nice-to-have dashboard. It is the continuous-monitoring artifact.

Third, post-deployment drift as a re-authorization trigger. We already accept that a significant change to a system boundary re-opens authorization. Drift is that same event, it just does not announce itself with a change ticket. Define the authorized behavioral envelope, instrument for it, and make a breach of that envelope a formal re-authorization trigger, on equal footing with a boundary change.

Tie those three together with something concrete: an AI Addendum to the SSP. Not a new framework, an addendum. It names the model and its version identity, states the authorized behavioral envelope in measurable terms, points to the telemetry that proves the model is inside that envelope, and specifies the drift thresholds that re-open the authorization. Think of it as the one document that lets an AO answer a question they cannot answer today: not "is the environment secure," but "is the model still behaving the way I authorized it to." The SSP has no vocabulary for that question right now. It should.

But isn't this already someone's job?

The fair pushback is that pieces of this already exist, so why invent a new boundary. Continuous monitoring already runs. M-25-21 already names an accountable officer. The vendor already tracks model versions. All true, and none of it closes the gap, because each of those pieces is pointed somewhere else. Continuous monitoring is aimed at the infrastructure, not the model's outputs. The accountable officer owns the risk on paper but has no authorization artifact that says what the model was permitted to do. The vendor tracks versions for their release process, not for your ATO. The parts are lying around. Nobody has assembled them into a boundary that an Authorizing Official can actually sign.

The other objection is harder, and I take it seriously: behavior is a distribution, not a line, so how do you authorize something that is probabilistic by nature? You do it the way we already handle other probabilistic controls, with thresholds and confidence intervals rather than absolutes. An authorized envelope is not "the model is always right." It is "the model stays within these measured bounds, and when it does not, authorization re-opens." That is harder than authorizing a static system. It is not harder than pretending a static-system framework already covers it.

Here is what I see

The uncomfortable part is that you do not actually need to wait for policy to catch up to start doing most of this. You can define a behavioral envelope for a model now. You can wire inference telemetry into your continuous monitoring now. You can write an AI Addendum to your SSP now, and set drift thresholds that trigger a review, whether or not any framework requires it yet. The teams that do this will be ready when the requirement lands (and it is coming). The teams that wait will be reverse-engineering a behavioral boundary the week before an assessment, which is the worst possible time to draw one.

I want to be honest about where I could be wrong, because this is a position, not a settled fact. Maybe COSAiS matures into exactly this and the gap closes on its own. Maybe the AO community looks at behavior-based re-authorization and decides it is operationally unworkable at scale. Maybe there is a cleaner way to bound a stochastic system than the one I am proposing. I would genuinely rather be argued out of a detail here than be quietly agreed with and left unchallenged. If you run ATOs for AI systems and you think I have this wrong, I want to hear it.

In an earlier post in this series I argued that the authorization boundary breaks when agents call agents, when the system's behavior emerges from interaction rather than code. This is the same crack, one layer down: the boundary breaks when the thing inside it can change its own behavior after you have signed. Both point at the same conclusion. Authorization built for fixed systems needs new machinery for systems that move. Later in the series I will get into where that machinery actually lives: how continuous ATO and continuous delivery have to meet in one pipeline for AI.

FedRAMP tells you the room is secure. It says nothing about what the model in the room decides to do tomorrow. That is the boundary we still have to draw.

—-

Shailesh Patel is CTO of Keystone International Ventures and a SAFe Program Consultant (SPC). He writes about the intersection of AI architecture, federal technology, and the delivery frameworks that connect them.