> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Amazon Bedrock

> What AWS Bedrock Guardrails is and how to connect one to MCP Manager as a custom rule engine: the guardrail policy types, the model-agnostic ApplyGuardrail API integration, the ARN/version/Authorization setup, and the tier, pricing, and logging details to plan for.

The **AWS Bedrock Guardrails** template connects an Amazon Bedrock guardrail as a [custom rule engine](/features/gateway-rules/custom-rules-engines) in MCP Manager. You create and tune the guardrail in AWS; MCP Manager calls Bedrock's `ApplyGuardrail` API on your behalf and translates the result into a pass / modify / block verdict on the tool message. Add it from **Rule Engines** → **Add** → **AWS Bedrock Guardrails**.

<Note>
  This page summarizes Bedrock Guardrails to help you decide how to configure one for MCP Manager. AWS owns the feature and changes it often — treat the [AWS Bedrock Guardrails documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html) and the [AWS Bedrock pricing page](https://aws.amazon.com/bedrock/pricing/) as the authoritative source for the current policy types, limits, tiers, and prices.
</Note>

## What Bedrock Guardrails is

Amazon Bedrock Guardrails is a **managed safety layer** that evaluates content against policies you define — on both the way in (prompts) and the way out (model responses). Its defining property for governance is that it enforces **deterministic controls that don't depend on a model cooperating**: unlike instructions embedded in a prompt, a guardrail's decision doesn't rely on the model's reasoning quality. (AWS publishes its own efficacy figures for how much harmful content guardrails catch; see the AWS product page for the current numbers and methodology.)

### Why MCP Manager uses the ApplyGuardrail API

Bedrock's **`ApplyGuardrail` API evaluates content against a guardrail without invoking any foundation model** — standalone content moderation, decoupled from inference. That decoupling is what makes a guardrail a fit for a gateway: MCP Manager sends the **tool message text** from your MCP traffic to `ApplyGuardrail`, the guardrail applies its configured policies, and MCP Manager acts on the verdict. Two consequences are worth knowing:

* **It's model-agnostic.** Because the guardrail evaluates text rather than running a model, the same guardrail you use elsewhere in Bedrock works here against MCP tool traffic — independent of which model your client ultimately talks to.
* **It complements model-side guardrails rather than replacing them.** A guardrail attached to a model call protects that call; applying a guardrail at the MCP gateway protects the data flowing through your [connections](/features/viewing-logs). You can run both.

## The policies a guardrail can enforce

AWS groups guardrail safeguards into several configurable policy types. You enable only the ones you want, and a guardrail must contain at least one policy plus the blocked-prompt and blocked-response messaging. The current set, per AWS:

<AccordionGroup>
  <Accordion title="Content filters">
    Detect and filter harmful text (and image) content across predefined categories such as Hate, Insults, Sexual, Violence, Misconduct, and Prompt Attack, with adjustable strength per category.
  </Accordion>

  <Accordion title="Denied topics">
    Define topics that are off-limits for your application; content is blocked when one of those topics appears in a query or a response.
  </Accordion>

  <Accordion title="Word filters">
    Block specific words, phrases, and profanity on exact match — useful for competitor names, brand terms, or other disallowed vocabulary.
  </Accordion>

  <Accordion title="Sensitive information filters (PII)">
    Detect PII from a predefined list or from your own custom types defined with regular expressions, then redact or block it.
  </Accordion>

  <Accordion title="Contextual grounding checks">
    Evaluate whether a response is grounded in the provided source material and relevant to the question, to reduce hallucinations.
  </Accordion>

  <Accordion title="Automated Reasoning checks">
    Mathematically verify natural-language content against policies you define, using formal logic.

    <Info>
      Per AWS, Automated Reasoning checks do **not** protect against prompt injection — they validate content as-is. AWS recommends pairing them with content filters.
    </Info>
  </Accordion>
</AccordionGroup>

For the exact, current list of policy types and how to configure each, see [how Bedrock guardrails work](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-how.html) in the AWS docs.

## What you need from AWS

Configure your guardrail in the Amazon Bedrock console first. Then you only need three things to connect it to MCP Manager:

<Steps>
  <Step title="Guardrail ARN">
    From the AWS console: **Bedrock → Guardrails → your guardrail → ARN**. It looks like `arn:aws:bedrock:us-east-1:000000000000:guardrail/abc123`. MCP Manager parses the **region** and **guardrail ID** out of it to build the endpoint URL automatically. The rule-engine form links to the [Bedrock guardrails console](https://console.aws.amazon.com/bedrock/home#/guardrails) if you still need to create one.
  </Step>

  <Step title="Version">
    A **numeric guardrail version** (for example `1`), or the literal `DRAFT` for the unpublished working copy. Pinning a number lets you publish new guardrail versions in AWS while controlling exactly which one MCP Manager uses.
  </Step>

  <Step title="Authorization header">
    Under **Headers**, add a header named exactly `Authorization` with the value `Bearer <token>` — the word `Bearer`, a space, then a Bedrock API key. The form links directly into the AWS console to generate a long-term Bedrock API key for this credential.
  </Step>
</Steps>

<Note>
  The **endpoint URL is built for you** from the ARN and version — you don't enter it. MCP Manager constructs `https://bedrock-runtime.<region>.amazonaws.com/guardrail/<guardrail-id>/version/<version>/apply`, taking the region and guardrail ID from the ARN. The HTTP method is fixed to POST.
</Note>

## How it behaves as a rule

Once saved, the Bedrock engine appears in the **Detection method** dropdown on any gateway rule. On the rule's [detection hook](/features/gateway-rules/overview#detection-hook-when-a-rule-fires), MCP Manager forwards the tool message to your guardrail through `ApplyGuardrail` and acts on the result. As with every [custom engine](/features/gateway-rules/custom-rules-engines), there is **no action picker** — the guardrail's decision drives whether the message passes, is modified, or is blocked — and the rule's [failure mode](/features/gateway-rules/overview#failure-mode-what-happens-when-a-detection-method-fails) defaults to **Block** if Bedrock is unreachable or errors. You can [test](/features/gateway-rules/custom-rules-engines#testing-an-engine) the engine with sample text before attaching it to a gateway.

## Cost, tiers, and logging to plan for

A few AWS-side operational details affect how you configure and budget a guardrail. **All of these are AWS behaviors and can change — confirm the specifics against AWS before relying on them.**

### Safeguard tiers

Content filters and denied topics can each run in a **Classic** or **Standard** tier, and you can mix tiers within one guardrail. The Standard tier adds stronger contextual understanding (including robustness to typos and variations), better prompt-attack defense, and support for many more languages. Using the Standard tier requires opting in to **cross-region inference** for Bedrock Guardrails. See the [AWS safeguard-tiers announcement](https://aws.amazon.com/blogs/machine-learning/tailor-responsible-ai-with-new-safeguard-tiers-in-amazon-bedrock-guardrails/).

### Pricing

Bedrock Guardrails is billed **per policy, per text unit**, and you pay only for the policies you enable. A **text unit holds up to 1,000 characters**, so a longer message counts as several text units. Two billing nuances matter for a gateway that evaluates traffic inline:

* Evaluation is charged **even when content is blocked** — a block doesn't make the check free.
* In MCP Manager's standalone `ApplyGuardrail` use there is no model inference to pay for, so a blocked input costs only the guardrail evaluation.

Rates differ by policy and change over time, so use the [AWS Bedrock pricing page](https://aws.amazon.com/bedrock/pricing/) — which includes worked examples — as the source of truth before estimating cost.

<Note>
  These charges are billed by **AWS**, not by MCP Manager. As long as your plan includes custom rule engines, MCP Manager does **not** meter or charge per call for routing MCP traffic to a Bedrock guardrail — you pay AWS directly, under Bedrock's own pricing, for the calls your guardrail evaluates.
</Note>

### Logging and encryption

<Warning>
  If you enable Bedrock **model invocation logs**, blocked content can be stored **in plain text** in those logs. If that's a concern for your compliance or regulatory posture, disable invocation logging or scope it carefully. This is an AWS-side setting, separate from MCP Manager's own [logs](/features/viewing-logs).
</Warning>

Guardrails are encrypted with an AWS-managed key by default, and you can supply your own customer-managed KMS key instead. See AWS for the details.

## Further reading

<CardGroup cols={2}>
  <Card title="Lakera Guard" icon="shield-check" href="/features/lakera-guard">
    A security-first custom rule engine for prompt injection, jailbreaks, and PII.
  </Card>

  <Card title="Custom Rule Engines" icon="plug" href="/features/gateway-rules/custom-rules-engines">
    How custom engines are added, tested, and applied to gateway rules.
  </Card>

  <Card title="Gateway Rules Overview" icon="shield-halved" href="/features/gateway-rules/overview">
    Detection methods, hooks, failure modes, actions, and rule ordering.
  </Card>

  <Card title="Microsoft Presidio" icon="user-shield" href="/features/gateway-rules/presidio">
    The built-in PII detection method, complementary to a Bedrock guardrail.
  </Card>
</CardGroup>

## External sources

<CardGroup cols={2}>
  <Card title="Guardrails product overview" icon="book-open" href="https://aws.amazon.com/bedrock/guardrails/" />

  <Card title="How guardrails work" icon="diagram-project" href="https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-how.html" />

  <Card title="Pricing and worked examples" icon="money-bill" href="https://aws.amazon.com/bedrock/pricing/" />

  <Card title="Automated Reasoning checks" icon="scale-balanced" href="https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-automated-reasoning-checks.html" />
</CardGroup>