Secure Formal Raising asks how an AI development environment can enforce its rules while a system is still learning. The paper extends Formal Raising from properties of model behavior to properties of the environment, including policy integrity, authorization and confidential data flow. The preprint was submitted to arXiv on November 5, 2026.
How the paper treats evidence
The authors use a four-valued evidence model. Evidence can support a property, refute it, do both or do neither. This makes a difference when information arrives over time. A policy engine can represent a conflict between pieces of evidence and change the permissions available for a proposed operation. A single true-or-false flag would hide some of that state.
The paper also distinguishes the version of the policy from the observations used to evaluate it. A model can be subject to a policy while the environment separately checks whether someone is authorized to change that policy. The same design makes it possible to reason about whether information may flow to a proposed destination.
Why the commit is checked again
The paper’s worked example checks authorization again at commit time. A proposed operation can become invalid while it is waiting, for example when live evidence changes the evaluation of a rule. Rechecking when the operation would actually take effect lets the environment reject it at that boundary. The paper presents this through executable properties and a plain C implementation.
What the example establishes
The work gives security engineers a way to specify and examine the rules around a training or development process. The example ties the security decision to a particular policy and to the evidence available when the decision is made. A team evaluating the approach would need to specify its own privileged operations and the sources of evidence for each property. The paper’s result concerns the behavior of its formal environment and implementation.
Comments