The Model Trust Gate

A step-by-step way to decide whether your organization should trust a given AI model, for a specific use, with the right amount of scrutiny and a record you can show an auditor.

The problem

Teams keep adopting AI models: cloud services you call over an API, and open-weight models you download and run yourself. Before each one goes live, someone has to decide whether it is safe enough for the use, and be able to defend that call. That is a hard decision, and an easy one to make inconsistently. The Model Trust Gate turns it into a repeatable procedure, like a vendor-risk or change-approval gate, but for AI models. It ends in a signed, dated Model Trust Record.

It does not invent new controls. It composes standards that already exist and arranges them into one runnable decision.

How to read this repo

Two paths, depending on why you are here.

Reviewing a model now (fastest path to a signed record):

1. QUICKSTART.md: the one-afternoon path, intake, triage, pick a track, run L3/L4, sign the record. Start here if a team just handed you a model.
2. RUNBOOK.md: the full runnable method behind the quickstart, a one-page intake, triage, tracks, effort sizing, a per-layer checklist, and default pass-bars.
3. The worked runbook closest to your case: hosted open-weight (Bedrock) or fine-tuned open-weight, each intake to signed record.
4. starters/: copy-and-edit promptfoo (L3) and garak (L4) configs so the technical layers are runnable, not just described.
5. templates/: the fillable record, a blank template to copy, the JSON schema for policy-engine gating, and two filled examples (hosted, fine-tuned). Check a record with python3 tools/validate_record.py <record.json> (needs pip install jsonschema; add --example for the shipped examples, which keep placeholder hashes and signatures).

Understanding or defending the method:

• Build, Break, Govern: the write-up, the method explained in one read with the diagram and the reasoning behind the order of the checks.
• FRAMEWORK.md: the method in full, the seven-layer gate, Rigor Levels, and the Model Trust Record.
• VALIDATION.md: how it holds up, a coverage crosswalk, worked runs, and an attack on the method itself (optional for a first review).
• experiments/claim-verification.md: the protocol behind the empirical pilot of the framework's central claim, that self-hosting an open-weight model relocates supply-chain risk onto the adopter. The same folder holds the two probes behind Don't judge an AI model by its origin, which applies the Gate's L3 and L4 to three open models of different origin.
• standards-crosswalk.md: the control-level backing, each layer mapped to ISO/IEC 42001 clauses and CSA AICM control IDs.

The idea in one screen

• A fail-fast gate. Seven checks run in order, cheap and administrative first, expensive and technical last, so a model that fails an early check is stopped before you spend on the hard testing: L0 set the stakes, L1 provenance and supply chain, L2 permission and governance, L3 behavior, L4 attack resistance, L5 guardrails, L6 upkeep. Each of L0 to L5 ends in pass, conditional (allowed once a named fix lands) or stop.
• Scrutiny matches the stakes. How hard you look is set by a Rigor Level (R1 to R4), driven by four things: autonomy (how independently the model acts), agency (what it can touch), the sensitivity of the data it sees, and the impact of its output on a person or the business. Autonomy and agency are adapted from the AWS and CSA agentic AI security scoping work.
• Origin decides where the effort lands. For a cloud model the work is mostly behavior and attack testing; for a downloaded open-weight model, the supply-chain and legal checks are the hard part.
• The output is a record, not a score. A signed, dated Model Trust Record, scoped to one use, with an expiry. The verdict is one of Allow, Allow with controls, Restrict (to a narrower use) or Deny.

What a finished record looks like (excerpt from the hosted open-weight example):

Model:            Qwen3-32B (open-lineage, via AWS Bedrock) @ qwen.qwen3-32b-v1:0, pinned 2026-08-25
Use case:         Internal knowledge assistant over internal docs; read-only, cannot act
Scrutiny level:   R2      Regulatory floor: none
Per-layer result: L0 pass · L1 pass · L2 pass · L3 pass · L4 conditional · L5 pass
Overall:          Allow with controls
Controls added:   Bedrock Guardrails on input+output, closes L4-F1 (indirect injection via documents)
Evidence:         each item labelled "ours" or "vendor's"
Expires:          2027-02-21 (180 days), or earlier if the provider updates the served model version
Approved by:      a reviewer independent of the requesting team

Status: working draft (v0.2.2), a personal working document. Facts that still need a primary-source check are tagged [verify] in the text.

What it composes

• Governance: NIST AI RMF, ISO/IEC 42001, CSA AI Controls Matrix (AICM), EU AI Act.
• Supply chain: NIST SP 800-218 (SSDF), SLSA, CSA AICM supply-chain domain.
• Technical: OWASP Top 10 for LLM Applications 2026 and OWASP Top 10 for Agentic Applications 2026 (the ASI Top 10, published December 2025), MITRE ATLAS, NIST AI 100-2 E2025 (adversarial-ML taxonomy).
• Risk classification: an agentic AI security scoping model (AWS / CSA lineage).

Scope

• Written for the adopter of a pretrained model, not the lab that trains one.
• Judges the model as an adopted component, not the wider system around it (knowledge bases, multi-agent orchestration, application code), which it hands to a separate system-level review.

---

Personal working draft. Not affiliated with, nor representing, any employer. All names, ticket IDs and policies in the examples are invented.