Platform
Govern every model in your environment
Every model your organization calls, recorded with its provider and version alongside the owner who approved it and the policy that constrains its use.
The estate, by model
Models
7
Providers
6
4 of 7 never send a prompt to a third party. That ratio is usually the first thing a review wants and the last thing an inventory can produce.
Why models get their own register
An agent is an actor. A model is a dependency.
They fail differently, so they are governed differently. An agent does something you can point at; a model quietly changes what every agent that calls it will do next — including agents whose own code has not been touched in months.
Most organizations track models as a cost line. That is a real thing to track and it answers none of the questions that matter under pressure: which snapshot was live on the day of the incident, who signed off on using it for that, and whether the prompt left the building.
A model register is also the only place a supersession is visible. A family name in an agent config will happily keep pointing at something that was replaced two months ago, and nothing in the agent will look wrong.
What a model record has to carry.
- Who approved it
- A named person, for a named use. Approval is never blanket — the same model can be approved for triage and refused for anything that moves money.
- Which snapshot is live
- A pinned version, not a family name. "We use Claude" does not tell you whether last week’s behaviour is reproducible.
- Where the weights run
- Vendor API, private endpoint, or your own hardware. This is the first question a data-residency review asks and the last one an inventory usually answers.
- What constrains its use
- A bound, evaluated at the action. A model approved for drafting does not become approved for committing because a workflow put it there.
Every model in the estate
Pinned, approved for something specific, and attributable.
Read the Approved-for column rather than the Model column. Two agents calling the same family under different approvals is normal; the same model approved for everything is the failure this register is designed to make visible.
Model register
5 approved · 2 needing attention| Model | Pinned | Where it runs | Approved by | Approved for | Called by | State |
|---|---|---|---|---|---|---|
| Claude SonnetAnthropic | 2026-04-11 | private endpoint | Priya NairSupport Ops | Customer-facing reasoning and refund adjudication | refund-resolverclaims-triage | approved |
| Claude HaikuAnthropic | 2026-04-11 | private endpoint | Priya NairSupport Ops | High-volume ticket triage and classification | order-lookuptier1-supportdunning-agent | approved |
| GPTOpenAI | 2026-03-28 | vendor API | Rahul MenonFinance | Invoice extraction and ledger reconciliation drafting | ap-invoice-agentpayout-runner | approved |
| Gemini ProGoogle | 2026-02-19 | vendor API | Sneha IyerRevOps | CRM record hygiene and duplicate detection | inventory-synccrm-hygiene | retiring |
| LlamaMeta | 2026-01-30 | self-hosted | Kabir SenLegal | Contract reading. Nothing leaves the perimeter. | contract-reader | approved |
| MistralMistral | 2026-03-05 | self-hosted | Anita RaoProcurement | Vendor document classification, procurement only | vendor-onboard | approved |
| Public web UIConsumer chat assistants | — | vendor API | Kabir SenLegal | Not approved for any action on a system of record. | — | blocked |
IllustrativeA sample estate. Provider and family names are real because OpsAI governs models from them; the pinned dates are this fictional estate's own snapshots, not a vendor's version numbering.
Where the weights run
3 answers, and only one of them involves a contract.
Hosting is not a performance decision once an action can touch regulated data. It determines whether a data-residency commitment is something you enforce or something you have been promised.
- self-hosted2
Open weights on our own hardware. Nothing leaves.
- Llama
- Mistral
- private endpoint2
The provider's model inside our own tenancy.
- Claude Sonnet
- Claude Haiku
- vendor API3
Prompt and context leave the perimeter under contract.
- GPT
- Gemini Pro
- Public web UI
Inside the perimeter
4
no prompt leaves
Under vendor contract
3
governed at the data boundary
Providers
6
no single dependency
Needing attention
2
retiring or blocked
IllustrativeFigures from the sample estate, not a customer deployment. What data a model may be given.
The honest rows
A register that only says yes is not a register.
2 rows here are not plain approvals, and they are the ones worth reading. One is still being called after being superseded. The other cannot be governed at the API at all.
Gemini Pro Google
Superseded for this use in March. Two agents still call it; both move next sprint.
- Approved for
- CRM record hygiene and duplicate detection
- Owner
- Sneha Iyer
Public web UI Consumer chat assistants
Reached through a browser rather than an API, so it is governed at the data boundary instead. Pasting customer data into one is the exposure this row exists to name.
- Approved for
- Not approved for any action on a system of record.
- Owner
- Kabir Sen
The models nobody registered
Discovery
A register covers what was declared. Unapproved model use is usually reached through a browser, not an API key.
What it may be given
Data access
A blocked model is governed at the data boundary instead — the point where the prompt would have been assembled.
Choosing between them
Model routing
Which model an action is allowed to use, decided by the action rather than by whoever wrote the config.
Where to start
Pin the versions, then name the approvals.
Most estates can produce a list of providers within an hour and a list of pinned snapshots with approved uses in about a week. The second list is the one an incident needs.