mirror of
https://github.com/Kilo-Org/kilocode.git
synced 2026-09-24 16:02:55 +08:00
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:
@@ -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",
|
||||
|
||||
Reference in New Issue
Block a user