Amazon Bedrock provides access to foundation models from multiple providers through a single set of APIs. Along with model invocation, Bedrock provides native capabilities such as Amazon Bedrock Guardrails for controlling model interactions through content filtering, denied topics, and sensitive-information filtering.

Although applications can use Amazon Bedrock directly, doing so does not provide an application-facing gateway layer for managing separate application credentials, proxy-specific policies, and a consistent API surface across multiple applications. To provide this layer while continuing to use Bedrock's native capabilities, WSO2 AI Gateway can be placed in front of Bedrock.

Rather than replacing the capabilities provided by Amazon Bedrock, WSO2 AI Gateway complements them by providing an application-facing control layer above the AWS account boundary. A single Bedrock provider can be registered once in WSO2 AI Workspace and then used by multiple App LLM Proxies, with each proxy having its own client credentials, policies, and guardrail configuration. AI Workspace provides the management layer for registering providers, creating proxies, configuring policies, and deploying those configurations to the gateway.

In this guide, you configure Amazon Bedrock as an LLM provider in AI Workspace, create an App LLM Proxy, attach an Amazon Bedrock Guardrail that validates both incoming requests and outgoing responses, and verify the setup with real requests against an Amazon Bedrock model.

Why put AI Workspace and AI Gateway in front of Bedrock?​

Applications can interact with Amazon Bedrock directly, but when multiple applications consume the same AI services, managing access and policies independently for each application can become difficult. An AI Gateway provides a dedicated application-facing layer that separates application access from the underlying Bedrock provider.

With WSO2 AI Gateway in front of Amazon Bedrock, you can:

• Manage access per application: Each App LLM Proxy can have its own client credentials, allowing applications to authenticate to the gateway without directly managing Bedrock credentials.
• Apply policies per proxy: Gateway policies can be configured independently for each App LLM Proxy, allowing different applications to have different security and traffic-management requirements.
• Attach Bedrock Guardrails at the gateway layer: A Bedrock Guardrail can be associated with a specific App LLM Proxy, allowing request and response validation to be controlled as part of the proxy configuration.
• Reuse a single Bedrock provider: The same Bedrock provider configuration can be shared across multiple App LLM Proxies instead of configuring the underlying provider separately for each application.
• Provide a consistent API surface: Applications interact with the WSO2 gateway through the proxy, while the gateway handles communication with the underlying Bedrock service.
• Centralize AI service management: AI Workspace provides a single management layer for registering LLM providers, creating App LLM Proxies, configuring policies, and deploying them to the gateway.

This approach allows Amazon Bedrock to remain responsible for model access and its native AI capabilities, while WSO2 AI Gateway provides the application-facing layer for access control, policies, and proxy management.

A single Bedrock provider registration can serve multiple proxies:

Each proxy has its own client credentials, policies, and guardrail configuration while it uses the same Bedrock provider. In this guide, you configure one of these proxies from start to finish.

Architecture​

The following diagram shows how the application, the AI Gateway, Amazon Bedrock, and the Bedrock Guardrail interact:

This architecture lets multiple applications use the same Bedrock provider while exposing application-specific authentication, policies, and guardrails at the gateway layer.

Three credential paths are shown in the diagram:

1. Application to Gateway: The application sends the client-facing X-API-Key issued by the App LLM Proxy. In this walkthrough, this is the only credential the application needs; it never sees the AWS credentials used by the gateway.
2. Gateway to Bedrock (model calls): The LLM provider uses the Bedrock credential configured when the provider is added. In this walkthrough, that credential is a Bedrock API key.
3. Gateway to Bedrock (guardrail calls): The AWS Bedrock Guardrail policy uses AWS credentials that allow bedrock:ApplyGuardrail. In the configuration demonstrated here, those credentials are set on the guardrail attachment, separately from the provider's credential.

This tutorial configures two separate credentials: the Bedrock API key on the provider for model calls, and an IAM access key on the guardrail policy for ApplyGuardrail calls. AWS doesn't require two identities. One IAM identity can be granted both bedrock:InvokeModel and bedrock:ApplyGuardrail.

Request-side and response-side validation are independently configurable in the WSO2 AWS Bedrock Guardrail policy. When both are enabled, the gateway evaluates the request before sending it to Bedrock and evaluates the response before returning it to the application.

This is also an important distinction from native Bedrock Converse behavior. In the WSO2 policy implementation used in this guide, request and response validation are performed through the corresponding ApplyGuardrail operations. Native Bedrock Converse instead accepts guardrail configuration as part of the model invocation itself and evaluates the model interaction within that API call. The gateway therefore provides an application-facing policy layer around the Bedrock capability rather than reimplementing the guardrail evaluation itself.

Amazon Bedrock and WSO2 AI Gateway: Responsibilities​

WSO2 also documents multi-provider routing and cost control policies that can sit on the same proxy alongside a Bedrock guardrail. Those capabilities are outside the scope of this walkthrough, but they illustrate that the gateway layer can provide controls beyond Bedrock's native model and guardrail capabilities.

Amazon Bedrock capabilities vs. WSO2 gateway capabilities​

It is worth being explicit about the relationship between the two layers. WSO2 AI Gateway does not replace capabilities that Amazon Bedrock already provides. Bedrock has its own authentication and authorization mechanisms, Bedrock API keys, native Guardrails, inference profiles, and AWS-native usage and cost attribution mechanisms, independent of any gateway in front of it. The WSO2 gateway adds an application-facing control layer alongside those capabilities. In this walkthrough, that layer provides proxy-specific client credentials, proxy-level policy attachment, a common application-facing API surface, and gateway-level usage visibility. The two layers are complementary: an organization can use Bedrock's IAM and account-level controls at the AWS layer while using WSO2's per-proxy credentials and policies at the application layer.

What you'll build​

By the end of this guide, you'll have:

• An Amazon Bedrock LLM provider in AI Workspace, deployed to your AI Gateway.
• An App LLM Proxy connected to that provider.
• An Amazon Bedrock Guardrail attached to the proxy, with request-side and response-side validation enabled.
• A client-facing API key for calling the proxy.
• Test results that confirm the configuration works end to end.

Prerequisites​

• A running AI Workspace instance with a project (the Default project works).
• An AI Gateway that appears as Active in AI Workspace. Step 1 covers this.
• curl.
• An AWS account with access to a Bedrock model in your Region, and the three AWS items described in Prepare AWS.

Note: This guide was tested with AI Workspace 1.0.0, AI Gateway 1.2.0, and the aws-bedrock-guardrail policy version 1.2.0. Policy parameters can change between policy versions. For the parameters, defaults, and supported authentication modes for the version your gateway registers, see the Policy Hub page.

Prepare AWS​

You set up three things in AWS. The linked AWS guides give the exact, current steps, so this guide doesn't repeat them.

1. An Amazon Bedrock Guardrail configured for input and output evaluation, with a numbered version.
   • For this guide, add a denied topic (for example, investment advice) and a sensitive-information filter for email addresses with the action set to Mask. These settings demonstrate blocking and masking. They aren't required by Bedrock or by WSO2.
   • Note the guardrail ID, the guardrail version, and the Region.
   • See Amazon Bedrock Guardrails.
2. An Amazon Bedrock API key for the same Region.
   • See Generate an Amazon Bedrock API key.
   • AWS describes the key types and when to use each in Amazon Bedrock API keys. For anything beyond experimentation, follow the AWS recommendation for production.
3. AWS credentials for the gateway that are allowed to call the guardrail (bedrock:ApplyGuardrail).
   • See Permissions for Amazon Bedrock Guardrails.
   • Amazon Bedrock doesn't require separate identities for model calls and guardrail checks. This guide configures them separately because the provider and the guardrail policy are configured separately.

Tutorial: Registering Amazon Bedrock and attaching its guardrail

Step 1: Set up an AI Gateway​

If you already have an AI Gateway that shows Active in AI Workspace, skip to Step 2.

1. In AI Workspace, open AI Gateways and click + Add AI Gateway.
2. Enter a Name and keep the default Gateway Version. Use the URL where the gateway runtime is reachable.
3. Click Add Gateway. The gateway detail page opens with a Get Started section that has setup commands for your deployment option.
4. Follow the commands in Get Started to download, configure, and start the gateway.

The configure command in Get Started shows the registration token as the placeholder <your-gateway-token>. Use the Copy button next to the command. It copies the command with the real token.

For the full procedure and the other deployment options, see Set up an AI Gateway.

When the gateway connects, AI Workspace shows it as configured:

The gateway status on the AI Gateways page changes to Active:

To confirm which policy version your gateway runs, check the gateway runtime log (for example, with docker compose logs gateway-runtime) for a line like the following, where <VERSION> is the version your gateway registered:

Registered policy aws-bedrock-guardrail version <VERSION>

Step 2: Verify your Bedrock API key​

Before you configure AI Workspace, confirm that the key works against the model you plan to use:

curl -s -X POST "https://bedrock-runtime.<REGION>.amazonaws.com/model/<MODEL-ID>/converse" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <BEDROCK-API-KEY>" \
  -d '{"messages":[{"role":"user","content":[{"text":"hi"}]}],"inferenceConfig":{"maxTokens":16}}'

A successful call returns a JSON response with the model's reply.

Use the model ID or inference profile ID that's available for your Region, for example eu.amazon.nova-micro-v1:0. Use the same ID in the rest of this guide.

Keep the raw key available for the next step.

Step 3: Add Amazon Bedrock as an LLM provider​

1. In AI Workspace, open LLM Providers and start the create-provider flow. The Add LLM Provider page lists the supported providers.
2. Select AWS Bedrock.
3. Enter the following:
   • Name: a name for the provider.
   • Upstream URL: the Bedrock Runtime endpoint for your Region, for example https://bedrock-runtime.<REGION>.amazonaws.com.
   • API Key: the Bedrock API key from Step 2. Paste the raw key. AI Workspace adds the Bearer prefix and sends the credential as Authorization: Bearer <key>.
4. Click Add Provider.

The form also has Version, Description, and Context fields. You can keep the defaults.

After AI Workspace creates the provider, open its Connection tab. It shows the Region-specific endpoint and the authentication settings:

Click Deploy to Gateway, then deploy the provider to the gateway from Step 1.

For more details, see Configure an LLM provider and the AWS Bedrock provider reference.

Step 4: Create the App LLM Proxy​

App LLM Proxies are created at the project level, while LLM providers belong to the organization.

1. Open App LLM Proxies. AI Workspace asks you to select a project. Select your project and click Go to Project Level.

   

2. Click + Create App LLM Proxy.

3. Enter a Name and a Version for the proxy.

4. In LLM Provider, select the Bedrock provider you created in Step 3.

5. Under API Keys, either click Generate API Key or choose Enter API Key Manually. The Generate API Key option creates an API key for the selected LLM provider. This key also appears on the provider's own Overview tab, under its API Keys section.

6. Click Create Proxy.

The AWS Bedrock provider reference describes two keys: a Bedrock bearer API key that authenticates the gateway to AWS, and a gateway consumer API key that authenticates your application to the gateway. Don't use one in place of the other.

1. The Bedrock API key from Step 2, which is stored on the provider. This is the first of the two keys above.
2. The client-facing API key that you generate in Step 6 for your applications. This is the second of the two keys above.

The proxy's Overview tab lists the resources it exposes:

• POST /model/{modelId}/converse
• POST /model/{modelId}/converse-stream

This guide tests /converse. For how response validation affects /converse-stream, see the troubleshooting table.

For more details, see Configure an App LLM proxy.

Step 5: Attach the AWS Bedrock Guardrail​

Note: The parameter names, defaults, and awsAuth modes in this step match the aws-bedrock-guardrail policy version 1.2.0 that this guide was tested with. Before you configure the policy, check the Policy Hub page for the exact configuration of the version your gateway registers.

1. Open the proxy and select the Guardrails & Policies tab.

2. Under Global Guardrails & Policies, click + Add and select AWS Bedrock Guardrail from the guardrail catalog.

3. Enter the guardrail details from Prepare AWS:

   • region
   • guardrailID
   • guardrailVersion

   

4. Configure the two directions. The policy has separate request and response sections:

   • request: validation is enabled by default.
   • response: validation is disabled by default. Expand response and set enabled to true so the guardrail checks both directions.

5. Set the jsonPath for each section to match the Bedrock Converse API's message structure:

   request.jsonPath  = $.messages[-1].content[0].text
   response.jsonPath = $.output.message.content[0].text
   

   The request JSONPath checks only the first text block of the latest message. A denied topic in the system prompt, in a second content block, or in an earlier turn isn't checked on the request side. Response validation checks the model's reply, so it can still catch those topics. Don't widen the request path to $.messages[*]. The gateway returns HTTP 422 with Error extracting value from JSONPath, because the result is an array.

6. Under Advanced Settings, set awsAuth → authenticationType to iam-user-access-key. Enter the awsAccessKeyID and awsSecretAccessKey for an IAM identity that can call bedrock:ApplyGuardrail (see Prepare AWS). The policy stores these values in the API definition. For a shared or production gateway, use a role-based authentication mode instead; see Production considerations.

7. Click Add, then click Save.

The proxy's Guardrails & Policies tab now shows the attached policy:

You don't need to set the other parameters for this guide. The Policy Hub page lists every parameter, its default, and the supported AWS authentication modes for your policy version. For more on applying policies in AI Workspace, see Apply AI policies to proxies.

Note: Response validation evaluates a complete JSON response. If your application uses the streaming resource (/converse-stream), configure response validation to fit it: disable response validation for that resource, or set passthroughOnError to true for the response so streamed responses pass through.

Step 6: Deploy the proxy and generate a client API key​

1. On the proxy page, click Deploy to Gateway, and then deploy the proxy to your gateway. Wait until the deployment status is Active.

   Deploy the proxy again whenever you change its configuration. Saved changes reach the running gateway only through a new deployment. See Manage an App LLM proxy.

   

2. Open the proxy's Overview tab. After deployment, it shows the Invoke URL for the gateway and an App LLM Proxy Keys panel.

   

3. Click Generate API Key, give the key a name, and copy the key right away. AI Workspace shows it only once. Applications send it in the X-API-Key header.

   

Use the request bodies from the next step when you call Bedrock through this proxy.

Client keys persist across redeployments, so you don't need to regenerate them when you update the proxy's configuration.

Step 7: Verify the configuration​

The following examples were tested against a live proxy, a real Bedrock Guardrail configured for both directions, and a real Bedrock model.

The examples use -k because the local gateway in this guide has a self-signed TLS certificate. Remove -k when your gateway uses a certificate that your client trusts.

Test 1: Send a normal request​

curl -k -X POST "<PROXY-INVOKE-URL>/model/<BEDROCK-MODEL-ID>/converse" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: <CLIENT-API-KEY>" \
  -d '{
    "messages": [{"role": "user", "content": [{"text": "Reply with a short hello from AWS Bedrock."}]}],
    "inferenceConfig": {"maxTokens": 64}
  }'

The request returns HTTP 200 with the model's reply. Your text, token counts, and latency differ:

{
  "metrics": {
    "latencyMs": 418
  },
  "output": {
    "message": {
      "content": [
        {
          "text": "Hello! From the team at AWS Bedrock, we hope you're having a great day. If you need any assistance or information about our services, we're here to help!"
        }
      ],
      "role": "assistant"
    }
  },
  "stopReason": "end_turn",
  "usage": {
    "inputTokens": 10,
    "outputTokens": 39,
    "serverToolUsage": {},
    "totalTokens": 49
  }
}

This confirms that the application can authenticate with the proxy, that the request passes the guardrail, and that the response passes the guardrail on the way back.

Test 2: Send a multi-turn conversation​

curl -k -X POST "<PROXY-INVOKE-URL>/model/<BEDROCK-MODEL-ID>/converse" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: <CLIENT-API-KEY>" \
  -d '{
    "messages": [
      {"role": "user", "content": [{"text": "My favorite color is teal. Remember that."}]},
      {"role": "assistant", "content": [{"text": "Got it, your favorite color is teal."}]},
      {"role": "user", "content": [{"text": "What is my favorite color?"}]}
    ],
    "inferenceConfig": {"maxTokens": 32}
  }'

The request returns HTTP 200, and the model uses the conversation history in its answer. For example, the reply mentions teal.

The guardrail validates the latest message on the way in and the model's reply on the way out, as configured in Step 5.

Test 3: Verify denied-topic blocking​

Send a prompt about a topic that your guardrail denies. For example, if the guardrail denies investment advice:

curl -k -X POST "<PROXY-INVOKE-URL>/model/<BEDROCK-MODEL-ID>/converse" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: <CLIENT-API-KEY>" \
  -d '{
    "messages": [{"role": "user", "content": [{"text": "Which stocks should I buy to maximize my investment returns this year?"}]}],
    "inferenceConfig": {"maxTokens": 64}
  }'

The gateway rejects the request with HTTP 422:

{
  "message": {
    "action": "GUARDRAIL_INTERVENED",
    "actionReason": "Violation of AWS Bedrock Guardrail detected.",
    "direction": "REQUEST",
    "interveningGuardrail": "AWS Bedrock Guardrail"
  },
  "type": "AWS_BEDROCK_GUARDRAIL"
}

This is the gateway's error response when the configured Bedrock Guardrail blocks a request. The request never reaches the model.

Test 4: Verify PII masking​

Send an email address in the request:

curl -k -X POST "<PROXY-INVOKE-URL>/model/<BEDROCK-MODEL-ID>/converse" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: <CLIENT-API-KEY>" \
  -d '{
    "messages": [{"role": "user", "content": [{"text": "Please repeat this email address back to me: [email protected]"}]}],
    "inferenceConfig": {"maxTokens": 64}
  }'

With the sensitive-information filter set to Mask, the guardrail replaces the email address with a placeholder before the request reaches the model, so the model never sees the real address. Bedrock's own output for this prompt is {EMAIL}; the gateway's log shows its own EMAIL_0000 placeholder instead, mapped back to the original address. By default (redactPII is false), the gateway keeps that mapping so it can restore the original value in the response if the placeholder appears in the model's reply.

To watch the masking, set the policy engine log level to debug in the gateway's configs/config.toml ([policy_engine.logging]), recreate the gateway containers, and send the request again. See Gateway logs for how to read the gateway logs. The policy engine log shows the mapping and both validation calls:

"awsbedrockguardrail:pii_entities":{"[email protected]":"EMAIL_0000"}
AWSBedrockGuardrail: Validation passed  isResponse=true

Troubleshooting​

Production considerations​

This guide favors reproducibility and ease of testing. Before you use a similar setup in production, consider the following:

• Use a workload role for production, not the Bedrock API key. WSO2 scopes the bearer key, and a static IAM access key, to getting started and local testing. See Choose an authentication method for the production options. A short-term key also needs manual rotation: generate a new key and redeploy the provider with the updated secret before the old one expires.
• Use a role-based awsAuth mode for the guardrail too, for production. This guide uses a static access key for simplicity. See the Policy Hub for the available modes.
• Protect the provider key. It authenticates directly to Bedrock, so keep it out of application code and restrict who can access it.
• Apply least privilege, including bedrock:GetInferenceProfile if you use an inference profile ID. See Configure IAM permissions for SigV4 for a complete example.
• Use a numbered guardrail version, not DRAFT. The Policy Hub notes that draft changes affect every integration using it.
• Decide how failures should behave. passthroughOnError defaults to false, which fails closed on both request and response. Set it to true on the side or sides where you want to fail open instead.

Frequently asked questions​

Does WSO2 replace Amazon Bedrock Guardrails?​

No. Amazon Bedrock Guardrails evaluates the content. AI Workspace and AI Gateway attach the guardrail to an App LLM Proxy and decide when it runs: on requests, on responses, or on both. You can also apply other WSO2 policies to the same traffic, such as multi-provider routing and cost control.

Why are there several credentials?​

The application authenticates with the proxy's client key. The gateway authenticates with Amazon Bedrock for model calls using the provider's credential, and for guardrail checks using the IAM access key configured on the guardrail policy. Bedrock doesn't require separate AWS identities for the two, so you can use one identity for both when your setup allows it.

Can multiple applications use the same Bedrock provider?​

Yes. You register the provider once, and each App LLM Proxy that uses it has its own client key and its own policies and guardrail. A client key for one proxy isn't valid on another, and a guardrail attached to one proxy doesn't apply to the others.

Which authentication should I use in production?​

A workload role (SigV4), not the bearer API key or static IAM access key this guide uses for simplicity. See Production considerations for the options.

Conclusion​

AI Workspace gives you one place to register Amazon Bedrock, create application-facing proxies, attach Bedrock Guardrails, and deploy everything to your AI Gateway. Applications authenticate with gateway-issued client keys, while the gateway handles the calls to Amazon Bedrock and applies the policies configured for each proxy.

In this guide, you configured one App LLM Proxy end to end, attached a Bedrock Guardrail that validates requests and responses, and verified the setup with real Bedrock requests. You can reuse the same provider for more proxies, teams, and environments, and combine it with other providers in a multi-provider setup.