Skip to main content
The Google Model Armor template connects a Model Armor template as a custom rule engine 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.
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 and the Model Armor pricing section of that page as the authoritative source for the current filters, limits, and prices.

​
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. 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. The current set, per Google:
Detect and filter harmful content across categories such as hate speech, harassment, sexually explicit, and dangerous content, with configurable confidence thresholds.
Detect attempts to subvert the model’s instructions or safety such as prompt-injection and jailbreak patterns are reported with a confidence level.
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.
Flag URLs in the content that are known to be malicious.
Screen for child sexual abuse material. This protection is always evaluated.
For the exact, current list of filters and how to configure each, see 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.
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.

​
Default detection (Basic)

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

Open your template

In the Model Armor console, open your template → Edit, and turn on the Sensitive Data Protection filter.
2

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

Create an inspection template

In the Sensitive Data Protection console, 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.
2

(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).
3

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

Point your Model Armor template at them

Back in your template in the Model Armor console, 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>.
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 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 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.”
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.

​
What you need from Google Cloud

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

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

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).
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.
3

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.

​
Connecting it in MCP Manager

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

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

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

​
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, MCP Manager forwards the tool message to your template through sanitizeModelResponse and acts on the result. As with every custom engine, there is no action picker — Model Armor’s verdict drives the outcome: The rule’s failure mode defaults to Block if Model Armor is unreachable or errors (including if the service account can’t authenticate). You can test 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.
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.

​
Further reading

Amazon Bedrock

A managed guardrail alternative you connect the same way.

Lakera Guard

A security-first custom rule engine for prompt injection, jailbreaks, and PII.

Custom Rule Engines

How custom engines are added, tested, and applied to gateway rules.

Gateway Rules Overview

Detection methods, hooks, failure modes, actions, and rule ordering.

​
External sources

Model Armor overview

Create and manage templates

Model Armor IAM roles

Sanitize prompts and responses