DECISION ARCHITECTURE | TRUSTED ARCHITECTURE | OPEN CAPABILITY
The central AI-policy mistake is regulating access to intelligence instead of controlling the authority of deployed systems.
By Vincent Sullivan, Founder, Cyber Strategy Institute
America is approaching artificial intelligence with the wrong unit of control. The most visible proposals focus on who may obtain advanced models, which institutions may use them, and which providers should retain the power to approve or refuse particular purposes. That may look like safety because it places capability behind a gate. It is not a complete security architecture.
Security has never meant preventing every person from possessing a powerful tool. It means defining what the tool may reach, what authority it may exercise, what evidence it must produce, and how quickly it can be stopped. We do not secure a financial network by licensing every spreadsheet. We secure identities, accounts, transactions, permissions, and recovery. AI should be governed the same way.
Access and authority are different questions
A person may lawfully possess a capable model without giving that model permission to read every file, contact every system, move money, retain every memory, or act without human approval. Conversely, a relatively modest model can become dangerous when connected to privileged credentials, persistent memory, executable tools, and unattended automation. The decisive variable is not merely the intelligence inside the model. It is the authority of the deployed system.
This distinction matters because adversaries do not organize themselves around provider usage policies. Criminal groups, hostile intelligence services, and determined insiders can steal, modify, fine-tune, self-host, or build models outside normal account controls. A policy that reliably restricts compliant users but only inconveniences adversaries produces asymmetric vulnerability.
Dario Amodei has now stated that open-weight models without dangerous capabilities are a public good and that banning their use by U.S. businesses would not solve the primary risks he identifies. That is an important concession. The remaining policy question is how to govern powerful capability without turning provider custody into an institutional privilege.
Five questions replace one label
Terms such as American, Chinese, open-weight, closed, frontier, and safe compress several independent risks into one label. A serious assurance process asks five separate questions:
Capability: What can the model reliably do in the relevant domain?
Continuing control: Who can access, observe, update, disable, compel, or materially alter the deployed system?
Embedded behavior: What censorship, regulatory framing, hidden triggers, values, or failure patterns are already present in the model or its adaptations?
Deployment authority: What data, identities, tools, memory, networks, and real-world actions can the system reach?
Dependency: Can the operator continue the mission if the provider refuses, changes policy, suffers an outage, raises prices, or is prohibited by government action?
No single answer determines the others. A foreign model can be locally hosted with no continuing developer access but still contain unacceptable embedded behavior. A domestic commercial API can perform well while creating a single-provider dependency that the operator cannot control. Evidence must replace inference.
The American doctrine should be broad access, bounded authority
The default should be lawful access. Additional obligations should attach as systems gain consequential authority. A personal research tool and an autonomous agent operating critical infrastructure are not the same risk category. Regulation should follow what the deployment can affect, not the pedigree or institutional status of the user.
For ordinary lawful use, government should enforce existing laws against fraud, unauthorized access, theft, violence, and other harmful conduct. For commercial systems handling sensitive data, it should require transparent data flows, identity controls, auditability, and incident response. For consequential or federal systems, it should add capability profiling, continuous behavioral assurance, strict tool permissions, human escalation, model substitution, and independent review proportionate to the mission.
This is already consistent with federal policy
NSPM-11 directs the national security enterprise to adapt commercial and open-source AI from diverse suppliers, prevent dangerous single-vendor dependence, preserve controllability, and ensure that no commercial entity can prevent use, disable or degrade, or materially modify a mission AI system without federal knowledge and approval. NIST is likewise organizing its agent initiative around open protocols, interoperability, identity, and security.
Those principles point toward a durable national doctrine: trusted architecture, open capability. Government does not need to choose between centralized custody and ungoverned release. It can preserve broad access while placing enforceable controls around data, tools, memory, identity, communications, and action.
Decision architecture is the missing boundary
Runtime controls determine what an AI system may access and do. Decision architecture determines how its output earns authority. Without that second boundary, the most fluent or fastest answer can frame the problem, narrow the options, and move an organization toward commitment before independent judgment occurs.
A complete policy therefore protects three things at once: lawful access to capability, bounded system authority, and the human or institutional ability to compare, challenge, decide, and reverse. The lock belongs on both the execution path and the decision path, not on the citizen.
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.
The lock belongs on the system boundary, not on the citizen.
Safety requirements should follow the power of the deployment, not the pedigree of the user.
