➜ 403 model_forbidden — checked at the gateway, at run creation, and again by the runner
Governance, enforced.
Not just written down.
A policy page nobody can actually violate. An admin sets what the team may use — providers, models, a locked default, MCP servers, skills — and every run in NextOS is checked against it at the moment it would matter, not just displayed back at the person who set it.
- roles
- 3
- invite links
- 7-day
- per seat / mo
- $28
- enforcement checks
- 3
a mock of the real console (Settings > Governance) — not live data
01How enforcement works
Three checks,
not one policy page.
The rules themselves live in one small, dependency-free module, evaluated identically on the server and in the browser — so what a tab shows you before you hit run is the same rule the server enforces after.
The gateway checks first
Every call to /v1/chat/completions resolves the caller’s effective policy and checks the requested model against it before anything is sent to a provider. A forbidden model gets a 403 model_forbidden back, not a silent substitution.
Run creation checks again
Starting or forking an agent run (from an app, a schedule, or the gateway’s inbound door) checks the same policy before the job is even enqueued. The refusal reads the same way everywhere: “your team’s policy does not allow provider/model.”
The runner checks a third time
Right before a background step actually builds a provider adapter, the runner re-fetches the account’s policy and checks again. A schedule enqueued under an older, looser policy — or a job record hand-edited in storage — still can’t run a model the current policy forbids.
02Invites, roles and seats
Bound to an email,
not a link anyone can forward.
There is no mail infrastructure to trust or misconfigure: an admin shares a link, and it only works for the address it was issued to. Everything else about membership follows the same plain rules.
- An invite link is bound to one email address and expires in 7 days — a leaked link is useless to anyone signed in as someone else
- Three roles: owner, admin, member. Owners and admins can invite, set policy, and change roles; members consume what’s allowed
- An org can never drop to zero owners — the last owner can’t be demoted or removed, only replaced
- A member with no Teams plan of their own inherits the org owner’s plan and seat pool while they’re in the org — nothing is written to their own billing record
- Governance can hold a per-member override that replaces the team policy for just that person, without touching everyone else’s
one policy · checked three times