Let the Proof Travel With the Model
Why I am proposing SAIL-GPL, a public draft license that makes signed provenance, honest evaluation and a disclosure contact follow every AI model release and every derivative
A model can change hands in an afternoon.
Someone downloads the weights, fine-tunes them, quantizes the result and uploads it again under a new name. A week later the model is inside a product. By then almost nothing about its origin has survived the journey. Which base model was it? What data shaped it? Was it ever tested against prompt injection? If you found a vulnerability, whom would you tell?
In my work in cybersecurity I keep returning to the same uncomfortable observation. We learned, slowly and painfully, to demand provenance for software. Signed packages, bills of materials and disclosure policies are now normal expectations. For AI models we are still mostly passing files around and hoping.
So I wrote a proposal and published it as a public draft. It is called SAIL-GPL, the Secure Super AI General Public License, and the idea fits in one line on its website. Let the proof travel.
Ownership changes. Assurance should stay.
A signature can show that files are intact. That is useful but not enough. A responsible release also explains where the model came from, what was evaluated and how to report a vulnerability.
SAIL-GPL couples the permission to distribute a model with a duty to ship its evidence. Recipients get the familiar freedoms. They may use the model for any purpose, study it, modify it, build derivatives and redistribute them. In return, every distribution must carry its release evidence, and every derivative must renew it. The draft puts it more bluntly than I usually would. You may own the weights. You may not ship them unverifiable.
This is the part I care about most. Fine-tuning, merging, quantization or simple re-hosting does not discharge the obligation. A small change does not remove the duty to explain what you are shipping.
One artifact, one inspectable release record
In practice the evidence lives in a folder called srm, short for Secure Release Metadata, next to the model files. It has five parts.
- Integrity. A signed manifest with hashes of every distributed file, including the model card and the evidence itself.
- Provenance. A SAI Bill of Materials, or SAIBOM, which declares upstream models and their licenses, adapters, dependencies, data provenance and a pipeline reference. A derivative records the signature digest of its parent.
- Context. A model card with intended use, out-of-scope use, limitations and known risks.
- Evaluation. A security attestation with explicit results for at least three categories, prompt injection, training-data extraction and poisoning or backdoor checks.
- Response. A disclosure policy with a named contact and a coordinated vulnerability disclosure process.
One rule deserves attention. Each test result must be stated as pass, fail or not-applicable, with notes or evidence. The toolkit never invents a passing result, and signing is never treated as evaluation. A failed test can be a perfectly valid piece of evidence. As the site says, a valid signature never turns a weak model into a safe one. I would rather receive an honest failure than a silent gap.
Prepare, declare, sign, verify
The release flow is deliberately simple.
Prepare. Collect the model files, write a meaningful model card and publish a disclosure contact and process.
Declare. Supply the SAIBOM and actual adversarial evaluation results, then choose the tier that fits the distribution and its risk.
Sign. Bind the files and evidence to a release manifest, and keep private keys outside the distributed artifact.
Get Šarūnas Grigaliūnas’s stories in your inbox
Join Medium for free to get updates from this writer.
Verify. Check the release against trusted keys obtained separately. For a derivative, renew the record and repeat.
Different risk, a higher bar
Not every model needs the same ceremony, so the draft defines tiers. T0 covers internal research that never leaves your organisation, and it triggers none of the release conditions. The moment you distribute a model to third parties you are at least at T1.
T1 is for small or narrow models. The evaluator may self-report, but explicit results for the minimum test set are still required. T2 covers capable general-purpose or product-embedded models, requires full evaluation coverage and recommends post-quantum or hybrid signatures. T3 is for frontier or high-risk distributions. It requires actual post-quantum (ML-DSA) or hybrid signing, an externally trusted publisher key, a distinct trusted independent evaluator key and a signed Merkle inclusion receipt checked against a trusted log key. Those three roles may not share key material.
All three distributed tiers require the core evidence bundle. The bar rises, the floor never disappears.
Trust begins with a check you can run
A license that only describes evidence would be easy to ignore, so SAIL-GPL comes with an open Python toolkit that builds and verifies native SRM v2 bundles. The repository contains a signed demonstration release. From the repository root you can run
PYTHONPATH=sail/src python -m sail verify example-model --trusted-key sail/examples/example-public-key.json
I ran it on a fresh clone while preparing this piece. The demonstration release comes back VERIFIED, with every check listed. Then I changed a single configuration file inside the model folder and ran the same command. The result flipped to NOT VERIFIED, with a hash mismatch on that file and a broken binding between the evaluation and the artifact it was supposed to describe. That is exactly the behaviour I want. Evidence that silently survives tampering is not evidence.
I also want to be precise about what VERIFIED means. It means the checked technical evidence passed. It is not a legal or safety certification, a promise of secure behaviour or proof of superhuman competence. Without a trusted publisher key, verification establishes integrity only. In a real release, the publisher key must be obtained and authenticated through a channel outside the model bundle. The key is part of the decision.
A word on the name
SAI stands for Super AI in this project. It names the class of model artifacts covered by the license, including the models we use today. It does not claim that superintelligence exists, and it certifies no capability. I chose the term because the obligations should already be in place before anyone argues about thresholds.
What it is, and what it is not yet
SAIL-GPL 1.0 is a public draft, offered for community and counsel review. It has no OSI approval and no registered SPDX identifier, so it uses the custom reference LicenseRef-SAIL-GPL-1.0. The native SRM and SAIBOM formats are custom. The draft cites OpenSSF Model Signing, Sigstore, SPDX, CycloneDX, OWASP and MITRE ATLAS as external references, but claims no compatibility with any of them. Independently licensed code keeps its own terms. None of this is legal advice, and the draft makes no enforceability claim for any jurisdiction.
Who should care
If you publish open-weight models, SAIL-GPL gives you a concrete way to say what you shipped and how to reach you. If you build products on downloaded models, it gives you something to check before a model enters your supply chain. If you work on red teams, evaluation or incident response, it gives your findings a place to live that follows the model. And if you are a lawyer or a policy person, the draft needs your critical reading more than anyone's.
How to get involved
Version 1.0 is a public draft, and this is the right moment to shape it. Read the license language, examine the wire format or test the toolkit. Clone the repository, run the verifier and try to break it. If you find a security issue in the toolkit, please use the private vulnerability reporting route described in the repository rather than a public issue. If you disagree with a requirement, tell me why. A proposal like this only becomes useful when people who did not write it start pushing on it.
Better releases start with evidence we can inspect. Let the proof travel.
Website https://sail-gpl.org/
Draft license https://github.com/Grigaliunas/SAIL-GPL/blob/main/SAIL-GPL-1.0.md
Source and toolkit https://github.com/Grigaliunas/SAIL-GPL
Dr. Šarūnas Grigaliūnas. SAIL-GPL is maintained by The Open Reality Initi
