[Automated] Draft docs (agentgateway): bedrock mantle: validate guardrail support

[github-actions]

agentgateway/agentgateway#3507 — bedrock mantle: validate guardrail support

Docs versions: standalone/main, kubernetes/main

What changes for users: Inline Bedrock guardrails now require the Runtime endpoint. Kubernetes configuration that combines guardrail with MantlePreferred or MantleOnly fails validation, and RuntimePreferred stays on Runtime when guardrail is set.

What the docs now say: The standalone and Kubernetes Amazon Bedrock provider pages now explain that inline Bedrock guardrails force Runtime, that the Mantle-preferred and Mantle-only endpoint preferences cannot be used with inline guardrails, and that prompt guardrails with bedrockGuardrails are separate.

Not verified: No cluster; the steps are unrun.

How agentgateway-3507 was drafted, and what was not verified

• Code PR: bedrock mantle: validate guardrail support agentgateway#3507
• Code issue: none linked
• Product: agentgateway (upstream) → agentgateway/website
• Docs version: standalone/main and kubernetes/main; documented in the development tree, which is where unreleased changes go.
• Category: scoped-edit / pr

Plan, and what changed it

• Planned: Add the Bedrock inline guardrail limitation beside the existing Bedrock Mantle endpoint preference tables.
• Learned: The dossier diff and target pages showed the specific Bedrock provider pages already own the endpoint preference behavior; UI and configuration index candidates were unrelated.
• Did: Updated the standalone Bedrock provider page and the shared Kubernetes Bedrock provider asset, and wrote a proposed release note.

Why a documentation change is necessary

The pull request adds validation that rejects guardrail with MantlePreferred or MantleOnly, and runtime behavior that keeps RuntimePreferred requests on Runtime when inline guardrails are set. The Bedrock Mantle sections already document endpoint preferences, but they did not state the new inline guardrail constraint or distinguish inline guardrails from prompt guardrails. A reader could otherwise combine guardrails with a Mantle mode that now fails validation.

What changed on disk

• assets/agw-docs/pages/agentgateway/llm/providers/bedrock.md: Updated the Kubernetes Bedrock Mantle table and added the inline guardrail Runtime constraint inside the existing unreleased version gate.
• content/docs/standalone/main/integrations/llm/providers/bedrock.md: Updated the standalone Bedrock Mantle table and linked readers to prompt guardrails for endpoint-independent Bedrock Guardrails.

How to verify this change

1. In a cluster with the main-branch agentgateway CRDs installed, confirm that a Kubernetes Bedrock backend rejects an inline guardrail with a Mantle preference.

   kubectl apply --dry-run=server -f- <<'EOF'
   apiVersion: agentgateway.dev/v1alpha1
   kind: AgentgatewayBackend
   metadata:
     name: bedrock-mantle-guardrail
   spec:
     ai:
       provider:
         bedrock:
           endpointPreference: MantlePreferred
           guardrail:
             identifier: test-guardrail
             version: "1"
   EOF

   The API server reports Bedrock guardrails cannot be used with MantlePreferred or MantleOnly.

2. Confirm that RuntimePreferred with the same inline guardrail passes schema validation.

   kubectl apply --dry-run=server -f- <<'EOF'
   apiVersion: agentgateway.dev/v1alpha1
   kind: AgentgatewayBackend
   metadata:
     name: bedrock-runtime-guardrail
   spec:
     ai:
       provider:
         bedrock:
           endpointPreference: RuntimePreferred
           guardrail:
             identifier: test-guardrail
             version: "1"
   EOF

   The server-side dry run succeeds.

3. For standalone mode, validate a Bedrock model configuration that combines inline Bedrock guardrail settings with the Mantle-preferred endpoint preference.

   agentgateway -f config.yaml --validate-only

   The validation output reports Bedrock guardrails cannot be used with MantlePreferred or MantleOnly.

What was not verified

The configuration was not applied to a cluster. The standalone inline guardrail field spelling was not in the dossier, so the standalone page does not add a runnable inline-guardrail YAML example.

How the pages were chosen (triage report)

Feature clusters

These pull requests document one feature between them:

Cluster	Pull requests	Product	Why grouped
c4	agentgateway/agentgateway#3507, agentgateway/agentgateway#3570, agentgateway/agentgateway#3582, agentgateway/agentgateway#3600, agentgateway/agentgateway#3620, agentgateway/agentgateway#3645, agentgateway/agentgateway#3671, agentgateway/agentgateway#3672, agentgateway/agentgateway#3685	agentgateway	both are drafted into content/docs/standalone/main/documentation/llm/playground.md, the only page a code-path rule names for one of them, so separate pull requests would conflict

Kept apart on purpose. Merging wrongly produces a guide that documents two things and explains neither, so these are reported for a person to merge rather than grouped automatically:

• ui: show models from the config dump in XDS mode agentgateway#3570 and config: replace YAML processing library agentgateway#3639 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• fix(ui): remove non-null assertions agentgateway#3582 and config: replace YAML processing library agentgateway#3639 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• Bump deps for UI agentgateway#3600 and config: replace YAML processing library agentgateway#3639 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• ui: when an API key is provisioned, stamp the request identity into it agentgateway#3620 and config: replace YAML processing library agentgateway#3639 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• config: replace YAML processing library agentgateway#3639 and ui: better embedded catalog support agentgateway#3645 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• config: replace YAML processing library agentgateway#3639 and ui: support and default to hashed keys agentgateway#3671 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• config: replace YAML processing library agentgateway#3639 and Misc UI cleanup agentgateway#3672 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• config: replace YAML processing library agentgateway#3639 and ui: misc minor cleanup agentgateway#3685 both have content/docs/standalone/main/documentation/llm/playground.md as a candidate, but for one of them it is one page among more than 3, so they are kept apart; merge them if both drafts do land there
• (1 more weaker link(s) not shown; the work-list JSON is complete)

Draft a documentation change

agentgateway/agentgateway#3507 — bedrock mantle: validate guardrail support

• Product: agentgateway (upstream) → agentgateway/website
• Docs version: standalone/main, kubernetes/main
• Summary (read from the body): These are unsupported with mantle (note you can use standalone)
• Not tested: no cluster was available, so every command in this diff is unrun

Draft branch: pr-tracker-draft-agentgateway-3507

---

Important

The test suite has not run on this pull request. It was opened by github-actions[bot], and GitHub does not start workflows for pull requests opened with the repository's own token. Doc tests, link checking and the static checks are held as action_required until somebody presses Approve and run on the Checks tab. Cloudflare Pages and DCO are GitHub Apps rather than Actions, so those two do run on their own.

Please approve the checks before reviewing the content: an absence of failures here means the tests have not run, not that they passed.

[cloudflare-workers-and-pages]

Deploying agentproxy with    Cloudflare Pages

Latest commit:	16aae7c
Status:	⚡️  Build in progress...

View logs