AI governance
Governance the database enforces, not a policy doc describes
Who may use which model, who may create the credentials, who approves, and what the record shows afterwards - every rule on this page is a row-level security policy or a trigger, which means application code cannot forget it and a policy document cannot drift from it.
- Three roles with a stated line: owners run billing and the roster, admins run keys and guardrails, members watch and request
- A key request needs a second person's approval - self-approval is refused inside the database function, not by a UI convention
- Everything leaves a record: role changes, roster changes and decisions land in a trigger-written trail nobody can edit
What is AI governance?
AI governance is the set of answers to four questions: who may use AI on the company's account, what they may reach with it, who says yes when someone needs more, and what the record shows when anyone asks afterwards. Most tools answer these in a policy document; the incidents happen in the gap between the document and the software.
Final Router answers them in the request path and the database. Model access attaches to API keys; roles and approvals are row-level security policies; the audit trail is written by triggers, which is what makes it evidence rather than an editable diary. A rule the database enforces is a rule a refactor cannot quietly lose.
The governance surface
Each card ends with the mechanism, because 'enterprise-grade governance' is not a claim - these are.
Roles with a bright line
Owners hold billing, provider credentials and the roster. Admins manage gateway keys and guardrails. Members see the traffic and spend nothing. Promotion is one dropdown on the Team card - and one logged event.
enforced by RLS policies, not by application code
Approvals that mean something
A member requests a key with a justification; the owner or an admin decides; the requester mints the approved key themselves - so the raw credential is only ever seen by the person who holds it.
self-approval refused in the database function
Model access per key
Every API key carries its own allowed models, providers and guardrail set - so a product, a team or a contractor reaches exactly what was approved for them and nothing else.
a leaked key is bounded by its own allowlist and caps
An audit trail written by triggers
Invitations, joins, removals, role changes and approval decisions are recorded with label snapshots, so the trail keeps naming people even after their accounts are gone. Nobody writes it directly - not even the owner.
evidence, not an editable diary
Retention you can only shorten
Prompt text is stored only on opt-in, for 1, 7, 14 or 30 days - 30 is the ceiling, and shortening deletes anything older immediately. The privacy policy quotes the same constant the sweep enforces.
per-account window, honoured by the database sweep
Spend governance underneath it all
Monthly budgets, per-key daily caps and per-session stops mean the governance story ends with a ceiling, not a hope - approved keys still carry every limit the account sets.
403 budget_exceeded before the spend exists
AI governance
Best practices - the order that works
- 01
Draw the role line before the team grows
Invite people as members first. Watching traffic requires no trust decision; promote to admin when someone actually needs to run keys, and the promotion itself is logged.
- 02
One key per product, policy attached
Keys are the unit of governance here: model access, guardrails, caps and expiry all travel with the key. A key that maps to one workload makes every log line attributable.
- 03
Route new credentials through approvals
Even when you would have said yes anyway, the request-approve-mint path leaves a record of who asked, who agreed and why - which is the difference between an answer and a shrug in the audit meeting.
- 04
Shorten retention to what you actually replay
If you only ever debug last week, a 7-day window is strictly better than 30. The dial only turns down, so tightening costs nothing and un-stores what you never needed.
- 05
Let the caps be the last line
Roles and approvals govern people; budgets and session stops govern software. The runaway loop does not care who approved its key - the ceiling stops it anyway.
Enforced in the database vs described in a document
| Final Router governance | Policy-document governance | |
|---|---|---|
| Role enforcement | Row-level security - the database refuses | Application checks, hoped consistent |
| Second-person approval | Self-approval refused in the decide function | A convention, until someone is busy |
| Credential exposure | Raw key shown once, to the requester alone | Pasted through chats and tickets |
| Audit trail | Trigger-written, label snapshots, nobody edits it | Whatever the app remembered to log |
| Retention | Per-account window, ceiling fixed, sweep enforced | A number in a PDF |
FAQ
What exactly can an admin do - and not do?
Admins create, revoke and cap the workspace's gateway keys, write and attach guardrails, and decide approval requests. They cannot touch billing, provider credentials, the roster or roles - those stay with the owner, and the restriction is a row-level security policy, not a hidden menu item.
Can someone approve their own request?
No. The decision function refuses it outright, whatever the requester's role - approval here means a second person said yes. An admin's own request waits for the owner or another admin.
Who sees an API key created through an approval?
Only the requester. Approving unlocks the mint; the requester creates the key from their own settings and it is shown exactly once, to them. The owner is emailed that a key was created - its name and prefix, never the key itself.
Is there an audit log I can rely on?
The workspace trail records invitations, joins, removals, role changes and approval decisions, written by database triggers with label snapshots - no code path can skip it and nobody can edit it. Request-level history lives in the request log beside it, exportable as CSV.
Do you support SSO or SCIM?
Not yet, and this page will not pretend otherwise. SAML SSO is on the roadmap and worth a conversation if your team needs it - contact us. SCIM provisioning is further out. Everything else on this page is live today.
Rules a refactor cannot lose
Invite a teammate as a member, promote them to admin, and watch both actions appear in a trail neither of you can edit.
Related: AI guardrails, AI spend management, LLM observability, security practices.