DECISION ARCHITECTURE | TRUSTED ARCHITECTURE | OPEN CAPABILITY
Provider control can be useful, but a nation cannot outsource mission authority to a commercial permission layer.
By Vincent Sullivan, Founder, Cyber Strategy Institute
A hosted model can be convenient, powerful, and responsibly operated. It can centralize updates, monitor abuse, and block some harmful requests. None of that makes provider custody a sufficient security architecture for government, critical infrastructure, or any mission that must remain available under stress.
The difference became visible in 2026. Anthropic temporarily suspended access to Claude Fable 5 and Mythos 5 for all users after receiving an immediate U.S. export-control directive that it could not implement selectively. The models later returned, but the event demonstrated a basic dependency: customers did not control whether the capability remained available. In a separate dispute with the Department of War, Anthropic publicly maintained two use restrictions even while emphasizing its extensive national-security deployments.
The moral merits of those particular restrictions are not the architectural point. The point is that a commercial provider retained the technical and contractual ability to determine whether a government customer could use the model for a lawful mission. That is provider governance, not sovereign mission control.
The custody model confuses moderation with assurance
Centralized providers often describe safety through the actions they can take: monitor accounts, classify prompts, withdraw access, update models, and change safeguards. Those capabilities can reduce some forms of misuse. They can also create an opaque dependency that the customer cannot independently inspect, preserve, or replace.
A provider-controlled system leaves several questions unanswered. Can the operator pin a known model version? Can it verify where inference and telemetry occur? Can it preserve audit evidence after a model update? Can it continue operating during a provider outage or policy dispute? Can it distinguish a lawful emergency action from a prohibited request at mission speed? Can the customer challenge a refusal that disables an essential function?
These are not theoretical objections. They are the standard questions engineers ask about any critical dependency. The difference is that AI providers are increasingly being treated not merely as suppliers, but as continuing governors of downstream operations.
Government policy already recognizes the conflict
NSPM-11 states that no commercial entity or adversary should possess the capability to prevent use of, disable or degrade, or materially modify without federal knowledge and approval an AI system used for national-security missions. That sentence should become a general design principle for consequential federal AI.
The requirement does not mean government must own every model. It means the operator must own the mission boundary. A commercial API can remain one provider in a broader architecture, but it cannot be the sole source of authority, policy, evidence, or continuity.
What a real assurance architecture looks like
A resilient system separates the model from the control plane. The control plane establishes identity, limits tools, filters data, records evidence, governs memory, enforces human approval, detects drift, and can route work to another model. The operator can use a closed model, an open model, or several models without surrendering those functions.
Provider-neutral interfaces and adapters so the system is not welded to one vendor.
Version records and regression tests so changes are visible before they become mission failures.
Local enforcement of permissions, egress, memory, and human approval.
Tamper-evident logs that remain available even when the upstream provider changes.
A tested fallback model for essential functions.
Contract language preserving the operator’s right to disable, roll back, and substitute.
This model does not reject commercial services. It puts them in the correct place: inside a governed architecture rather than above it.
The choice is not trust or distrust
The strongest argument for provider custody is that capable models can be misused and that centralized controls may stop some abuse. That is true. The mistake is assuming that because one control has value, it should become the governing architecture for everyone.
National security and public resilience require defense in depth. Provider controls can be one layer. Runtime enforcement, local evidence, independent evaluation, substitution, and lawful human authority must be additional layers. No private company; however responsible; should become the final arbiter of whether a nation, business, researcher, or citizen may use intelligence for a lawful purpose.
Custody can also control the frame
Provider custody does more than mediate model access. It can shape which sources are retrieved, which uses are refused, which models are available, and which framing reaches the user first. In a saturated information environment, that first frame can become the practical decision default.
A resilient system should therefore retain alternate models, independent sources, and a decision process that does not treat provider confidence as evidence. Custody may be one service model. It should not become the architecture through which a single provider supplies both intelligence and the boundaries of acceptable judgment.
Author note: Vincent Sullivan is the founder of Cyber Strategy Institute and a retired U.S. Air Force lieutenant colonel. His work focuses on runtime AI governance, zero-trust architecture, federal acquisition, and operational resilience.
A provider’s custody of a model is a business arrangement, not a complete security control.
Rent a service when it serves the mission. Never rent the mission’s sovereignty.
