Providers, models and clients
The three allow-lists that decide where your code may go, what may run on it, and which tools may open a session — plus what happens when one is broken.
Three lists, on Organization → Governance → What agents may use. All three need governance.manage_providers — owner or organization admin.
AI providers
Which vendors may receive this organization's source code. A provider with no decision is blocked.
There is no default, on purpose: a default would be a decision made on your behalf about where your source code may be sent.
The seven Madebook knows:
| Value | Label |
|---|---|
anthropic |
Anthropic |
openai |
OpenAI |
deepseek |
DeepSeek |
xai |
xAI (Grok) |
google |
Google (Gemini) |
azure_openai |
Azure OpenAI |
local |
Self-hosted / local |
Click a chip to approve it; click an approved one to block it again. Filled means approved, dashed means blocked. Every change is audited.
With no provider approved at all, Madebook's own workflows refuse with:
{organization} has not approved any AI provider. Approve one under Governance › AI providers before running AI workflows.
Models
Approve none and every model from an approved provider is allowed; approve any and only those are.
This is the one rule on the page that surprises people, so it is worth restating: an empty model list is permissive, not restrictive. Once you approve a single model, only approved models are allowed.
The badge reflects it: {n} approved, or all from approved providers.
The chips offered come from the platform's model catalog at the account service, filtered to your approved providers. Before a provider is picked: "Approve a provider first — the models on offer follow from it."
The catalog says what exists; the AI page says what answers; this list says what is permitted. A chip you approve here is not thereby configured to run, and a model configured to run is not thereby approved.
Adding a model by name
Add a model by name takes a provider and an identifier. Its hint is the important part:
Exactly as the client reports it. The name is matched as written, ignoring case, so a near-miss is a model that never matches.
Azure OpenAI and self-hosted providers ship no catalogued models at all, deliberately — a deployment name is chosen by whoever created the deployment, and no catalog can know what you called yours. If you have pointed the organization at your own endpoint, this is how you approve what it serves: approve local, then add the model by the identifier you typed there.
Coding clients
Which tools may open a session — a session from a client not approved here is refused at registration, before it is briefed with anything.
| Value | Label |
|---|---|
claude_code |
Claude Code |
cursor |
Cursor |
vscode |
VS Code |
codex |
Codex |
copilot |
GitHub Copilot |
windsurf |
Windsurf |
other |
Other |
The same empty-list rule applies: "Approve none and any client may open a session."
This is the value an engineer sets as MADEBOOK_CLIENT. See The MCP server.
What happens when one is broken
Under each of the three panels is an enforcement control: "When an unapproved {provider/model/client} is used."
Two settings.
What happens to the run
| Mode | Effect |
|---|---|
| Refuse the run | the run is blocked before it starts and the agent is told why. This is the default. |
| Allow, but record | the run is allowed to proceed — use this while rolling out, so engineers are seen rather than blocked. |
The default is refuse at high severity, and an organization that has never opened this page is on that default. This table only ever loosens, deliberately.
Severity of the record — and the page spells out exactly what each level means for you:
| Severity | What it does |
|---|---|
low |
Lands on the Violations page and as a Decision in Attention. Only recipients whose email floor is "every violation" hear about it. |
medium |
Violations page, a Decision in Attention, emailed to recipients on "every violation" or "medium and up". |
high |
Violations page, a Decision in Attention, emailed to everyone except "critical only" recipients. |
critical |
Appears as INTERVENE at the top of every Attention queue, and every recipient is notified whatever their floor. |
The refusal messages
| What was refused | The reason the agent is given |
|---|---|
| Provider | "{organization} has not approved {provider} as an AI provider." |
| Model | "{model} is not on {organization}'s approved model list." |
| Client | "{client} is not an approved development client for {organization}." |
| A policy's provider list | "Policy "{name}" limits providers to anthropic, openai." |
| A policy's model list | "Policy "{name}" limits models to claude-sonnet-5, gpt-5-codex." |
| A policy's client list | "Policy "{name}" limits clients to claude_code, cursor." |
A policy allow-list always refuses. It ignores the enforcement mode entirely — its consequence is stronger than any gate.
A refused client stops a session opening at all, with CLIENT_NOT_APPROVED. A refused model stops a run being recorded, with MODEL_NOT_APPROVED.
Where the API key lives
The allow-list and the API key are two different things. The allow-list says whether a vendor may see your code. It holds no key, and approving a vendor here makes nothing run.
Keys live at the Bookbag account service, never in Madebook, and there are two possible sets of them depending on what the organization chose on its AI self hosted page at Bookbag account (see AI configuration):
- Self hosted — the organization's own keys, added by its owner or an admin on that page at Bookbag account. Its provider bills it directly.
- Managed by us — the platform's keys, added by a platform administrator at the account service. Nobody in the organization pastes anything.
Whichever set is in play, a key is:
- Verified against the provider before it is stored. A rejected key is never kept.
- Encrypted. There is no plaintext fallback — with no encryption key configured, the store refuses to save.
- Never returned to a browser. Only a hint: the last four characters.
- One per provider per scope. Adding a key replaces the one that provider had.
Both lists must agree before anything runs. A model with a working key that this page has not approved is refused. A model approved here with no key behind it has nothing to run on. The first is fixed here; the second on AI configuration.
See AI configuration for an organization's own keys, and Platform AI and the model catalog for the platform's.
Compliance frameworks
The Compliance tab names frameworks your policies can cite. It is explicitly not enforcement:
Compliance frameworks are just categories for your policies. You don't need to add any: policies work exactly the same without them.
Ten templates ship: SOC 2 Type II, ISO 27001, HIPAA, GDPR, PCI DSS, CCPA / CPRA, NIST 800-53, FedRAMP, SOX (ITGC), and Internal standards. You can name your own.
Removing one is safe — "policies keep working, they just lose the tag."
The tab has three views — Board, List and Tree — a search, and a Has policies filter. An untagged group called Not tagged collects everything that cites no framework.
Related
- AI configuration — which models actually answer, and whose key pays
- Policies
- Violations
- AI runs