Amazon Bedrock

Connect a Bedrock API key, its region, and an endpoint in your workspace's Settings → Providers, in its Provider keys section. Your application sends a Sentisec workspace key to Sentisec; Sentisec uses the stored Bedrock key to reach AWS. The supported connection uses bearer authentication, not an IAM access-key pair or SigV4.

From 0.8, choose the model's supported API and endpoint from the model catalog. Native Converse and ConverseStream are available alongside Messages, Chat Completions, and Responses.

What you need

• A Bedrock API key and the region associated with it.
• AWS account access and quota for the model you want to use.
• A Sentisec workspace API key and workspace id.

Setup

1. Open Settings → Providers. In Provider keys, choose Add Bedrock key on the Amazon Bedrock card.
2. Paste the API key, choose the Endpoint — see which endpoint to pick — then the Region, and click Save credential.
3. Use Test connection to check the saved connection. Model access and quota are separate from whether the key is accepted.
4. Issue a Sentisec key under Settings → API keys with Issue key.
5. Set your client's base URL and use that Sentisec key for authentication.

Which endpoint to pick

The form preselects Bedrock mantle (default). Pick by the model and API your application uses:

When you are unsure, pick Bedrock runtime: every model in the table below has a runtime combination, and only gpt-oss Responses needs mantle.

Regions

The workspace credential selects the upstream region. Runtime calls use bedrock-runtime.<region>.amazonaws.com; mantle calls use bedrock-mantle.<region>.api.aws. Include the selected host in your network allowlist when running Sentisec yourself. Converse always uses runtime, even when the saved compatibility endpoint is mantle.

The catalog's measured region is eu-west-1. Its verified_regions field describes measurement, not access permission or a promise that the same model is available in every region. AWS account access, model availability, and quotas still apply.

Testing the key

The credential card records the provider check. A successful check confirms that connection; it does not grant access to every model.

Model access

Use your AWS account's Bedrock model-access and quota settings to confirm the selected model is available. If AWS refuses a request, inspect its error before changing the key: access, quota, and request compatibility are distinct from credential validity.

Model ids and which endpoint serves them

GET /ws/{workspace_id}/v1/models returns Bedrock rows with a capabilities object. Read each lanes entry as one measured combination of endpoint, wire, and model_id; do not combine the separate endpoints and wires lists into unsupported pairs. Also read tools, streamed_tools, status, inference_profile, and verified_regions.

These rows support tools and streamed tools. The catalog also includes other models with narrower support: Nova, Mistral Large 2402, and Pixtral use native Converse only. Mistral Large 2402 and Pixtral support tools on non-streamed Converse, but reject streamed requests with tools. Models marked without tool support must be called without tool declarations. Chat Completions does not serve every Bedrock family.

From 0.8, a known-incompatible model/API/endpoint combination, or an unsupported tool mode, returns HTTP 400 with detail.error: bedrock_model_capability_mismatch before calling AWS. The response names the requested model, API, endpoint, region, and supported combinations. Known model aliases are translated to the catalog's endpoint-specific spelling. Unknown ids pass through the selected Bedrock API for AWS to validate; this is not a claim of measured support for them.

Vendor-prefixed and regional inference-profile ids select Bedrock when the workspace holds a Bedrock credential. For compatibility APIs, you can explicitly select it with X-Sentisec-Upstream-Provider: bedrock.

First call

With a runtime or mantle credential, send a Chat Completions request:

curl "https://api.sentisec.ch/ws/$SENTISEC_WORKSPACE_ID/v1/chat/completions" \
  -H "Authorization: Bearer $SENTISEC_API_KEY" -H "Content-Type: application/json" \
  -d '{"model":"mistral.ministral-3-14b-instruct","messages":[{"role":"user","content":"Hello"}]}'

The request appears under Requests, linked to its session.

SDKs

Use the base URLs above with your provider SDK. For Messages, use the full Haiku id in the table and set max_tokens. For Chat streaming, send stream: true and stream_options: {"include_usage": true} to request the provider's usage chunk. Without it, streamed request rows carry no token counts. Missing counts are not zero usage.

Native Converse and ConverseStream

Any client that speaks Bedrock's Converse API reaches Sentisec with two standard AWS settings. That includes the AWS SDKs with Bedrock API-key support and the Vercel AI SDK's Amazon Bedrock provider, which speaks Converse rather than an OpenAI-compatible API.

Both clients read these variables from the environment, so an application that already calls Bedrock with an API key needs no code change to route through Sentisec. Your Bedrock key stays in the workspace's Provider keys, and Sentisec uses it to reach AWS.

Converse always uses the runtime endpoint, even when the saved connection's endpoint is mantle. The workspace credential decides AWS's region; the region configured in your SDK does not override it.

Send one x-session-id per workflow run and reuse it for every request in that run, so the run's calls form one session. See sessions.

Vercel AI SDK

With the two variables set, create the provider as usual and pass the run id as a request header:

import { createAmazonBedrock } from "@ai-sdk/amazon-bedrock";
import { generateText } from "ai";

const bedrock = createAmazonBedrock({ region: "eu-west-1" });
const runId = `run-${crypto.randomUUID()}`; // one per workflow run

const { text } = await generateText({
  model: bedrock("mistral.ministral-3-14b-instruct"),
  prompt: "Hello",
  headers: { "x-session-id": runId },
});

streamText takes the same headers option. To configure the endpoint in code instead, pass baseURL and apiKey to createAmazonBedrock. A framework that takes an AI SDK model, such as Mastra, uses the provider you configured this way.

boto3

boto3 reads the same two variables. To set them in code:

import os, boto3
os.environ["AWS_BEARER_TOKEN_BEDROCK"] = os.environ["SENTISEC_API_KEY"]
client = boto3.client("bedrock-runtime", region_name="eu-west-1", endpoint_url="https://api.sentisec.ch/ws/<workspace_id>/v1")

Then call the ordinary SDK methods:

request = {"modelId": "eu.amazon.nova-lite-v1:0", "messages": [{"role": "user", "content": [{"text": "Hello"}]}]}
reply = client.converse(**request)
events = client.converse_stream(**request)["stream"]

boto3 has no per-call header option. Add the run id to each request with an event handler:

run_id = "run-2f9c41"  # one per workflow run
client.meta.events.register("before-sign.bedrock-runtime.*", lambda request, **_: request.headers.__setitem__("x-session-id", run_id))

Replace <workspace_id> with your workspace id. The SDKs call POST /ws/{workspace_id}/v1/model/{modelId}/converse or …/converse-stream. The native converse-stream route remains supported; it is separate from the retired Messages and Chat -stream routes.

A non-streamed reply carries the verdict in additionalModelResponseFields.sentisec.verdict. A streamed reply carries it in messageStop.additionalModelResponseFields.sentisec.verdict and has no X-Sentisec-Verdict header. ConverseStream uses AWS binary events, not SSE comments or [DONE].

A blocked tool call is withheld and explained in place. In a non-streamed reply, its toolUse block becomes a text block reading [Sentisec blocked tool_use: …]. In a stream, the call's frames are dropped and the same text arrives as a contentBlockDelta at the same index. Other calls in the turn that only read are released; a call that changes something is not sent when another call in the turn is held or refused (calls proposed together). stopReason stays tool_use while an allowed call remains and is end_turn otherwise, so it is always a standard Converse value and SDKs need no special handling. In shadow mode the call is released, and the verdict still reports what enforcing would have done.

Forwarding a field does not mean Sentisec inspects it. Keep any application checks required for those content types.

Compatibility adjustments

For Bedrock Responses requests, system instructions are carried as a system input message where needed, and json_schema output requests use JSON mode. JSON mode does not enforce your schema; validate the returned object in your application. The response's x-sentisec-upstream-normalized header identifies request adjustments.

From 0.8, Bedrock gpt-oss runtime Chat moves inline reasoning out of answer content into reasoning, and removes complete channel or format suffixes from tool names before evaluation. Other model output keeps its existing handling. Response adjustments discovered after streaming headers have been sent are recorded on the request; the header cannot enumerate changes discovered later. Original response capture follows the workspace's existing capture settings.

What you get

Supported tool calls are evaluated under your workspace's policy, with verdicts and request records available in the dashboard. Policy blocks apply in enforce mode. Invalid or incomplete tool-call attempts are withheld in either mode. For SSE verdicts and provider-specific endings, see streaming.

If something goes wrong

More

• Providers
• Keys management
• Chat endpoints
• Dashboard