docs(kilo-docs): remove model-provider-blocklist doc and nav item

remove deprecated model-provider-blocklist page and nav item
update enterprise model-access-controls doc content
add redirect from old docs path to new enterprise path
This commit is contained in:
kiloconnect[bot]
2026-03-10 14:20:58 +00:00
parent 494ebcee77
commit 2c7ed9461c
4 changed files with 58 additions and 107 deletions
@@ -50,10 +50,6 @@ export const ContributingNav: NavSection[] = [
href: "/contributing/architecture/mcp-oauth-authorization",
children: "MCP OAuth Authorization",
},
{
href: "/contributing/architecture/model-provider-blocklist",
children: "Model/Provider Blocklist",
},
{
href: "/contributing/architecture/onboarding-improvements",
children: "Onboarding Improvements",
@@ -5,44 +5,73 @@ description: "Control which AI models your team can access"
# Model Access Controls
**Model Access** lets organization admins control which AI models and providers are available to team members.
Admins can **enable or disable** specific models, filter by attributes, and enforce organizational data policies.
{% callout type="info" %}
This is an **Enterprise-only** feature. Organizations on other plans have unrestricted access to all models and providers.
{% /callout %}
**Model Access Controls** let organization owners block specific AI models or providers for all team members. The system uses a **blocklist** approach: everything is allowed by default, and admins explicitly block what should not be accessible.
This means newly added models and providers are automatically available to your team without any manual action required.
## How It Works
| Scenario | Behavior |
| ---------------------- | ------------------------------------------------------------------------------------- |
| No blocks configured | All models and providers are available (default) |
| Provider blocked | All current and future models from that provider are unavailable |
| Specific model blocked | Only that model is unavailable; other models from the same provider remain accessible |
## Managing Model Access
1. Navigate to the **Model Access** tab of the Enterprise Dashboard.
2. Toggle the checkbox beside any model or provider to enable or disable access.
3. Click "Save Changes" to apply
Navigate to your organization's **Providers & Models** page to configure access controls.
{% image width="800" alt="Model-Access-Select" src="https://github.com/user-attachments/assets/af71353d-facc-4d4b-a0cd-c7f2cea73e97" /%}
The page has two tabs:
## Filtering Models
### Models Tab
You can filter available models by:
Lists all available models across all providers. For each model you can:
| Filter | Description |
| ----------------------------- | --------------------------------------------------------------------------- |
| **Data Policy** | Choose models that meet specific data retention or compliance requirements. |
| **Provider Location** | Restrict models hosted in certain geographic regions. |
| **Series** | Filter by model family (e.g. GPT-4, Claude 3, Gemini 1.5). |
| **Provider** | Limit access to specific providers like OpenAI, Anthropic, or Google. |
| **Input / Output Modalities** | Filter by capabilities (text, code, image, audio, etc.). |
| **Pricing** | Compare cost per token or usage tier. |
- Toggle access on or off
- Search by model name, ID, or provider
- Filter to show only currently allowed models
Select multiple filters for increased granularity.
### Providers Tab
---
Lists all providers. For each provider you can:
- Toggle the entire provider on or off (blocks all current and future models from that provider)
- Filter by data policy (trains on data, retains prompts)
- Filter by provider location / datacenter region
When you toggle a provider off, all models it offers become unavailable to team members. Re-enabling the provider restores access to all its models.
### Saving Changes
A status bar appears at the bottom of the page whenever you have unsaved changes. Click **Save** to apply your changes, or **Cancel** to discard them. Changes take effect immediately for all team members once saved.
## Filtering Options
Use filters to find the models or providers you want to block:
| Filter | Tab | Description |
| ------------------- | ------------------ | ----------------------------------------------------- |
| **Search** | Models & Providers | Filter by name, ID, or provider slug |
| **Enabled only** | Models & Providers | Show only currently allowed items |
| **Trains on data** | Providers | Filter by whether the provider trains on user prompts |
| **Retains prompts** | Providers | Filter by whether the provider retains user prompts |
| **Location** | Providers | Filter by provider headquarters or datacenter country |
## Example Use Cases
- **Security-first teams**: Disable models that store prompts or operate outside your data region.
- **Cost control**: Limit access to higher-priced models.
- **Specialization**: Enable models that are optimized for specific tasks.
- **Data compliance**: Block providers that train on prompts or operate outside your required data region.
- **Cost control**: Block high-cost models to prevent accidental expensive usage.
- **Security policy**: Restrict access to a known set of approved providers.
---
## Notes
- Only **Admins** and **Owners** can modify model access.
- Updates propagate to all team members within seconds.
- Only **Owners** can modify model access controls.
- Individual users cannot override organization-level restrictions.
- Blocking a provider blocks all its models, including models added by that provider in the future.
- Unblocking a provider immediately restores access to all its models.
@@ -1,80 +0,0 @@
---
title: "Model/Provider Blocklist"
description: "Proposal to replace the model/provider allowlist with a blocklist approach for enterprise team management"
---
# Model/Provider Blocklist
## Overview
Enterprise organization administrators currently manage which models and providers their team members can use through an **allowlist** system in the Providers & Models settings page. This system stores two lists in organization settings: one for allowed models and one for allowed providers. It has proven confusing for customers and adds unnecessary friction.
- By default, an empty allowlist means "allow everything." Once an admin customizes any setting, new models added by providers are **not** automatically available -- the admin must manually approve each one.
- An "Allow all current and future models" checkbox was added per-provider to address this. It works by adding a provider wildcard entry to the model allow list, which allows any model offered by that provider (including future ones). However, it has a critical flaw: if an admin disables one specific model that was allowed via the wildcard, the wildcard itself is removed. The admin is then forced back into manual per-model curation. Additionally, you have to set this manually for each provider.
- The net result is that admins must either allow everything wholesale or commit to ongoing manual curation of hundreds of model/provider combinations.
This proposal replaces the allowlist with a **blocklist** approach. The default behavior becomes "everything is allowed unless explicitly blocked," which eliminates the ongoing maintenance burden while still giving admins precise control.
## Requirements
- This feature remains restricted to **enterprise plans only**, consistent with the current allowlist system. Teams-plan organizations get unrestricted model/provider access.
- All models and providers are **allowed by default**, including newly added ones.
- Admins can block an entire provider (all current and future models from that provider).
- Admins can block a specific model/provider combination without affecting other providers offering the same model.
- The UI must make it easy to find and block specific models across a large catalog (300+ models, 65+ providers).
- Migration from the existing allowlist data must be handled without disrupting current customer configurations.
### Non-requirements
- Blocking a model across _all_ current and future providers (e.g., "block model X regardless of who offers it"). This can be added later if there is demand, but adds complexity and is not needed for the initial implementation.
- Per-user or per-team blocklists. This proposal covers organization-level controls only.
- Cost controls or spending limits per model. This is a separate concern.
## System Design
### Core Semantics
The system shifts from "deny by default, explicitly allow" to **"allow by default, explicitly deny"**:
| Scenario | Behavior |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| No blocklist entries | All models and providers are available (default) |
| Provider blocked | All current and future models from that provider are unavailable. The same model may still be available from other providers. |
| Specific model/provider combo blocked | Only that specific combination is unavailable. The model remains available from other providers, and other models from that provider remain available. |
### Plan Gating
Blocklist enforcement only applies to enterprise-plan organizations. For non-enterprise organizations (including teams plans), the blocklist fields are ignored and all models/providers are available. This mirrors the current allowlist behavior.
The mutation to update blocklists must remain gated behind organization owner permissions and an enterprise plan check, consistent with the existing allowlist mutation.
### Implementation design
TBD
### UI Design
Replace the current dual-tab (Models / Providers) layout with a **single unified view** organized by provider:
**Main view: Provider list with expandable models**
- A flat list of all providers, each expandable to show its offered models.
- Each provider row has a block/unblock toggle. Blocking a provider visually marks all its models as blocked.
- Each model row (within an expanded provider) has a block/unblock toggle for that specific model/provider combination.
- A **free-text search/filter box** at the top filters both providers and models. For example, typing "K2.5" filters the provider list to only those offering a matching model, and within each provider only shows the matching models. This makes it easy to block a specific model across select providers. Providers are auto-expanded to show the matching models.
- Blocked items are visually distinct (e.g., a red/muted treatment) so the current block state is immediately clear.
- A summary indicator shows total blocked count (e.g., "3 providers blocked, 7 model combinations blocked").
**Interaction examples:**
| Action | Result |
| --------------------------------------- | --------------------------------------------------------------------------------- |
| Block provider "Chutes" | All Chutes models become unavailable. Future models from Chutes are also blocked. |
| Search "K2.5", block it under Fireworks | Only K2.5 via Fireworks is blocked. K2.5 via other providers is unaffected. |
## Features for the Future
- **Cross-provider model blocking**: Block a model ID across all current and future providers (e.g., "block anthropic/claude-opus-4.6 regardless of which provider serves it"). Deferred unless there is significant demand.
- **Per-team / per-project blocklists**: Allow different teams within an organization to have different blocklist policies.
- **Cost-based controls**: Automatically block models above a certain price threshold.
- **Temporary blocks**: Time-limited blocks for models under evaluation or during incident response.
@@ -1,4 +1,10 @@
module.exports = [
{
source: "/docs/contributing/architecture/model-provider-blocklist",
destination: "/docs/collaborate/enterprise/model-access-controls",
basePath: false,
permanent: true,
},
{
source: "/docs/features/custom-modes",
destination: "/docs/customize/custom-modes",