Merged
Conversation
|
|
Contributor
📝 WalkthroughSummary by CodeRabbit
WalkthroughDocumentation changes add per-provider environment-variable support (allowing Changes
Sequence Diagram(s)sequenceDiagram
participant Client as Client
participant HTTPHook as HTTPTransportPreHook
participant Validator as VirtualKey/Router
participant Parser as BodyParser/Serializer
participant LB as LoadBalancer
participant MCP as MCPToolInjector
participant Backend as BackendService
Client->>HTTPHook: HTTP request (path contains "passthrough")
HTTPHook-->>Client: Bypass governance (early exit)
Client->>Backend: Request forwarded directly
%% Normal flow
Client->>HTTPHook: HTTP request (normal)
HTTPHook->>Validator: Validate keys & routing
Validator->>Parser: Parse/serialize body
Parser->>LB: Select upstream
LB->>MCP: Inject MCP tools
MCP->>Backend: Forward processed request
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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.11.4)level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies" Comment |
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Apr 26, 2026
Merged
Contributor
Confidence Score: 4/5Documentation changes are safe to merge; the Go change in main.go introduces an unconditional governance bypass that should be reviewed before merging. A single P1 finding in the Go code (unconditional passthrough bypass) caps the score at 4. The docs changes are clean and internally consistent. plugins/governance/main.go — the passthrough early-return needs scoping or intentional justification.
|
| Filename | Overview |
|---|---|
| plugins/governance/main.go | Adds a broad strings.Contains(req.Path, "passthrough") early-return in HTTPTransportPreHook that unconditionally skips virtual key validation, routing rules, and guardrails for any matching path. |
| docs/deployment-guides/config-json/guardrails.mdx | Replaces env-var-unsupported warnings with notes, adds Patronus AI provider tab, adds auth-mode examples for AWS Bedrock and Azure Content Safety, renumbers Gray Swan to id 5, and adds comprehensive env-var support reference tables. |
| docs/deployment-guides/helm/guardrails.mdx | Mirrors the config-json changes for the Helm values format, including Patronus AI tab, auth-mode snippets, env-var support tables, and provider ID renumbering. |
| docs/enterprise/user-provisioning.mdx | Adds SailPoint as a SCIM provider and adds per-provider env-var support tables for all SCIM providers (Okta, Entra ID, Keycloak, Zitadel, Google Workspace, SailPoint). |
Reviews (9): Last reviewed commit: "guardrails helm chart upgrade" | 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: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/deployment-guides/config-json/guardrails.mdx`:
- Around line 11-13: Update the Note block that currently shows the example
string "env.AWS_SECRET_KEY" to use the consistent AWS variable name
"env.AWS_SECRET_ACCESS_KEY" so it matches the Bedrock example; search for the
literal "env.AWS_SECRET_KEY" in the guardrails.mdx content and replace it with
"env.AWS_SECRET_ACCESS_KEY" to avoid copy/paste misconfiguration.
In `@docs/deployment-guides/helm/guardrails.mdx`:
- Around line 11-13: The Note uses env.AWS_SECRET_KEY but the Bedrock example
uses env.AWS_SECRET_ACCESS_KEY; update the Note so both examples use the same
canonical environment variable name (prefer env.AWS_SECRET_ACCESS_KEY) — replace
env.AWS_SECRET_KEY in the guardrail provider `config` block example with
env.AWS_SECRET_ACCESS_KEY to ensure consistency across the page.
In `@docs/enterprise/user-provisioning.mdx`:
- Line 88: The provider list string was updated to include "sailpoint" but the
UI/content for provider cards doesn't surface a SailPoint setup path; update the
user-provisioning page to either add a SailPoint provider card/link (matching
the other providers' card pattern) that points to setup/config docs for
SailPoint, or explicitly annotate the provider list to say "SailPoint
(config-only)" and add a short note under the provider cards explaining what
"config-only" means; look for the "provider": "okta | entra | zitadel | keycloak
| google | sailpoint" string and the provider cards section on the page to make
the change.
- Around line 115-216: The SCIM provider docs list unsupported providers and
fields that conflict with the schema; update docs to match the schema in
transports/config.schema.json by removing or refactoring all provider sections
except the supported "okta" and "entra" providers and remove references to
non-existent config objects and fields (e.g., okta_config, entra_config,
attributeRoleMappings, attributeTeamMappings, attributeBusinessUnitMappings)
that will be rejected by validation; keep only the exact fields and env.*
support semantics defined by the schema for provider values ["okta","entra"], or
note that other providers/attribute-mapping arrays are future work and will be
added in a follow-up PR.
🪄 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: dd40607a-125f-4756-9757-521e47a67aaf
📒 Files selected for processing (3)
docs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/enterprise/user-provisioning.mdx
akshaydeo
force-pushed
the
04-26-guardrails_helm_chart_upgrade
branch
from
cae1379 to
5ea9826
Compare
akshaydeo
force-pushed
the
04-26-env_var_updates
branch
from
e7a62e3 to
91a8e27
Compare
akshaydeo
force-pushed
the
04-26-guardrails_helm_chart_upgrade
branch
from
5ea9826 to
c28107b
Compare
akshaydeo
force-pushed
the
04-26-env_var_updates
branch
2 times, most recently
from
b55ebc8 to
a9dd3d6
Compare
akshaydeo
force-pushed
the
04-26-guardrails_helm_chart_upgrade
branch
from
c28107b to
42f1869
Compare
akshaydeo
force-pushed
the
04-26-guardrails_helm_chart_upgrade
branch
from
42f1869 to
5f6de6c
Compare
akshaydeo
force-pushed
the
04-26-env_var_updates
branch
from
a9dd3d6 to
4775cb0
Compare
akshaydeo
force-pushed
the
04-26-guardrails_helm_chart_upgrade
branch
from
5f6de6c to
1169c9d
Compare
akshaydeo
force-pushed
the
04-26-env_var_updates
branch
from
4775cb0 to
880f504
Compare
akshaydeo
force-pushed
the
04-26-env_var_updates
branch
from
880f504 to
fdcb08f
Compare
akshaydeo
force-pushed
the
04-26-guardrails_helm_chart_upgrade
branch
from
1169c9d to
39d8ac2
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 the current code and only fix it if needed.
Inline comments:
In `@docs/deployment-guides/helm/guardrails.mdx`:
- Around line 245-251: Update the Regex env-support matrix to include the
timeout field: add a new table row for `timeout` (or append `timeout` into the
existing Regex table) showing whether it is required (No), env.* supported
(Plain only) and a short Notes entry (e.g., timeout in seconds for pattern
evaluation; optional). Ensure this matches the examples that already use
`timeout` so the docs clearly state its env-support behavior and default/units.
🪄 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: 669c48ac-0931-417d-b6db-c1930b3ec8e4
📒 Files selected for processing (3)
docs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/enterprise/user-provisioning.mdx
✅ Files skipped from review due to trivial changes (1)
- docs/deployment-guides/config-json/guardrails.mdx
akshaydeo
force-pushed
the
04-26-guardrails_helm_chart_upgrade
branch
from
39d8ac2 to
f06aa56
Compare
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (4)
docs/deployment-guides/config-json/guardrails.mdx (2)
11-13: Resolve inconsistent AWS secret env var name in the note.The note on line 12 uses
"env.AWS_SECRET_KEY"as the example, but the AWS Bedrock provider (lines 74-75) uses"env.AWS_SECRET_ACCESS_KEY". AWS SDK standard convention usesAWS_SECRET_ACCESS_KEY. Consider updating the note to use the canonical name for consistency.🛠️ Suggested doc fix
-Credential and endpoint fields in guardrail provider `config` blocks support `"env.VAR_NAME"` strings (e.g. `"env.AWS_SECRET_KEY"`). Bifrost resolves the value from the process environment at startup. +Credential and endpoint fields in guardrail provider `config` blocks support `"env.VAR_NAME"` strings (e.g. `"env.AWS_SECRET_ACCESS_KEY"`). Bifrost resolves the value from the process environment at startup.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/config-json/guardrails.mdx` around lines 11 - 13, Update the Note block that currently shows the example credential string "env.AWS_SECRET_KEY" to use the canonical AWS variable name "env.AWS_SECRET_ACCESS_KEY" so it matches the AWS Bedrock provider example and common AWS SDK conventions; locate the Note element containing the example string (and the AWS Bedrock provider example strings "env.AWS_SECRET_ACCESS_KEY") and replace the shorter nonstandard name with the full "env.AWS_SECRET_ACCESS_KEY" for consistency.
294-300: Addtimeoutto the Regex env-support matrix.The Regex provider example includes
"timeout": 5, but the Regex env-support table (lines 294-300) doesn't list thetimeoutfield. Add it for consistency with other providers and so users can see the env-support behavior for all configurable fields.🛠️ Suggested doc fix
### Regex | Field | Required | env.\* supported | Notes | |-------|----------|-----------------|-------| | `patterns` | Yes | **Plain only** | Array of `{ pattern, description?, flags? }` objects | | `sampling_rate` | No | **Plain only** | `0`–`100`; percentage of requests to evaluate (default: `100`) | +| `timeout` | No | **Plain only** | Execution timeout in seconds |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/config-json/guardrails.mdx` around lines 294 - 300, The Regex env-support table is missing the `timeout` field shown in the Regex provider example; update the Regex table to include a `timeout` row indicating whether env.* is supported (e.g., Plain only or same as other fields) and a brief Notes entry (e.g., seconds, optional) so it matches the example that uses `"timeout": 5`; locate the Regex section and add the `timeout` entry next to `patterns` and `sampling_rate` in the table.docs/deployment-guides/helm/guardrails.mdx (1)
245-251: Addtimeoutto the Regex env-support matrix.The Regex provider example (lines 37-38) includes
timeout: 5, but the Regex env-support table in lines 245-251 doesn't list thetimeoutfield. Add it for completeness so users know the env-support behavior for all configurable fields.🛠️ Suggested doc fix
### Regex | Field | Required | env.\* supported | Notes | |-------|----------|-----------------|-------| | `patterns` | Yes | **Plain only** | Array of `{ pattern, description?, flags? }` objects | | `sampling_rate` | No | **Plain only** | `0`–`100`; percentage of requests to evaluate (default: `100`) | +| `timeout` | No | **Plain only** | Execution timeout in seconds |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/deployment-guides/helm/guardrails.mdx` around lines 245 - 251, Update the Regex env-support table to include the timeout field: add a row for `timeout` (mark as No for Required, **Plain only** for env.* supported) and include a short Notes entry such as `seconds; evaluation timeout (e.g., 5 in example)` so the table reflects the `timeout` shown in the Regex provider example.docs/enterprise/user-provisioning.mdx (1)
30-43: Consider adding a SailPoint provider card for discoverability.The provider list on line 88 includes
sailpoint, but the provider cards in lines 30-43 don't include a SailPoint option. While the previous review comment on this was marked as addressed, the cards still only show Okta, Microsoft Entra, Zitadel, and Google Workspace. Users looking for SailPoint setup documentation may not find it easily without a card linking to setup docs.🤖 Prompt for AI Agents
Verify each finding against the current code and determine if this is intentional or needs addressing. In `@docs/enterprise/user-provisioning.mdx` around lines 30 - 43, The provider card group lists Okta, Microsoft Entra, Zitadel, and Google Workspace, but does not include a card for SailPoint even though the provider list and env-support tables document it. Check if there's a separate SailPoint setup guide linked elsewhere, or if adding a SailPoint card would improve discoverability. If there's no setup guide, consider adding a note that SailPoint is config-only (schema file only, no separate setup guide) in the provider list section.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/enterprise/user-provisioning.mdx` around lines 30 - 43, The CardGroup in user-provisioning.mdx currently renders Card components for Okta, Microsoft Entra, Zitadel, and Google Workspace but omits SailPoint; add a new Card (same pattern as the others) with title "SailPoint", an appropriate icon (e.g., "sailpoint" or "cloud" if icon missing), and href pointing to the SailPoint setup doc (or to a new/internal note) so SailPoint is discoverable, or—if no setup guide exists—add a Card titled "SailPoint" whose body text clarifies "config-only (schema file only, no separate setup guide)" and links to the schema/config reference; update the CardGroup containing Card components to include this new Card and ensure the Card title matches the provider identifier `sailpoint`.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@docs/deployment-guides/config-json/guardrails.mdx`:
- Around line 11-13: Update the Note block that currently shows the example
credential string "env.AWS_SECRET_KEY" to use the canonical AWS variable name
"env.AWS_SECRET_ACCESS_KEY" so it matches the AWS Bedrock provider example and
common AWS SDK conventions; locate the Note element containing the example
string (and the AWS Bedrock provider example strings
"env.AWS_SECRET_ACCESS_KEY") and replace the shorter nonstandard name with the
full "env.AWS_SECRET_ACCESS_KEY" for consistency.
- Around line 294-300: The Regex env-support table is missing the `timeout`
field shown in the Regex provider example; update the Regex table to include a
`timeout` row indicating whether env.* is supported (e.g., Plain only or same as
other fields) and a brief Notes entry (e.g., seconds, optional) so it matches
the example that uses `"timeout": 5`; locate the Regex section and add the
`timeout` entry next to `patterns` and `sampling_rate` in the table.
In `@docs/deployment-guides/helm/guardrails.mdx`:
- Around line 245-251: Update the Regex env-support table to include the timeout
field: add a row for `timeout` (mark as No for Required, **Plain only** for
env.* supported) and include a short Notes entry such as `seconds; evaluation
timeout (e.g., 5 in example)` so the table reflects the `timeout` shown in the
Regex provider example.
In `@docs/enterprise/user-provisioning.mdx`:
- Around line 30-43: The CardGroup in user-provisioning.mdx currently renders
Card components for Okta, Microsoft Entra, Zitadel, and Google Workspace but
omits SailPoint; add a new Card (same pattern as the others) with title
"SailPoint", an appropriate icon (e.g., "sailpoint" or "cloud" if icon missing),
and href pointing to the SailPoint setup doc (or to a new/internal note) so
SailPoint is discoverable, or—if no setup guide exists—add a Card titled
"SailPoint" whose body text clarifies "config-only (schema file only, no
separate setup guide)" and links to the schema/config reference; update the
CardGroup containing Card components to include this new Card and ensure the
Card title matches the provider identifier `sailpoint`.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 3bac0d12-4b16-4cff-9f71-482ee79fd97b
📒 Files selected for processing (4)
docs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/enterprise/user-provisioning.mdxplugins/governance/main.go
✅ Files skipped from review due to trivial changes (1)
- plugins/governance/main.go
Contributor
Author
Merge activity
|
akshaydeo
changed the base branch from
04-26-env_var_updates
to
graphite-base/3062
akshaydeo
dismissed
coderabbitai[bot]’s stale review
The base branch was changed.
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
2 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
Updates the guardrails and user-provisioning documentation to reflect that
env.*references are now supported in guardrail providerconfigblocks and most SCIM provider config fields. Removes the previous warnings stating env vars were unsupported, replaces hardcoded credential placeholders withenv.*examples, and adds comprehensive per-provider field reference tables documenting which fields support env var resolution and which require plain values.Changes
<Warning>blocks statingenv.*was unsupported with<Note>blocks explaining the new env var resolution behavior for guardrail provider config fieldsenv.*strings instead of hardcoded placeholder credentialsauth_typefield documentation and examples for AWS Bedrock (keys,api_key,iam_role) and Azure Content Safety (api_key,default_credential,entra_id), including separate config snippets for each auth modepatronus-ai) with its own tab, example config, and field referencesampling_rateto all provider config examples; removed the now-unusedmode: "block"field from Regex examplesbase_urlto the Gray Swan provider configconfig.jsonand Helm guardrails docs with per-provider tables distinguishingenv.*-supported fields from plain-only fieldsenv.*support)provider_config_idsreferences in rule examples to reflect the new provider ID numbering (Gray Swan moved from4to5after Patronus AI was inserted)Type of change
Affected areas
How to test
Review the rendered documentation pages for:
docs/deployment-guides/config-json/guardrails.mdxdocs/deployment-guides/helm/guardrails.mdxdocs/enterprise/user-provisioning.mdxVerify that:
env.*strings rather than hardcoded placeholder valuesBreaking changes
Related issues
Security considerations
All credential fields in example configurations now use
env.*references rather than hardcoded placeholder strings, reducing the risk of users copying examples with literal secrets into production configs. The documentation explicitly distinguishes which fields support env var resolution to prevent misconfiguration.Checklist
docs/contributing/README.mdand followed the guidelines