A working draft (v0.2.1). This is a methodology, not a product: a way to make one specific decision repeatable and auditable. It composes standards that already exist rather than inventing new ones. The method, a runbook, a fillable Model Trust Record, the validation write-up, and the red-team harness are in the model-trust-gate repo.
The decision nobody writes down
A team wants to adopt a model. Maybe a new frontier API, maybe an open-weight checkpoint they will download and self-host. Someone has to answer a plain question before it goes live:
Do we trust this model enough to use it for this, and can we prove we made that call responsibly?
In most organizations that decision is made on gut feel, a vendor’s system card, and whoever pushes hardest, then rationalised afterwards. It is a hard decision, and an easy one to make inconsistently. The Model Trust Gate turns it into a repeatable procedure, the same way vendor-risk review or change-approval turns “should we let this in” into a gate instead of an argument.
We are not short of standards for the pieces. NIST AI RMF, ISO/IEC 42001, and CSA’s AI Controls Matrix cover the governance side. OWASP’s LLM and Agentic Top 10s, MITRE ATLAS, NIST’s adversarial-ML taxonomy, and red-teaming cover the technical side. What none of them gives you is a runnable decision procedure: an ordered gate that ends in an auditable yes or no. Checklists enumerate things. They do not gate.
The idea: order the review, fail fast
The Gate is seven checks run in order, from cheap and administrative to expensive and technical. Each ends in one of three outcomes: pass, conditional-pass (allowed once a named control is added), or stop.
- L0 Set the stakes: what are we deciding, and how hard must we look?
- L1 Provenance: do we know where this model came from, and can we trust the files?
- L2 Permission: are we allowed to use it, and can we prove it to a regulator?
- L3 Behavior: with nobody attacking it, does it behave well enough for the job?
- L4 Attack resistance: when someone actively tries to trick or abuse it, does it hold?
- L5 Guardrails: what controls do we wrap around it in production?
- L6 Upkeep: how do we keep this decision valid as the model, the threats, and the rules change?
The ordering is the point. You confirm where a model came from and whether you are legally allowed to run it before you spend days red-teaming it. If a downloaded model file fails a malware scan at L1, you stop there and never pay for the expensive testing on a model you were never going to be allowed to run. This is the same fail-fast logic as a change gate that rejects a request on a missing approval before anyone starts the work. It is an old pattern, borrowed on purpose from vendor-risk review and bank model-risk management, and pointed at AI-specific inputs.
Two dials: how hard you look, and where the effort lands
How hard you look is set once, at the start, by how risky the use is, not the model. A tool that drafts internal meeting notes gets a light review; a model that helps decide insurance claims gets a heavy one. The Gate calls this the Rigor Level, R1 to R4, and it takes the highest level any single driver reaches: the model’s autonomy (how independently it acts, on the AWS / CSA Agentic AI Security Scoping Matrix), its agency (how far it can reach, from read-only to privileged action), the sensitivity of the data, and the impact of its output on a person or the business (a scoring model that acts on nothing can still screen a job applicant). A use that is R4 on any one driver is R4.
Where the effort lands is decided by the model’s origin. For a trusted cloud vendor the paperwork is light and the real work is behavior and attack testing. For a downloaded open-weight model the supply-chain and legal checks are the hard part, because you are now running someone else’s files in your environment.
A third case sits between the two, and it is now the most common request a platform team gets: an open-weight model served through a managed cloud provider (Qwen or Llama on AWS Bedrock, Azure AI Foundry, and the like). The provider holds and runs the files, so the file-level supply chain nearly vanishes exactly as it does for any cloud model. What does not come with it is the safety pedigree: an open-lineage model typically arrives with far thinner inherited testing than a frontier lab’s. So the effort lands on your own behavior and attack testing, plus a first-time origin and data-governance decision, rather than on the file scanning that dominates a downloaded model. Who holds the files, and who tested the model, moves the work; who trained it does not.
That second dial is the one idea worth remembering, and it is more precise than the usual slogan:
Both cloud and open-weight models need behavior and attack testing. What downloading and self-hosting an open-weight model adds is supply-chain risk that a reputable cloud API mostly spares you, because you now hold and run the files. It can also raise the technical risk, because you lose the vendor’s runtime safety layer and may change the model when you compress or fine-tune it.
Note what this does not say. It does not say open-weight is more dangerous, and it does not say cloud is safe. It says the distinctive extra work moves from one end of the gate to the other depending on how you got the model.
An early signal, honestly scoped
That last claim is testable rather than assertable, so a small red-team harness tests it: one fixed attack battery, changed one variable at a time, against local models. It is a directional pilot on small models (7B to 8B), not a frontier measurement, and it is reported as such. Three comparisons, each run twice:
- Losing the runtime guardrail (B2): adding an input-and-output guardrail dropped attack-success from a measurable rate to zero, cleanly and repeatably. This is the “a cloud service ships a safety layer you lose when you self-host” effect, isolated.
- Model choice (B3): models of similar size but different families sat at very different attack-success rates, a large and repeatable spread. “Open-weight” is not one risk level; the specific model you pick is a first-order decision.
- Compression (B1): the effect of quantization on safety was inconclusive on this small battery. The direction reversed between runs, driven by a single flaky attack, so the pilot does not lean on it.
The honest read: B2 and B3 support the corrected claim; B1 does not carry weight and is reported as inconclusive rather than dressed up. This is an early signal, not a proof, and it is labelled that way in the validation write-up.
What this deliberately cannot tell you
A method is only trustworthy if it is clear about its own edges. Three are named openly rather than hidden:
- The system above the model. The Gate judges the model. Risks in the knowledge bases it reads from, or in how several agents chain together, live at the system level. The Gate flags these and hands them to a separate system review rather than pretending to cover them.
- Attacks baked in during training. An organization adopting a finished model cannot fix poisoning introduced when the model was trained. It can look for signs at L1 (file tampering) and L3 (behavioural drift), but a trigger-keyed backdoor that stays dormant until a rare input is, by construction, not reliably detectable by either. The Gate does not claim to catch weight-encoded backdoors; it reduces their blast radius downstream.
- Frontier capability testing. Whether a model meaningfully helps build a weapon is not something an ordinary adopter can safely test. The Gate uses the vendor’s or a safety institute’s published testing and labels that evidence as inherited, never claiming to have re-run it.
These are not defects to patch. They are the honest edge of a framework written for the adopter of a model, not the lab that trained it. Naming them is what separates a usable method from a marketing diagram.
The output is a record, not a score
The Gate does not produce a grade. It produces a signed, dated Model Trust Record: one model, one use, the result of each check, the controls added, who approved it, and when it expires. Every verdict is scoped (“allow for this use, at this level, until this date”), never “this model is safe.” Every piece of evidence is labelled “ours” or “the vendor’s,” so an inherited dependency is visible rather than laundered into a false pass. That record is the artifact you hand an auditor, and the thing you re-open when the model version, the threat, or the regulation changes.
Where it sits among existing work
The standards-crosswalk space is crowded, and this is not a claim to have invented a category. GLACIS AI Vendor Due Diligence is adopter-side too, but a flat parallel checklist with no fail-fast ordering and no cloud-versus-open-weight split. Databricks DASF composes many standards, but organised by system component rather than as a sequential stop/pass gate. Gartner AI TRiSM is a continuous operating model, not a one-time per-model decision. CSA STAR for AI is an organisational maturity pathway. Bank model-risk management (SR 11-7, and its successor) is the structural ancestor, but it explicitly scopes generative and agentic AI out, which is part of the gap this fills. What the Gate adds is narrow and specific: the fail-fast ordering, run on the AI-specific standards, weighted by whether the model is a cloud call or a downloaded file, ending in a signed record.
Status and the honest next step
This is a working draft (v0.2.1). Its validation so far is a coverage crosswalk against the standard risk lists (OWASP 2026, NIST’s generative-AI categories, CSA AICM, MITRE ATLAS), four worked adoption runs that are explicitly illustrative rather than real deployments, an adversarial attack on the method itself, and the directional red-team pilot above. Two control-mapping details remain flagged for confirmation against paywalled source documents, and they are marked as such rather than asserted.
The natural next validation is the one thing a paper cannot fake: a documented internal deployment, one real model adopted for one real use, run through all seven layers, with the Model Trust Record as the output. That is v0.3, and it is named here as the roadmap rather than quietly implied to already exist. Until then this is a reasoned, ordered, honestly-bounded method for a decision teams are making anyway, usually without writing it down.