Google Model Armor’s Workspace Update: Configure Screening for Gemini Agents

Google’s October 9, 2026 Model Armor release note announces enhanced prompt-injection and jailbreak screening for Workspace emails, documents and files. The update matters to teams feeding that content into Gemini workflows: Google specifies US and EU multi-region screening endpoints and templates or floor settings using filter version v3 or later.

Google claims better detection and fewer false positives, but the announcement provides no numerical evaluation. This is a Workspace-specific enhancement, not the launch of v3, which arrived in May. The practical task is to establish which content gets screened, under which policy, before the agent uses it. Release chronology.

1. Identify the integration before changing a template

Start with the route the email or document takes into the agent. An app-level setting, a model-call integration and a direct screening API have different responsibilities.

Google documents screening of intermediate grounding material in Gemini Enterprise, Agent Runtime and Apigee, not just the first prompt and final answer. That does not establish coverage for every Workspace connector or delegated custom agent. Treat each retrieval route as a separate verification item. Integration coverage.

For the broader choice of enterprise workflows to pilot, see RohitAI’s Gemini agent governance guide. This guide focuses on the screening configuration.

2. Check the endpoint, enabled filter and resolved version

As checked on October 9, Stable resolves to v3 and Latest to v4 in us/eu. Templates without a version, and floor settings, default to Stable. Aliases advance automatically; an explicit version supports a controlled upgrade cycle. Google currently schedules legacy v1/v2 retirement for December 17, 2026, with regional exceptions. Version table and lifecycle.

Read the current template before editing it. The following is a configuration fragment for an input template, not a complete deployment or a replacement for existing filters, residency settings and enforcement choices. Its fields come from Google’s version selector and template configuration documentation.

{
  "filterConfig": {
    "piAndJailbreakFilterSettings": {
      "filterEnforcement": "ENABLED",
      "confidenceLevel": "HIGH"
    }
  },
  "templateMetadata": {
    "filterVersionSelector": {
      "alias": "FILTER_VERSION_ALIAS_STABLE"
    }
  }
}

Selecting v3 does not enable a disabled injection filter. HIGH flags high-confidence findings; LOW_AND_ABOVE also includes lower-confidence findings. Google recommends High to reduce false positives. That threshold is not a guarantee that all malicious content will be detected. Filter and confidence settings.

For direct screening, a us template uses modelarmor.us.rep.googleapis.com; an eu template uses modelarmor.eu.rep.googleapis.com. The endpoint must match the template location. The global Model Armor endpoint manages floor settings; it is not a sanitization endpoint. Endpoint documentation.

Do not confuse Model Armor multi-regions with Agent Platform multi-regions. Google explicitly says Agent Platform floor settings do not apply to requests sent to its multi-regional model endpoints. Its floor-routing table lists regional locations. The documentation does not clearly map the October 9 enhancement onto every regional route: confirm that mapping before claiming coverage, or evaluate direct us/eu screening with application-side enforcement. Floor-setting routing.

3. Configure blocking and scan-failure handling separately

For a Gemini Enterprise app, Google’s enablement guide specifies Gemini Enterprise Admin, Model Armor Admin and Model Armor User permissions for the relevant administrators and caller. US apps use us templates; EU apps use eu; Global apps can use either. Configure separate input and output templates. Google recommends avoiding the injection filter on responses because it can add false positives and latency.

1. Open the app’s Configurations → Assistant page, enable Model Armor and enter the two template resource names.

2. Set the processing-failure toggle deliberately, then choose Save and publish. In the API, failureMode accepts FAIL_CLOSED or FAIL_OPEN; the documented default is FAIL_CLOSED. App setup and failure modes.

Two decisions remain distinct. INSPECT_ONLY records detections without blocking them; INSPECT_AND_BLOCK enforces detected violations in supported managed integrations. Template enforcement. Separately, fail-closed stops app interactions when screening fails, while fail-open permits them without screening. Gemini Enterprise failure behavior.

For Agent Platform, inspect request-level templates as well as floor settings: request templates take precedence. Google documents continued processing without screening when Model Armor is unreachable, internally errors or is absent from the routed region. Blocking mode still reports configuration errors such as permission or quota problems. These are integration-specific behaviors, not Gemini Enterprise app defaults. Agent Platform limitations and precedence.

A policy that blocks detected violations is not necessarily a policy that stops work when screening fails.

Rollout recommendation: use inspect-only to assess false positives in a bounded workflow that cannot send messages, export data or change records. Decide which findings warrant blocking and which failures must halt the workflow before granting consequential tool access. Direct API users must implement that gate themselves.

4. Distinguish a completed scan from an absent match

In custom API handling, check invocationResult separately from the verdict. SUCCESS means the filters were invoked successfully; PARTIAL means some were skipped or failed; FAILURE means all were skipped or failed. Also verify that the required filter was enabled, inspect its execution state and messages, and record the resolved filter version. SanitizationResult reference.

Recommended application rule: only treat content as having passed your screening policy after the required checks complete and return an allowed verdict. Send timeouts, skipped filters and missing results down an explicit failure path. A no-match field alone is insufficient evidence.

For ordinary direct-API and buffered text screening, the injection filter’s limit is 65,536 tokens, including extracted document text. Files or images above 4 MB are skipped. Over-limit processing can produce EXECUTION_SKIPPED. Real-time streaming has a separate token-limit exception. System limits. The Gemini Enterprise integration is also documented without that token limit, but remains subject to throughput quotas. Integration-specific limits.

Embedded-image coverage remains unclear: the general integrations page says images inside documents are not screened, while the Gemini Enterprise-specific guide says directly uploaded embedded images are screened. Confirm the exact path before relying on it; this guide does not assume universal image protection.

5. Budget for scans and preserve useful evidence

The default Model Armor API quota is 1,200 queries per minute per project; ExternalProcessor has a separate 600-QPM quota. Published quotas. Illustrative calculation: if a custom interaction makes one prompt scan and one response scan, 1,200 ÷ 2 gives an upper bound of 600 interactions per minute from that API quota alone. Intermediate scans, retries, shared traffic and other limits reduce that ceiling. This is capacity arithmetic, not measured throughput.

Google’s current pricing table lists 2 million monthly tokens free for standalone/API and inline usage, then US$0.10 per additional million. Gemini Enterprise app usage is included in its subscription; that inclusion is not a blanket entitlement for separate custom API traffic. These are screening charges, not the total cost of model inference, infrastructure or logging.

Use Data Access audit logs for routine verdict review. Template payload logging can retain raw prompts and responses; restrict access and retention if that content is necessary. Logging guidance.

Proposed acceptance checks—not tests performed for this article:

• Use authorized synthetic emails and documents, both benign and containing attempted instruction redirection, for every supported retrieval route.

• Exercise detections, processing failures and over-limit inputs in staging without live external actions. Confirm the application’s actual allow/block behavior, not only its configured mode.

• Record the route, template, resolved version, scan completion, verdict and downstream action. Keep tool permissions and approval for consequential actions separate from content screening.

The next step is a route-by-route coverage record: what enters, where it is screened, which policy applies and what happens if that scan cannot finish. That gives the team a concrete basis for enabling the Workspace enhancement without assuming the whole agent is covered.

Methodology: AI-assisted reporting and analysis based on Google’s release notes, API references and configuration guides, rechecked on October 9, 2026. No tenant configuration, security test or benchmark was performed. Detection improvements remain Google’s claims; the release note supplies a date, not an exact announcement time.