Aligning the model was never intended to control it.

      Most AI roadmaps rely on a subtle assumption: that laboratories will eventually release a model that is safe and aligned enough to be trusted in production settings. With improved training, enhanced safeguards, and just one more iteration, the model will function correctly.

      Here lies the flaw in that assumption. Even a perfectly aligned model cannot provide information about who utilized it, what data was used, under which policy, or supply an auditable record. These aspects do not pertain to the model's behavior but rather to its deployment, existing entirely outside its weights. A better model addresses a different inquiry than what regulators, auditors, and security teams are genuinely asking, and the divide between those inquiries is where the true risk resides.

      Security engineering identified this trap fifty years ago. A 1972 study by the US Air Force defined the reference monitor as the component that determines whether an action is permissible, establishing three criteria for trusting it: it must be tamperproof, invoked for every access, and small enough for complete verification.

      A contemporary frontier model does not satisfy any of those criteria. Alignment attempts to ensure that the model abides by the rules intended to constrain it from within, while governance must exist outside the model itself.

      Safety is not equivalent to governance.

      The confusion stems from a single term. Safety and alignment focus on whether a model generally behaves properly. This is a characteristic embedded in the weights, and laboratories have indeed become proficient at shaping it. Governance poses different questions: who used what model, with which data, under whose policy, and accompanied by an auditable record. This pertains to the specific deployment of the model. Training can influence the first aspect, but it cannot, by its very nature, fulfill the second. Mistaking them as a single issue is the fundamental error underlying most discussions about AI risk.

      The problem extends beyond the model, and it is expanding.

      This is not merely a niche concern for laboratories. It affects all who deploy AI, and it is growing for two reasons.

      Firstly, models are acquiring agency. When a model only generated text, a negative interaction simply resulted in an incorrect answer. Now, models perform actions via tools and protocols like MCP, making each tool call a fresh decision regarding who is acting, with what data, and under whose authority. These decisions multiply with each task and user involved.

      According to OWASP’s 2026 tracking, many agentic projects it monitors are coding agents, and prompt injection aligns with six of the ten risks on its top-10 list for agentic projects. The unregulated surface expands as adoption increases.

      Secondly, accountability has legal implications. California’s SB 53 and European Union regulations for general-purpose AI impose obligations on laboratories, while the EU AI Act also assigns distinct responsibilities to deployers. Additionally, data-protection laws already hold organizations accountable for how they use personal data.

      When a regulator inquires about what your AI did, answering “we utilized an aligned model” is insufficient. A vendor’s safety report will not clarify who within your organization submitted what data to which model last Tuesday.

      Public benchmarks do not provide assistance either. StrongREJECT, HarmBench, and AgentHarm assess the model based on generic prompts rather than your specific users, data, or policies on any given day. A high score indicates a model characteristic, not an audit trail.

      Therefore, the scope is broad and concrete: every organization deploying AI faces this growing surface, with liabilities that are now enforceable. None of this constitutes a model-quality issue.

      Why aligning the model won’t resolve the problem.

      Revisiting the 1972 test reveals exactly where solutions cannot reside.

      A model is not tamperproof. Prompt injection, a term introduced in 2022, functions because instructions and data travel through the same text channel, meaning a document read by the model can overwrite its given instruction.

      Four years later, this issue remains unresolved: OWASP indicates uncertainty about foolproof prevention, and a 2026 paper posits that agents may always be susceptible. A control that can be altered by the input it is examining is not a genuine control.

      A model cannot reliably function as a gate. When given tools, it becomes a classic example of the "confused deputy," a term from 1988 that describes a trusted program deceived by an untrusted caller into misusing its authority, as it cannot distinguish between an instruction and the data it reads.

      A model is not verifiable. You cannot scrutinize billions of opaque parameters like you can audit a compact enforcement kernel.

      Failing all three criteria does not lead to the conclusion of “align harder.” Rather, it indicates that the model cannot act as the enforcement mechanism; enforcement must be implemented externally.

      The solution involves creating a layer surrounding the model.

      Since the model cannot regulate itself, the answer does not lie in developing a better model but in establishing a thin control layer around it—one that treats the model as an untrusted