> ## 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.

# Google Model Armor

> What Google Cloud Model Armor is and how to connect a template to MCP Manager as a custom rule engine: the filters it enforces, the sanitizeModelResponse integration, the project/location/template plus service-account-key setup, server-side authentication, and the pricing and behavior to plan for.

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

<Note>
  This page summarizes Model Armor to help you decide how to configure a template for MCP Manager. Google owns the feature and changes it often — treat the [Model Armor documentation](https://docs.cloud.google.com/model-armor/overview) and the Model Armor pricing section of that page as the authoritative source for the current filters, limits, and prices.
</Note>

## What Model Armor is

Google Cloud Model Armor is a **managed AI-safety service** that screens content against filters you configure in a template — both prompts on the way in and model (or tool) responses on the way out. Its defining property for governance is that it enforces **controls that don't depend on a model cooperating**: unlike instructions embedded in a prompt, a Model Armor verdict doesn't rely on the model's reasoning quality. It is model-independent and cloud-agnostic — it evaluates text, so it works regardless of which model your client ultimately talks to.

### How MCP Manager integrates it

Model Armor exposes a **`sanitizeModelResponse` endpoint that evaluates content against a template without invoking any foundation model** — standalone content screening, decoupled from inference. MCP Manager sends the **tool message text** from your MCP traffic to that endpoint (as `modelResponseData`), Model Armor applies the template's filters, and MCP Manager acts on the verdict. Two consequences are worth knowing:

* **It's response-direction today.** MCP Manager fires this engine on tool **responses** — the result your agent is about to receive — and screens that text. (Model Armor also has a `sanitizeUserPrompt` endpoint for the request direction; MCP Manager uses the response endpoint.)
* **It complements model-side safety rather than replacing it.** Safety attached to a model call protects that call; screening at the MCP gateway protects the data flowing through your [connections](/features/viewing-logs). You can run both.

## What a template can detect

You configure Model Armor's filters in the template, and MCP Manager surfaces which filter fired in the rule's alert and [logs](/features/viewing-logs). The current set, per Google:

<AccordionGroup>
  <Accordion title="Responsible AI filters">
    Detect and filter harmful content across categories such as hate speech, harassment, sexually explicit, and dangerous content, with configurable confidence thresholds.
  </Accordion>

  <Accordion title="Prompt injection and jailbreak detection">
    Detect attempts to subvert the model's instructions or safety such as prompt-injection and jailbreak patterns are reported with a confidence level.
  </Accordion>

  <Accordion title="Sensitive Data Protection (PII)">
    Detect sensitive data using Google's Sensitive Data Protection (SDP). A **basic** configuration inspects and flags PII; an **advanced** SDP template can return a **de-identified** version of the text. When Model Armor returns de-identified text that differs from the original, MCP Manager applies it as a **modify** (see below) rather than blocking outright.
  </Accordion>

  <Accordion title="Malicious URL detection">
    Flag URLs in the content that are known to be malicious.
  </Accordion>

  <Accordion title="Child safety (CSAM)">
    Screen for child sexual abuse material. This protection is always evaluated.
  </Accordion>
</AccordionGroup>

For the exact, current list of filters and how to configure each, see [Model Armor templates](https://docs.cloud.google.com/security-command-center/docs/manage-model-armor-templates) in the Google Cloud docs.

## Detecting PII with Sensitive Data Protection

Model Armor's PII detection runs on **Sensitive Data Protection (SDP)**, Google's data-inspection service. You turn it on inside your Model Armor template in one of two modes: **Basic** for a quick start, or **Advanced** when you want to choose exactly what to detect — or to redact matches in place instead of blocking.

<Note>
  The Sensitive Data Protection filter uses Google's SDP service, so the **Sensitive Data Protection API** must be enabled in your project once: `gcloud services enable dlp.googleapis.com`, or accept the enable prompt the first time you open the SDP console.
</Note>

### Default detection (Basic)

The fastest way to start, with nothing to configure beyond a toggle.

<Steps>
  <Step title="Open your template">
    In the [Model Armor console](https://console.cloud.google.com/security/model-armor), open **your template → Edit**, and turn on the **Sensitive Data Protection** filter.
  </Step>

  <Step title="Choose Basic">
    Select **Basic**. Model Armor uses Google's built-in set of common PII detectors — a US-focused default list covering things like Social Security numbers and credit-card numbers. There's nothing else to configure in the template.
  </Step>
</Steps>

Basic mode **inspects and flags** PII but never rewrites it. In MCP Manager that means a tool response containing PII is **blocked** (the result is replaced with an error) — the right choice when such data should never reach the agent.

### Custom detection (Advanced)

Use Advanced when you want to pick specific data types, add your own, or **redact PII in place instead of blocking**. Advanced mode points your Model Armor template at one or two templates you create in **Sensitive Data Protection**.

<Steps>
  <Step title="Create an inspection template">
    In the [Sensitive Data Protection console](https://console.cloud.google.com/security/sensitive-data-protection), go to **Configuration → Templates → Create template**, and create an **Inspect** template. Choose the data types (infoTypes) you care about from Google's 150+ built-in detectors — PII, credentials, and more — and/or add a **custom infoType** with a regular expression or a word/phrase dictionary for organization-specific data (for example, your employee-ID format). Create it in the **same region** as your Model Armor template.
  </Step>

  <Step title="(Optional) Create a de-identification template">
    To have matches **redacted in place** rather than blocked, also create a **De-identify** template. It defines the transformation — replace a value with a placeholder like `[REDACTED]`, or mask it (for example, showing only the last four digits of a card number).
  </Step>

  <Step title="Let Model Armor use your templates">
    So Model Armor can read your templates at runtime, grant its **service agent** the **DLP User** (`roles/dlp.user`) and **DLP Reader** (`roles/dlp.reader`) roles on the project that holds the SDP templates. The service agent is `service-<project-number>@gcp-sa-modelarmor.iam.gserviceaccount.com` (your project number is on the Cloud console dashboard). Skip this and Advanced mode fails with a permission error.
  </Step>

  <Step title="Point your Model Armor template at them">
    Back in your template in the [Model Armor console](https://console.cloud.google.com/security/model-armor), set **Sensitive Data Protection** to **Advanced** and select your Inspect template (and the De-identify template, if you created one). If the form asks for a path rather than a picker, it's `projects/<project>/locations/<location>/inspectTemplates/<template-id>`.
  </Step>
</Steps>

How the two Advanced setups behave in MCP Manager:

* **Inspect template only** (no de-identification) → a match **blocks** the tool response.
* **With a de-identification template** → Model Armor returns the **de-identified** text and MCP Manager applies it as a **modify**: the agent receives the redacted or masked version instead of the original, and the message still flows through.

### Turn it into a high-value PII engine

A few choices take a basic Advanced setup and make it genuinely protective for MCP traffic — most of the value comes from the first two:

* **Mask instead of block.** Pair your Inspect template with a De-identify template so matches are redacted *in place* (a **modify**) rather than blocking the whole response. The agent keeps working — an email becomes `[EMAIL_ADDRESS]`, a card is masked to its last four digits — and the raw value never reaches it. Reserve blocking for data that must never appear at all; masking is usually the better default for tool output.
* **Catch credentials, not just classic PII.** Tool responses leak API keys, OAuth/JWT tokens, and passwords far more often than Social Security numbers, and an agent that ingests a live credential is a real risk. Add Sensitive Data Protection's **credentials-and-secrets** detectors — it's the single highest-value addition for an MCP gateway. (See the [infoType reference](https://docs.cloud.google.com/sensitive-data-protection/docs/infotypes-reference) for exact names such as `AUTH_TOKEN`, `GCP_API_KEY`, and `PASSWORD`.)
* **Add one custom infoType for your own identifiers.** A single regex or word-list detector teaches Model Armor your organization's data — employee IDs (e.g. `EMP-\d{6}`), internal project codenames, customer account numbers, internal hostnames. This is what makes the engine feel tailor-made rather than generic.
* **Keep the set tight and raise the threshold to cut noise.** Start with a focused list (emails, phone numbers, payment cards, your region's national ID, credentials) instead of all 150+ detectors, and set the inspection **minimum likelihood** to `LIKELY` so borderline guesses don't flood your [logs](/features/viewing-logs) with false positives. You can always widen it later.
* **Define it once, reuse it everywhere.** An SDP Inspect (and De-identify) template is a reusable resource — point multiple Model Armor templates at the same one so every gateway enforces the same definition of "sensitive."

<Note>
  SDP templates are **regional** and must be created in the same location as the Model Armor template that references them. This is a getting-started overview — for the full list of detectors, custom-infoType options, and de-identification transforms, see [Sensitive Data Protection](https://docs.cloud.google.com/sensitive-data-protection/docs).
</Note>

## What you need from Google Cloud

Set up the template and a service account in Google Cloud first.

<Steps>
  <Step title="Enable the API and create a template">
    Enable Model Armor (`gcloud services enable modelarmor.googleapis.com`), then create a template that defines your filters. Creating templates requires the **Model Armor Admin** (`roles/modelarmor.admin`) role. Note the **project ID**, the **location**, and the **template ID** you choose.

    <Warning>
      Choose a **regional** location (for example `us-east1`, `us-central1`, `europe-west4`) — not `global`. MCP Manager builds the regional endpoint `modelarmor.<location>.rep.googleapis.com`, and a `global` template uses a different host that MCP Manager will reject.
    </Warning>
  </Step>

  <Step title="Create a service account with the Model Armor User role">
    Create a service account (IAM & Admin → Service Accounts) and grant it the **Model Armor User** (`roles/modelarmor.user`) role on the project that holds your template — this is the role that lets it **call** the API (Admin is only needed to create templates).

    <Note>
      In the IAM role picker, searching "model" surfaces the Viewer, Admin, and Editor roles first — **"Model Armor User" is below them under "Show more" / additional results.** It's easy to miss.
    </Note>
  </Step>

  <Step title="Download a JSON key">
    On the service account's **Keys** tab, choose **Add key → Create new key → JSON**. The downloaded file (it contains `client_email` and `private_key`) is what you paste into MCP Manager.
  </Step>
</Steps>

## Connecting it in MCP Manager

In the **Google Model Armor** rule-engine form, provide:

<Steps>
  <Step title="Project, location, and template">
    Enter the **GCP project ID**, the template's **location**, and the **template ID** from the setup above. The form links to the Google Cloud console if you still need to create a service account.
  </Step>

  <Step title="Service account key (JSON)">
    Paste the full contents of the downloaded service-account key JSON. MCP Manager stores it **encrypted at rest** and uses it to authenticate to Model Armor.
  </Step>
</Steps>

<Note>
  The **endpoint URL is built for you** from the project, location, and template — you don't enter it. MCP Manager constructs `https://modelarmor.<location>.rep.googleapis.com/v1/projects/<project>/locations/<location>/templates/<template>:sanitizeModelResponse` and the HTTP method is fixed to POST. It validates that URL is a canonical Model Armor endpoint before sending any credential, so the access token can only ever go to Google.
</Note>

### Authentication is handled for you

You provide the **service-account key** once and MCP Manager authenticates to your Model Armor template for you — handling the Google Cloud access tokens server-side. Those tokens are `cloud-platform`-scoped, used only to call your Model Armor template, and never persisted. The stored key itself is encrypted at rest and is redacted (shown as `[Redacted]`) whenever the engine is read back in the UI.

## How it behaves as a rule

Once saved, the Model Armor 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 template through `sanitizeModelResponse` and acts on the result. As with every [custom engine](/features/gateway-rules/custom-rules-engines), there is **no action picker** — Model Armor's verdict drives the outcome:

| Model Armor result                                   | What MCP Manager does                                                  |
| ---------------------------------------------------- | ---------------------------------------------------------------------- |
| No filter match                                      | **Pass** — the message is forwarded unchanged.                         |
| Match, with de-identified text (advanced SDP)        | **Modify** — the sanitized text replaces the original in the response. |
| Match, no rewrite available                          | **Block** — the result is replaced with an error.                      |
| Evaluation didn't succeed, or an unreadable response | Routed through the rule's failure mode.                                |

The rule's [failure mode](/features/gateway-rules/overview#failure-mode-what-happens-when-a-detection-method-fails) defaults to **Block** if Model Armor is unreachable or errors (including if the service account can't authenticate). You can [test](/features/gateway-rules/custom-rules-engines#testing-an-engine) the engine with sample text before attaching it to a gateway; the test surfaces a precise message if the service-account key is missing or can't authenticate.

## Cost

Model Armor's standalone API — the way MCP Manager uses it — is billed by **Google Cloud**. **These are Google behaviors and can change — confirm against Google before relying on them.**

* There is **no charge for the first 2 million tokens per month**; usage beyond that is billed at roughly **\$0.10 per million tokens**.
* Model Armor counts a **token as four UTF-8 characters** (excluding whitespace), the same definition Vertex AI uses — so a longer tool message counts as more tokens.
* Because MCP Manager calls the standalone screening API, there is **no model inference to pay for** — a blocked or flagged message costs only the screening.

<Note>
  These charges are billed by **Google Cloud**, 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 Model Armor — you pay Google directly, under Model Armor's own pricing, for the calls your template evaluates.
</Note>

## Further reading

<CardGroup cols={2}>
  <Card title="Amazon Bedrock" icon="aws" iconType="brands" href="/features/amazon-bedrock">
    A managed guardrail alternative you connect the same way.
  </Card>

  <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>
</CardGroup>

## External sources

<CardGroup cols={2}>
  <Card title="Model Armor overview" icon="book-open" href="https://docs.cloud.google.com/model-armor/overview" />

  <Card title="Create and manage templates" icon="diagram-project" href="https://docs.cloud.google.com/security-command-center/docs/manage-model-armor-templates" />

  <Card title="Model Armor IAM roles" icon="key" href="https://docs.cloud.google.com/iam/docs/roles-permissions/modelarmor" />

  <Card title="Sanitize prompts and responses" icon="shield-halved" href="https://docs.cloud.google.com/model-armor/sanitize-prompts-responses" />
</CardGroup>