feat: gate passthrough methods by virtual key provider config

[TejasGhatte]

Summary

Introduces an allow_passthrough flag on virtual key provider configs that gates access to passthrough API endpoints on a per-provider basis. Previously, any virtual key could use passthrough endpoints for any provider without restriction. This change enforces a deny-by-default policy: passthrough must be explicitly enabled per provider on each virtual key.

Changes

• Added AllowPassthrough bool field to TableVirtualKeyProviderConfig with a default:false GORM tag, enforcing deny-by-default for all existing and new provider configs.
• Added a database migration (migrationAddAllowPassthroughToProviderConfig) that adds the allow_passthrough column to the virtual key provider config table, with rollback support.
• Added DecisionPassthroughBlocked decision type and a corresponding 403 error response in EvaluateGovernanceRequest.
• Added checkPassthroughPermission in the governance plugin's PreLLMHook, which intercepts passthrough and passthrough-stream requests and short-circuits with a 403 if the VK's provider config does not have AllowPassthrough set to true.
• Exposed allow_passthrough in the HTTP handler for both create and update virtual key endpoints, mapping it through to the provider config table.
• Added allow_passthrough to the UI type definitions (VirtualKeyProviderConfig, VirtualKeyProviderConfigRequest, VirtualKeyProviderConfigUpdateRequest) and form schema.
• Added a PASSTHROUGH_ENABLED_PROVIDERS constant (openai, anthropic, gemini, vertex, azure) used to conditionally render the passthrough toggle in the UI.
• Added an "Allow Passthrough API" toggle in the virtual key create/edit sheet, visible only for providers in PASSTHROUGH_ENABLED_PROVIDERS.
• Added a "Passthrough API" status badge in the virtual key details sheet, also gated to PASSTHROUGH_ENABLED_PROVIDERS.

Design decision: The flag is deny-by-default. Existing provider configs that relied on passthrough will need to be explicitly opted in after this migration runs.

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

1. Create a virtual key with a provider config for openai and allow_passthrough: false (or omit it). Attempt a passthrough request using that virtual key — expect a 403 with decision passthrough_not_allowed.
2. Update the same virtual key to set allow_passthrough: true for openai. Retry the passthrough request — expect it to succeed.
3. Verify the UI toggle appears only for providers in PASSTHROUGH_ENABLED_PROVIDERS and that the details sheet reflects the correct enabled/disabled badge.
4. Run the migration against an existing database and confirm the allow_passthrough column is added with a default of false.

go test ./...

cd ui
pnpm i
pnpm build

Breaking changes

• Yes
• No

Any virtual key that was previously using passthrough endpoints will have passthrough blocked after this migration runs, since allow_passthrough defaults to false. Operators must explicitly enable allow_passthrough on the relevant provider configs for each virtual key that requires passthrough access.

Security considerations

This change tightens the authorization surface for passthrough endpoints. Previously, possession of a valid virtual key was sufficient to use passthrough for any provider. Now, passthrough access must be explicitly granted per provider on each virtual key, reducing the risk of unintended direct provider access through governance-controlled keys.

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

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 6 committers have signed the CLA.

✅ BearTS
✅ Vaibhav701161
❌ tejas ghatte
❌ TejasGhatte
❌ roroghost17
❌ akshaydeo

---

tejas ghatte seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Per-provider passthrough API access control for virtual keys (OpenAI, Anthropic, Gemini, Vertex, Azure).
  • UI: "Allow Passthrough API" toggle and status badge per provider (disabled by default).

• API

  • Create/update endpoints accept a passthrough flag for provider configs; settings are persisted.

• Enforcement

  • Passthrough requests are blocked unless explicitly enabled for the provider.

• Chores

  • Database migration applied to store the new setting.

Walkthrough

Adds a deny-by-default per-provider "allow_passthrough" flag for virtual keys: DB migration and model field, governance checks (blocked with 403), HTTP request schemas and handlers, TypeScript API types, UI constants, form inputs, and details view updates.

Changes

Passthrough API Permission Control

Layer / File(s)	Summary
Database schema and data model framework/configstore/migrations.go, framework/configstore/tables/virtualkey.go	Migration to add allow_passthrough column; TableVirtualKeyProviderConfig gains AllowPassthrough bool with default false.
Governance permission enforcement plugins/governance/resolver.go, plugins/governance/main.go	Adds DecisionPassthroughBlocked; isPassthroughAllowedForVK and GovernancePlugin.checkPassthroughPermission enforce deny-by-default passthrough; PreLLMHook short-circuits denied passthrough requests and VK context attachment is centralized via attachVKContext.
HTTP request contracts and handler persistence transports/bifrost-http/handlers/governance.go	CreateVirtualKeyRequest/UpdateVirtualKeyRequest accept allow_passthrough; creation and update handlers persist and reconcile the flag on provider configs.
UI types and constants ui/lib/types/governance.ts, ui/lib/constants/governance.ts	Adds optional allow_passthrough to TS interfaces; exports PASSTHROUGH_ENABLED_PROVIDERS set for UI gating.
Virtual key form configuration and UI ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx	Form defaults map existing allow_passthrough (fallback false), new configs default to false, normalization preserves flag, and conditional "Allow Passthrough API" switch updates provider config.
Virtual key details view ui/app/workspace/virtual-keys/views/virtualKeyDetailsSheet.tsx	Details sheet conditionally shows "Passthrough API" status badge for providers in PASSTHROUGH_ENABLED_PROVIDERS reflecting config.allow_passthrough.

Sequence Diagram

sequenceDiagram
  participant Client as Client Request
  participant PreLLM as PreLLMHook
  participant GovCheck as GovernancePlugin.checkPassthroughPermission
  participant VKStore as Virtual Key Store
  participant Eval as EvaluateGovernanceRequest

  Client->>PreLLM: PassthroughRequest + VirtualKey
  PreLLM->>GovCheck: checkPassthroughPermission(provider, virtualKey)
  GovCheck->>VKStore: load virtual key provider configs
  VKStore-->>GovCheck: provider config (allow_passthrough: false)
  GovCheck-->>PreLLM: BifrostError 403 (passthrough not enabled)
  PreLLM->>Eval: DecisionPassthroughBlocked
  Eval-->>Client: 403 Passthrough not enabled

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

• danpiths
• roroghost17
• akshaydeo

Poem

🐰 A little gate on keys so bright,
Deny by default, keep wrongs from flight,
Toggle in forms and badges to show,
From DB to governance the check will go.
Hooray for configs that guard the flow!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 77.78% 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: gating passthrough methods by virtual key provider config, which is the core change across all modified files.
Description check	✅ Passed	The description is comprehensive and well-structured, covering summary, changes, type of change, affected areas, testing steps, breaking changes, and security considerations as required by the template.
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 05-25-feat_gate_passthrough_methods_by_virtual_key_provider_config

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"

---

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

[TejasGhatte]

• feat: gate passthrough methods by virtual key provider config #3734 👈 (View in Graphite)
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 5/5

The change is safe to merge. The core enforcement logic is correct — deny-by-default, proper nil handling on updates, and idempotent migration.

The migration is guarded with HasColumn checks and has a rollback path. The *bool pointer in UpdateVirtualKeyRequest correctly distinguishes omitted from explicitly false. The in-memory store lookup in checkPassthroughPermission is fast and ProviderConfigs is preloaded when VKs are cached. The passthrough check ordering and double VK fetch are minor inefficiencies with no correctness impact.

plugins/governance/main.go and plugins/governance/resolver.go — the ordering of checkPassthroughPermission relative to EvaluateGovernanceRequest and the redundant store lookup are worth a follow-up but do not block merging.

Important Files Changed

Filename	Overview
plugins/governance/main.go	Adds passthrough VK-context attachment in HTTPTransportPreHook, attachVKContext helper to eliminate duplicate team/customer attribution code, and passthrough permission enforcement in PreLLMHook; passthrough check ordering (after EvaluateGovernanceRequest) is suboptimal.
plugins/governance/resolver.go	Adds DecisionPassthroughBlocked decision constant, isPassthroughAllowedForVK helper, and checkPassthroughPermission with correct deny-by-default logic; redundant GetVirtualKey fetch noted.
framework/configstore/migrations.go	Adds migrationAddAllowPassthroughToProviderConfig with proper idempotent HasColumn guard and rollback support; wired correctly into triggerMigrations.
framework/configstore/tables/virtualkey.go	Adds AllowPassthrough bool field with default:false GORM tag; correct deny-by-default semantics, consistent with existing fields.
transports/bifrost-http/handlers/governance.go	Uses bool for CreateVirtualKeyRequest and *bool for UpdateVirtualKeyRequest (nil = preserve existing) with correct nil-guard on update and new-provider-config paths.
ui/lib/constants/governance.ts	Adds PASSTHROUGH_ENABLED_PROVIDERS Set; values match backend ModelProvider string constants.
ui/lib/types/governance.ts	Adds optional allow_passthrough to all three provider config type shapes with correct optionality.
ui/app/workspace/virtual-keys/views/virtualKeySheet.tsx	Adds passthrough toggle gated by PASSTHROUGH_ENABLED_PROVIDERS, initialised to false on new configs; schema and handler wiring look correct.
ui/app/workspace/virtual-keys/views/virtualKeyDetailsSheet.tsx	Adds Passthrough API status badge gated to PASSTHROUGH_ENABLED_PROVIDERS; straightforward UI addition.

_{Reviews (3): Last reviewed commit: "feat: gate passthrough methods by virtua..." | Re-trigger Greptile}

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

transports/bifrost-http/handlers/governance.go (1)

661-705: 🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win

Consider validating allow_passthrough against supported providers.

The handler accepts allow_passthrough: true for any configured provider, but only openai, anthropic, gemini, vertex, and azure support passthrough (per PASSTHROUGH_ENABLED_PROVIDERS in the UI). Direct API calls could set this flag for unsupported providers, storing inconsistent data. While the governance plugin enforces passthrough permissions at runtime, adding validation here would prevent data inconsistency and provide immediate feedback.

🛡️ Proposed validation

Define the supported provider set in the Go backend:

+var passthroughEnabledProviders = map[schemas.ModelProvider]struct{}{
+	"openai":     {},
+	"anthropic":  {},
+	"gemini":     {},
+	"vertex":     {},
+	"azure":      {},
+}
+
 			providerConfig := &configstoreTables.TableVirtualKeyProviderConfig{
 				VirtualKeyID:      vk.ID,
 				Provider:          string(providerName),
 				Weight:            pc.Weight,
 				AllowedModels:     pc.AllowedModels,
 				BlacklistedModels: pc.BlacklistedModels,
 				AllowAllKeys:      allowAllKeys,
+				AllowPassthrough:  pc.AllowPassthrough,
-				AllowPassthrough:  pc.AllowPassthrough,
 				Keys:              keys,
 			}
+
+			if pc.AllowPassthrough {
+				if _, ok := passthroughEnabledProviders[providerName]; !ok {
+					return &badRequestError{err: fmt.Errorf("provider %s does not support passthrough API", providerName)}
+				}
+			}

Apply the same validation in the update path (lines 1113-1122 for new configs and lines 1189-1211 for existing configs).

🤖 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 `@transports/bifrost-http/handlers/governance.go` around lines 661 - 705, The
code allows pc.AllowPassthrough=true for any provider, which can store invalid
passthrough flags; when building providerConfig in the provider loop
(providerName, pc.AllowPassthrough, providerSet), validate pc.AllowPassthrough
against a backend whitelist of passthrough-capable providers (same set used by
the UI: openai, anthropic, gemini, vertex, azure) and return a badRequestError
if true for an unsupported provider; apply the identical validation to the
update-path provider handling blocks that construct new and existing provider
configs so passthrough is rejected consistently server-side.

🤖 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 `@plugins/governance/main.go`:
- Around line 1467-1475: The passthrough permission check (the block that checks
req.RequestType == schemas.PassthroughRequest || req.RequestType ==
schemas.PassthroughStreamRequest and calls p.checkPassthroughPermission with
virtualKeyValue and provider) runs too early and can leak provider-config state
for blocked virtual keys; move or guard that logic so it only executes after
EvaluateGovernanceRequest has validated the virtual key (i.e., call
p.checkPassthroughPermission only if EvaluateGovernanceRequest succeeds and the
VK is not blocked), or fold the passthrough check into the normal VK evaluation
flow so that virtual_key_blocked takes precedence over returning
passthrough_not_allowed.

In `@ui/lib/types/governance.ts`:
- Line 95: VirtualKeyProviderConfig's allow_passthrough is currently required
but the server may omit it; update the type so the property is optional (e.g.,
allow_passthrough?: boolean) in the VirtualKeyProviderConfig declaration and
adjust any places that assume it always exists (use safe checks or defaulting).
Ensure references to allow_passthrough in validation or usage handle undefined
rather than only boolean values.

---

Outside diff comments:
In `@transports/bifrost-http/handlers/governance.go`:
- Around line 661-705: The code allows pc.AllowPassthrough=true for any
provider, which can store invalid passthrough flags; when building
providerConfig in the provider loop (providerName, pc.AllowPassthrough,
providerSet), validate pc.AllowPassthrough against a backend whitelist of
passthrough-capable providers (same set used by the UI: openai, anthropic,
gemini, vertex, azure) and return a badRequestError if true for an unsupported
provider; apply the identical validation to the update-path provider handling
blocks that construct new and existing provider configs so passthrough is
rejected consistently server-side.

🪄 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: bcddb9ae-1476-4757-8d52-956e9afdd1ce

📥 Commits

Reviewing files that changed from the base of the PR and between 584816b and cb68a1a.

📒 Files selected for processing (9)

• framework/configstore/migrations.go
• framework/configstore/tables/virtualkey.go
• plugins/governance/main.go
• plugins/governance/resolver.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/constants/governance.ts
• 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 `@plugins/governance/main.go`:
- Around line 1474-1479: The passthrough denial returns early without marking
the request as governance-rejected; update the block that handles
schemas.PassthroughRequest and schemas.PassthroughStreamRequest so that when
p.checkPassthroughPermission(ctx, virtualKeyValue, provider) returns an error
you first set the request's governance-rejection marker (the same field/key used
elsewhere for blocked requests, e.g., req.GovernanceRejected or the repo's
equivalent metadata flag) and then return req,
&schemas.LLMPluginShortCircuit{Error: bifrostErr}, nil; modify the code in the
branch where virtualKeyValue != "" and bifrostErr != nil to set that marker
before the short-circuit return.

🪄 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: 915a806b-7235-4b2e-afb3-592a649d6e2f

📥 Commits

Reviewing files that changed from the base of the PR and between cb68a1a and e6fa30e.

📒 Files selected for processing (9)

• framework/configstore/migrations.go
• framework/configstore/tables/virtualkey.go
• plugins/governance/main.go
• plugins/governance/resolver.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/constants/governance.ts
• 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 `@plugins/governance/main.go`:
- Around line 1778-1796: attachVKContext currently only sets governance
TeamID/CustomerID when the FK pointers vk.TeamID/vk.CustomerID are non-nil, but
callers can load relations (vk.Team or vk.Customer) with the ID present even
when the FK pointers are nil; update attachVKContext to also populate
schemas.BifrostContextKeyGovernanceTeamID and
schemas.BifrostContextKeyGovernanceCustomerID from vk.Team.ID and vk.Customer.ID
when vk.TeamID/vk.CustomerID are nil but vk.Team/vk.Customer are non-nil (ensure
you handle the actual field name/type of the nested ID and any pointer/value
differences), while continuing to set the Team/Customer names as before using
ctx.SetValue.

🪄 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: 44a7cad8-99cc-4dcc-acb4-0f679fef9058

📥 Commits

Reviewing files that changed from the base of the PR and between e6fa30e and f156425.

📒 Files selected for processing (9)

• framework/configstore/migrations.go
• framework/configstore/tables/virtualkey.go
• plugins/governance/main.go
• plugins/governance/resolver.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/constants/governance.ts
• ui/lib/types/governance.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Populate governance IDs from loaded relations too.

attachVKContext only writes TeamID/CustomerID when the FK pointer fields are non-nil. This plugin already has to handle VKs whose Team/Customer relations are populated while those FK pointers are nil, so that shape is real. In those cases the new shared helper drops governance IDs for passthrough, large-payload, and realtime paths, which can break downstream attribution that keys off the IDs.

🔧 Suggested fix

 func attachVKContext(ctx *schemas.BifrostContext, vk *configstoreTables.TableVirtualKey) {
 	if vk == nil {
 		return
 	}
 	if vk.TeamID != nil {
 		ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamID, *vk.TeamID)
+	} else if vk.Team != nil {
+		ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamID, vk.Team.ID)
 	}
 	if vk.Team != nil {
 		ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamName, vk.Team.Name)
 	}
 	if vk.CustomerID != nil {
 		ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerID, *vk.CustomerID)
+	} else if vk.Customer != nil {
+		ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerID, vk.Customer.ID)
+	} else if vk.Team != nil && vk.Team.Customer != nil {
+		ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerID, vk.Team.Customer.ID)
 	}
 	if vk.Customer != nil {
 		ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerName, vk.Customer.Name)
+	} else if vk.Team != nil && vk.Team.Customer != nil {
+		ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerName, vk.Team.Customer.Name)
 	}
 }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// attachVKContext sets team and customer governance context values from the virtual key,
	// enabling correct attribution in logs and cost tracking.
	func attachVKContext(ctx *schemas.BifrostContext, vk *configstoreTables.TableVirtualKey) {
	if vk == nil {
	return
	}
	if vk.TeamID != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamID, *vk.TeamID)
	}
	if vk.Team != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamName, vk.Team.Name)
	}
	if vk.CustomerID != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerID, *vk.CustomerID)
	}
	if vk.Customer != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerName, vk.Customer.Name)
	}
	}
	// attachVKContext sets team and customer governance context values from the virtual key,
	// enabling correct attribution in logs and cost tracking.
	func attachVKContext(ctx *schemas.BifrostContext, vk *configstoreTables.TableVirtualKey) {
	if vk == nil {
	return
	}
	if vk.TeamID != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamID, *vk.TeamID)
	} else if vk.Team != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamID, vk.Team.ID)
	}
	if vk.Team != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceTeamName, vk.Team.Name)
	}
	if vk.CustomerID != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerID, *vk.CustomerID)
	} else if vk.Customer != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerID, vk.Customer.ID)
	} else if vk.Team != nil && vk.Team.Customer != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerID, vk.Team.Customer.ID)
	}
	if vk.Customer != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerName, vk.Customer.Name)
	} else if vk.Team != nil && vk.Team.Customer != nil {
	ctx.SetValue(schemas.BifrostContextKeyGovernanceCustomerName, vk.Team.Customer.Name)
	}
	}

🤖 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 `@plugins/governance/main.go` around lines 1778 - 1796, attachVKContext
currently only sets governance TeamID/CustomerID when the FK pointers
vk.TeamID/vk.CustomerID are non-nil, but callers can load relations (vk.Team or
vk.Customer) with the ID present even when the FK pointers are nil; update
attachVKContext to also populate schemas.BifrostContextKeyGovernanceTeamID and
schemas.BifrostContextKeyGovernanceCustomerID from vk.Team.ID and vk.Customer.ID
when vk.TeamID/vk.CustomerID are nil but vk.Team/vk.Customer are non-nil (ensure
you handle the actual field name/type of the nested ID and any pointer/value
differences), while continuing to set the Team/Customer names as before using
ctx.SetValue.