Your ATO Should Survive the Next Model Release.

Every few weeks, somewhere in a program office we work with, the same memo gets drafted. A frontier lab shipped a better model: sharper reasoning, longer context, tighter tool discipline, lower cost. The engineering team wants it. And then someone asks the question that stops the memo cold: does taking it mean going back through authorization?

If the question is hard to answer, the architecture has already answered it. Somewhere in the boundary documentation, “the agent” and a specific model name are the same line. That fusion felt harmless on the day the system was authorized. It is now a standing appointment with the accreditation process, renewed on a release calendar nobody in the building controls.

The fix, in one sentence: keep the agent’s identity stable, treat the model as a swappable capability bound to it, and a model swap becomes a change request adjudicated through a security impact analysis instead of a re-accreditation event.

This closes the loop on the argument I have been making since Agents Are Just Identities. Identity discipline, a governed command surface, and an enforced allow-list all cost effort to build. Model velocity is where that effort pays for itself.

Two clocks, one collision

Two clocks run in every federal AI program, and they do not know about each other.

The first is the release clock. Frontier models version every month or two, and the improvements are material, not cosmetic.

The second is the accreditation clock, and it deserves a precise description, because the lazy version of this argument pretends it is 2019. A full initial authorization still runs six to twelve months when it goes well. But a program holding an agent today is usually not facing a fresh ATO on every change; it operates under continuous monitoring, and the modern postures (ongoing authorization, cATO, the fast-track programs) exist precisely so that change is adjudicated continuously instead of episodically. The honest comparison for a model swap is not “change request versus a year.” It is “change request versus a significant-change determination,” and the cost of that determination depends almost entirely on the architecture underneath it. Fuse the agent to the model and every release raises a significance question the documentation makes expensive to answer. Abstract the model and the same question becomes cheap, which is also what makes a cATO posture survivable against a monthly release cadence in the first place.

Fusion still forces the bad choice; it just forces it in slow motion. Reopen the authorization question on every release, or defer, and defer again. We have watched programs drift onto models two generations stale this way. Sometimes holding is the right call, made deliberately: the accredited model is evaluated, trusted, and doing the job, and the authorizing official’s risk posture says stay. What the fused architecture takes away is the ability to make that a choice. When the swap costs a re-accreditation-shaped fight, deferral stops being a risk decision and becomes the default, and the deficiency list on the old model grows without anyone ever deciding to accept it.

The separation that does the work

The identity is an account. The model is a capability bound to that account, the way a workload’s runtime is a capability bound to a service account.

Concretely, in the system security plan, the agent is a system component with a stable identity: its account of record, its scope, its authorization policy, its oversight tiers, its allow-list, its audit attribution. The model behind it is a configuration item within that component, tracked in the baseline with its exact version (the inventory should always know which model is in production), reached through an abstraction layer: a provider interface, a model gateway, a routing broker. The mechanism matters less than the boundary line. The accredited unit is the component; the model version is a CI within it, and changing a CI is what change management is for.

Look at what survives a swap under that structure, because it is the load-bearing set:

• The account of record and its lifecycle hooks. Unchanged.
• The scope and every named permission in it. Unchanged.
• The enforced command allow-list and its enforcement point. Unchanged, and this matters most: what the new model can execute is bounded by the same control that bounded the old one, because that control never depended on the model’s judgment.
• The oversight tiers. The consequence-to-oversight mapping lives in the scope, not in the model, so a more capable model does not inherit more authority. Capability earns speed, not authority.
• The audit attribution. Same account, same delegation chain, into the same SIEM.

And be honest about what does move, because it is exactly what the security impact analysis exists to examine. Prompt architecture and system prompts are model-specific and usually need re-engineering. Safety and refusal configuration does not transfer. Context and token limits change how the same controls behave at the margins, including what reaches an enforcement check intact. Telemetry can shift: different usage fields, different logging defaults, new metadata landing in the SIEM. None of that is a re-architecture. All of it is security-relevant configuration change, which is why the swap gets an SIA and not a shrug.

The through line from the earlier essays is the payoff here: a boundary built to hold regardless of what the model decides is, by construction, a boundary that can survive the model being replaced.

What a swap still owes

None of this makes a swap a free action, and nobody should sign a risk acceptance that claims it does.

A model swap moves through change management as a change request, and the change request triggers a security impact analysis. The SIA, informed by a behavioral regression run, determines whether the swap stays routine or escalates, and the significance determination belongs to the authorizing official, informed by the ISSM and the ISSO. Not to the vendor, not to the pipeline, and not to the eval suite. The architecture makes the question cheap to answer; it does not get to answer it.

The regression gate itself is behavioral: the program’s evaluation suite, run against the new model inside the real scope, with the real allow-list, against the real tasks. It checks two things. First, that the new model still does the job. Second, and less obviously, that it does not do more than the job. A more capable model finds paths through a task that a weaker one never saw, and some of those paths press against the edges of the scope in ways the old model never did. The deny log from the evaluation run is some of the most honest reading in the program: every denied call is the new model discovering an edge that was already controlled.

And some swaps legitimately escalate past a routine determination. A new vendor. A substantially different model family. A hosting change that moves inference across the boundary, say from in-boundary weights to an external API, which is not a model swap at all but a boundary change wearing a model swap’s clothes, and it drags an interconnection question and usually a FedRAMP inheritance question in with it. The pattern reduces the frequency of re-accreditation. It does not, and should not, reduce it to zero.

Questions for your own shop

Before this becomes a vendor conversation, three questions belong inside the program office, because the abstraction is worthless if the government side cannot operate it.

Ask your ISSM whether the model version is a named configuration item in the SSP or fused into the component definition; the answer tells you which architecture you already have. Ask your authorizing official, in advance and in the abstract, how a model swap would be adjudicated, so the significant-change path is pre-agreed instead of negotiated under deadline. And settle who owns, funds, and runs the evaluation harness on the government side once it is delivered, including whether continuous-monitoring capacity can actually execute a regression gate, because an eval harness the team cannot run is a deliverable that governs nothing.

Questions for your vendors, including us

I will flag my seat plainly: I run engineering at a company that builds agentic systems for federal customers, so a CTO telling you to demand the architecture his teams build deserves exactly the skepticism you are applying right now. Here is the version I can defend.

Ask any agent vendor, Accelera included, to walk through what happens in their architecture the day a materially better model ships. If the walkthrough contains the phrase “and then you would re-accredit,” price that into the offer: that is a subscription to someone else’s release calendar, with your accreditation process as the payment method.

But treat the answer as diligence, not a loyalty test. There are honest reasons an architecture binds tightly to one model: it may be the model the vendor has actually evaluated, red-teamed, and can stand behind, and in a disconnected or air-gapped enclave “provider substitution” can mean choosing between the two models that exist inside the boundary, not the frontier. Swap-ability and assurance genuinely pull against each other; an abstraction layer with a weak gate is how an unevaluated model slides into an authorized boundary under cover of a routine change request. The regression gate is what resolves the tension, and a vendor who binds to one model with a strong evaluation story deserves a different hearing than one who binds to it because the integration is load-bearing.

If the capability belongs in the acquisition, route it properly: hand the contracting officer a capability to evaluate (model abstraction, an evaluation harness delivered with the system, a documented swap procedure), backed by market research showing more than one offeror can meet it, and let the CO and counsel shape language that survives a competition review. Write a requirement only your vendor can satisfy and you have not written a discriminator; you have drafted the other side’s protest.

The models will keep getting better on someone else’s schedule. The identity, the scope, the enforcement, and the audit chain are the program’s own, they compound, and they are what an authorizing official actually accredits.

The model will change on someone else’s calendar. The boundary you accredited will not. Build for the part that stays.