feat(governance): add virtual key blocked models

[Vaibhav701161]

Summary

Adds blocked model support for virtual key provider configurations.

Provider keys already supported both allowed and blocked models, but virtual key provider configs only supported allowed models. This PR adds the missing blocked model flow for virtual keys, so specific models can be denied at the VK provider-config level.

Changes

• Added blacklisted_models to virtual key provider configs.
• Added a configstore migration for the new blacklisted_models column.
• Updated virtual key create/update handlers to validate, persist, and return blocked models.
• Added governance checks to reject virtual key requests when the requested model is blocked.
• Made blocked models take priority over allowed models.
• Updated virtual key model filtering to respect blocked models.
• Added Blocked Models UI under provider configurations in the virtual key create/edit sheet.
• Added blocked model display in the virtual key details sheet.
• Updated frontend governance types for virtual key provider configs.

This follows the existing provider-key blocked model behavior instead of introducing a separate flow.

Behavior:

• Empty blacklisted_models means no models are blocked.
• ["*"] blocks all models for that VK provider config.
• If the same model exists in both allowed and blocked models, the blocked list wins.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

Local UI flow:

Start Bifrost locally with embedded UI on port 9090, then open:

http://localhost:9090/workspace/governance/virtual-keys

Steps tested:

1. Open Virtual Keys.
2. Create or edit a virtual key.
3. Expand a provider config.
4. Confirm Blocked Models appears below Allowed Models.
5. Select a blocked model and save.
6. Reopen the virtual key and confirm the blocked model is still shown.
7. Refresh the page and confirm the value persists.

Runtime validation:

1. Configure a VK provider config with allowed_models: ["*"] and blacklisted_models: ["<model-to-block>"].
2. Send a request through that virtual key using the blocked model.

Expected: request is rejected.

3. Send a request through the same virtual key using a model not present in blacklisted_models.

Expected: request succeeds.

4. Configure the same model in both allowed_models and blacklisted_models.

Expected: request is rejected because blocked models take priority.

5. Configure blacklisted_models: [].

Expected: existing virtual key behavior remains unchanged.

Sanity checks:

go test ./framework/configstore/... ./plugins/governance/... ./transports/bifrost-http/handlers/...

UI check:

cd ui && pnpm build

Screenshots/Recordings

Added a recording showing the new Blocked Models field in the virtual key provider configuration flow.

pr-896.mp4

Breaking changes

• Yes
• No

Related issues

BF-896

Security considerations

This change improves virtual-key governance by allowing specific models to be denied for a VK provider config.

No provider secrets, customer keys, auth tokens, or PII are exposed or stored by this change. Existing provider-key behavior is unchanged.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Per-provider model blacklist support in virtual key configs (UI form, badges, wildcard)
  • API accepts and persists provider-level blacklisted models on create/update

• Behavior Change

  • Blacklists are enforced before allow checks: providers that blacklist a model are excluded during selection and routing

• Chores

  • Migration adds blacklisted_models column and backfills existing rows; config hashes recomputed after backfill

Walkthrough

This PR adds a model blacklist feature to virtual key provider configurations, implementing deny-by-default filtering across the database schema, governance routing logic, API handlers, and user-facing UI to allow administrators to block specific models (or all models via wildcard) per provider.

Changes

Virtual Key Model Blacklist Feature

Layer / File(s)	Summary
Schema, model validation, and JSON marshaling framework/configstore/migrations.go, framework/configstore/tables/virtualkey.go	Adds blacklisted_models JSON column to governance_virtual_key_provider_configs with idempotent migration and backfill. Extends TableVirtualKeyProviderConfig struct with BlacklistedModels field, validates it in BeforeSave, and ensures MarshalJSON always emits it as a non-null array.
Governance evaluation: blacklist-first filtering plugins/governance/resolver.go, plugins/governance/utils.go, plugins/governance/main.go	Implements early blacklist checks in isModelAllowed, filterModelsForVirtualKey, and loadBalanceProvider using deny-by-default semantics: blocked models immediately return false before allow-list or model-catalog evaluation occurs.
API request contracts for creation and update transports/bifrost-http/handlers/governance.go	Extends CreateVirtualKeyRequest and UpdateVirtualKeyRequest DTOs with optional blacklisted_models field in provider config entries.
Virtual key create and update handler logic transports/bifrost-http/handlers/governance.go	Validates and persists blacklisted_models during virtual key creation and update for both newly created and existing provider configs.
Frontend TypeScript type definitions ui/lib/types/governance.ts	Adds blacklisted_models: string[] to VirtualKeyProviderConfig interface and optional blacklisted_models?: string[] to request DTOs.
Virtual key form UI: blacklist editing ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx	Extends provider configuration form with schema field, initialization from existing configs, and a "Blocked Models" multiselect component supporting wildcard blocking of all models.
Virtual key details view: display and layout ui/app/workspace/virtual-keys/views/virtualKeyDetailsSheet.tsx	Adds read-only "Blocked Models" badge display in provider config details showing all-models-blocked, specific blocked models, or none; adjusts rate-limit reset line formatting.

Sequence Diagram (high-level governance flow):

sequenceDiagram
  participant Client
  participant BifrostHandler as BifrostHTTPHandler
  participant Resolver as isModelAllowed
  participant ProviderLoader as loadBalanceProvider
  participant DB as GovernanceTable
  Client->>BifrostHandler: request using modelStr
  BifrostHandler->>Resolver: isModelAllowed(modelStr)
  Resolver->>DB: read provider configs
  alt any config blacklists modelStr
    Resolver-->>BifrostHandler: return false
  else
    Resolver->>ProviderLoader: continue with allow checks
    ProviderLoader->>DB: apply blacklist pre-pass, select providers
    ProviderLoader-->>BifrostHandler: selected provider(s)
  end
  BifrostHandler-->>Client: response

Loading

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

• danpiths
• roroghost17

🐰 A blacklist for the models so fine,

Provider configs now will decline,

Any blocked by a star or by name,

Forms and handlers all sing the same tune,

Governance hops forward beneath the moon!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main feature: adding blocked models capability to virtual key configurations, which is the primary purpose of this changeset.
Description check	✅ Passed	The description covers all key template sections: summary, detailed changes, type of change, affected areas, testing steps, screenshots, breaking changes, related issues, security considerations, and most checklist items. Content is comprehensive and well-structured.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/bf-896-vk-blacklisted-models

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.12.2)

level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies"

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Confidence Score: 5/5

Safe to merge; the change follows well-established patterns already used for provider-key denylists, and the three governance enforcement sites are updated consistently.

The implementation closely mirrors existing BlacklistedModels logic on provider keys — same schemas.BlackList type, same two-pass (blacklist-first) evaluation, same migration pattern, and same nil-to-empty-array guard in MarshalJSON. No logic divergence was found between the three enforcement sites.

No files require special attention; governance enforcement sites are consistent across resolver.go, main.go, and utils.go.

Important Files Changed

Filename	Overview
plugins/governance/resolver.go	Refactors isModelAllowed into two passes: blacklist scan first (returning false on any match), then allowlist scan (returning true on any match). Also fixes a pre-existing behaviour where the first non-matching allowlist config would immediately return false even if a later config would permit the model.
plugins/governance/main.go	Adds a pre-pass in loadBalanceProvider that builds a blacklistedProviders map; all configs for a provider are excluded from routing if any of that provider's configs blacklists the requested model.
plugins/governance/utils.go	Adds an isBlocked pre-pass in filterModelsForVirtualKey (model listing) before the existing allowlist loop, consistent with the resolver and load-balancer changes.
framework/configstore/migrations.go	Adds migration to introduce blacklisted_models JSON column, backfill existing rows with empty arrays, and recompute config hashes — follows the same pattern used by the prior allow_all_keys migration.
framework/configstore/tables/virtualkey.go	Adds BlacklistedModels schemas.BlackList field with GORM JSON serializer; extends BeforeSave validation and MarshalJSON (nil → empty-array guard) to cover the new field in the same way AllowedModels is handled.
transports/bifrost-http/handlers/governance.go	Adds BlacklistedModels field to CreateVirtualKeyRequest / UpdateVirtualKeyRequest; adds Validate() call and wires the field into both create and update handler code paths.
ui/lib/types/governance.ts	Adds blacklisted_models: string[] (required) to VirtualKeyProviderConfig and optional blacklisted_models?: string[] to both request interfaces.
ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx	Adds blocked models ModelMultiselect component under provider configs with correct wildcard toggle logic (prevents mixing "*" with explicit entries), matching the allowed-models pattern.
ui/app/workspace/virtual-keys/views/virtualKeyDetailsSheet.tsx	Adds a "Blocked Models" read-only row in the details sheet with destructive badge styling for blocked models and "All Models Blocked" banner for the wildcard case.

_{Reviews (3): Last reviewed commit: "feat(governance): add virtual key blocke..." | Re-trigger Greptile}

[coderabbitai]

🧹 Nitpick comments (1)

ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx (1)

238-238: 💤 Low value

Consider defensive fallback for robustness.

While the TypeScript type guarantees blacklisted_models is present, adding a fallback (config.blacklisted_models || []) would protect against edge cases during migration or with cached data. Note that line 1127 already uses this pattern for the same field.

This also applies to allowed_models at line 237, but that's a pre-existing pattern outside this PR's scope.

🛡️ Optional defensive enhancement

-					blacklisted_models: config.blacklisted_models,
+					blacklisted_models: config.blacklisted_models || [],

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx` at line 238, In
virtualKeySheet.tsx update the object property that sets blacklisted_models to
use a defensive fallback (e.g., replace config.blacklisted_models with
config.blacklisted_models || []) so that if config is missing or has
stale/migrated data we pass an empty array; keep allowed_models unchanged for
now since it’s handled elsewhere, and search for occurrences of
config.blacklisted_models in the file (including the object created around the
diff snippet) to apply the same fallback consistently.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx`:
- Line 238: In virtualKeySheet.tsx update the object property that sets
blacklisted_models to use a defensive fallback (e.g., replace
config.blacklisted_models with config.blacklisted_models || []) so that if
config is missing or has stale/migrated data we pass an empty array; keep
allowed_models unchanged for now since it’s handled elsewhere, and search for
occurrences of config.blacklisted_models in the file (including the object
created around the diff snippet) to apply the same fallback consistently.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c2b724ec-5856-4405-9983-c3a1f6ea1dac

📥 Commits

Reviewing files that changed from the base of the PR and between b287d55 and e585f67.

📒 Files selected for processing (9)

• framework/configstore/migrations.go
• framework/configstore/tables/virtualkey.go
• plugins/governance/main.go
• plugins/governance/resolver.go
• plugins/governance/utils.go
• transports/bifrost-http/handlers/governance.go
• ui/app/workspace/virtual-keys/views/virtualKeyDetailsSheet.tsx
• ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx
• ui/lib/types/governance.ts

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@framework/configstore/migrations.go`:
- Around line 8554-8561: After adding and backfilling the blacklisted_models
column on TableVirtualKeyProviderConfig, recompute and persist the owning
virtual keys' config_hash so they don't appear dirty: find all virtual keys
referencing provider configs (rows in the virtual keys table whose
provider_config_id matches entries in governance_virtual_key_provider_configs),
for each affected virtual key re-run the same config-hash computation used
elsewhere (the existing config hash routine used to populate the config_hash
field) against the updated TableVirtualKeyProviderConfig (including the new
blacklisted_models value) and update the virtual key's config_hash column;
perform this update within the same migration transaction after the backfill so
the persisted state is consistent.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 9e14f7b5-a9ed-4898-aa14-1295e5316400

📥 Commits

Reviewing files that changed from the base of the PR and between e585f67 and 5e30cc3.

📒 Files selected for processing (9)

• framework/configstore/migrations.go
• framework/configstore/tables/virtualkey.go
• plugins/governance/main.go
• plugins/governance/resolver.go
• plugins/governance/utils.go
• transports/bifrost-http/handlers/governance.go
• ui/app/workspace/virtual-keys/views/virtualKeyDetailsSheet.tsx
• ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx
• ui/lib/types/governance.ts

[coderabbitai]

♻️ Duplicate comments (1)

framework/configstore/migrations.go (1)

8564-8582: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Avoid full-table VK preload during hash recomputation.

Line 8564 loads every VK (with nested preloads) in one shot inside the migration transaction. On larger deployments this can significantly increase lock time and memory usage during startup. Recompute hashes only for affected VK IDs.

💡 Suggested fix

-				var virtualKeys []tables.TableVirtualKey
-				if err := tx.
-					Preload("ProviderConfigs").
-					Preload("ProviderConfigs.Keys").
-					Preload("MCPConfigs").
-					Find(&virtualKeys).Error; err != nil {
-					return fmt.Errorf("failed to fetch virtual keys for hash recomputation: %w", err)
-				}
-				for _, vk := range virtualKeys {
+				var modifiedVKIDs []string
+				if err := tx.Model(&tables.TableVirtualKeyProviderConfig{}).
+					Distinct("virtual_key_id").
+					Pluck("virtual_key_id", &modifiedVKIDs).Error; err != nil {
+					return fmt.Errorf("failed to query VK IDs for hash recomputation: %w", err)
+				}
+				for _, vkID := range modifiedVKIDs {
+					var vk tables.TableVirtualKey
+					if err := tx.
+						Preload("ProviderConfigs").
+						Preload("ProviderConfigs.Keys").
+						Preload("MCPConfigs").
+						First(&vk, "id = ?", vkID).Error; err != nil {
+						if err == gorm.ErrRecordNotFound {
+							continue
+						}
+						return fmt.Errorf("failed to reload VK %s for hash recomputation: %w", vkID, err)
+					}
 					newHash, err := GenerateVirtualKeyHash(vk)
 					if err != nil {
 						return fmt.Errorf("failed to generate hash for VK %s: %w", vk.ID, err)
 					}
 					if err := tx.Model(&tables.TableVirtualKey{}).
-						Where("id = ?", vk.ID).
+						Where("id = ?", vkID).
 						Update("config_hash", newHash).Error; err != nil {
-						return fmt.Errorf("failed to update config_hash for VK %s: %w", vk.ID, err)
+						return fmt.Errorf("failed to update config_hash for VK %s: %w", vkID, err)
 					}
 				}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@framework/configstore/migrations.go` around lines 8564 - 8582, Currently the
migration loads all TableVirtualKey records with deep Preloads into memory and
recomputes hashes, which causes long locks and high memory; change the logic to
select only the affected virtual key IDs (or query IDs in batches) and then for
each ID fetch the minimal row needed, call GenerateVirtualKeyHash(vk) and update
config_hash via tx.Model(&tables.TableVirtualKey{}).Where("id = ?",
id).Update(...). Use batching (e.g., FindInBatches or manual LIMIT/OFFSET) or
stream rows to avoid a full-table preload, and ensure you still preload only the
necessary relations for each vk before calling GenerateVirtualKeyHash.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Duplicate comments:
In `@framework/configstore/migrations.go`:
- Around line 8564-8582: Currently the migration loads all TableVirtualKey
records with deep Preloads into memory and recomputes hashes, which causes long
locks and high memory; change the logic to select only the affected virtual key
IDs (or query IDs in batches) and then for each ID fetch the minimal row needed,
call GenerateVirtualKeyHash(vk) and update config_hash via
tx.Model(&tables.TableVirtualKey{}).Where("id = ?", id).Update(...). Use
batching (e.g., FindInBatches or manual LIMIT/OFFSET) or stream rows to avoid a
full-table preload, and ensure you still preload only the necessary relations
for each vk before calling GenerateVirtualKeyHash.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 53650e44-0ad7-4121-aeb3-f86ef23d22be

📥 Commits

Reviewing files that changed from the base of the PR and between 5e30cc3 and 3dd7a49.

📒 Files selected for processing (9)

• framework/configstore/migrations.go
• framework/configstore/tables/virtualkey.go
• plugins/governance/main.go
• plugins/governance/resolver.go
• plugins/governance/utils.go
• transports/bifrost-http/handlers/governance.go
• ui/app/workspace/virtual-keys/views/virtualKeyDetailsSheet.tsx
• ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx
• ui/lib/types/governance.ts

[akshaydeo]

Merge activity

• May 21, 7:25 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• May 21, 7:25 PM UTC: @akshaydeo merged this pull request with Graphite.