docs: direct api key - #4208
Merged
Merged
Conversation
|
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. |
Contributor
📝 WalkthroughWalkthroughAdds docs for a direct API key bypass: a new ChangesDirect API Key Bypass Feature Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
TejasGhatte
marked this pull request as ready for review
June 9, 2026 11:58
Contributor
Confidence Score: 5/5Documentation-only change that accurately reflects the existing gateway implementation; no code logic is modified. All documented behavior — the double-gate requirement, virtual-key exclusion, three accepted key headers, and security denylist entry — was verified against transports/bifrost-http/lib/ctx.go. The schema description is now in sync with the implementation. No new executable code paths are introduced. No files require special attention. Important Files Changed
Reviews (2): Last reviewed commit: "docs: direct api key" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
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 `@docs/providers/request-options.mdx`:
- Around line 174-185: Add an explicit guardrail paragraph to the direct-key
section: instruct operators to never log or forward raw provider credentials
(Authorization: Bearer <key>, x-api-key, x-goog-api-key) and to exclude those
headers from any logging or header-forwarding configuration (e.g.,
logging_headers), and recommend tight header filtering when allowing
allow_direct_keys or when callers set x-bf-direct-key or
BifrostContextKeyDirectKey (schemas.Key) to prevent secret exposure.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 171f5371-77a6-455c-a7dd-5ee0dfeb0c13
📒 Files selected for processing (4)
docs/deployment-guides/config-json/client.mdxdocs/deployment-guides/config-json/schema-reference.mdxdocs/providers/request-options.mdxdocs/quickstart/go-sdk/context-keys.mdx
TejasGhatte
force-pushed
the
06-09-docs_direct_api_key
branch
from
June 9, 2026 12:16
241d20b to
d109742
Compare
Contributor
There was a problem hiding this comment.
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 `@docs/deployment-guides/config-json/schema-reference.mdx`:
- Line 65: Update the schema row for the boolean field allow_direct_keys to
explicitly list accepted header sources for the raw provider key:
"Authorization: Bearer <key>", "x-api-key", and "x-goog-api-key"; modify the
description text for allow_direct_keys to read something like: Let callers
bypass the key pool with x-bf-direct-key: true plus a raw provider key supplied
via Authorization: Bearer <key>, x-api-key, or x-goog-api-key so it matches the
client config guide and schema contract.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 003d4940-8a55-4c3f-9131-5ab377644bf8
📒 Files selected for processing (5)
docs/deployment-guides/config-json/client.mdxdocs/deployment-guides/config-json/schema-reference.mdxdocs/providers/request-options.mdxdocs/quickstart/go-sdk/context-keys.mdxtransports/config.schema.json
Pratham-Mishra04
approved these changes
Jun 9, 2026
Collaborator
Merge activity
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Documents the new
allow_direct_keysgateway configuration option and theBifrostContextKeyDirectKeycontext key, which together allow callers to supply a raw provider API key directly to Bifrost, bypassing the registered key pool. This is intended for multi-tenant setups where each caller manages their own provider credentials.Changes
allow_direct_keysboolean field to the client config and schema reference tables, defaulting tofalserequest-options.mdxcovering gateway usage (viax-bf-direct-key: true+ a raw key inAuthorization,x-api-key, orx-goog-api-key) and Go SDK usage (viaBifrostContextKeyDirectKey)x-bf-direct-keyto the security denylist so it cannot be forwarded to providers viax-bf-eh-*extra headersBifrostContextKeyDirectKeyto the Go SDK context keys reference and quickstart guide, including a warning that it bypasses governance, weighted selection, and key rotation/fallbackallow_direct_keysmust be enabled server-side and the caller must sendx-bf-direct-key: true; virtual keys in those headers are not treated as direct keysType of change
Affected areas
How to test
allow_direct_keysentry appears correctly in the client config and schema reference pages.request-options.mdxwith the cURL and Go SDK tabs.x-bf-direct-keyappears in the security denylist section.BifrostContextKeyDirectKeyappears in the Go SDK context keys table and quickstart guide.Breaking changes
Security considerations
allow_direct_keysis off by default and requires explicit opt-in by the server admin. When enabled, raw provider secrets are passed by callers and used directly — bypassing all of Bifrost's key governance, rate limiting, and rotation. Thex-bf-direct-keyheader is added to the security denylist to prevent it from being forwarded to upstream providers via the extra-headers mechanism. Operators should enable this only when callers are trusted to manage their own provider credentials.Checklist
docs/contributing/README.mdand followed the guidelinesSummary by CodeRabbit