A production guardrail changed on August 31 even if nobody merged a configuration file. Google moved Model Armor’s Stable alias to v3, so the reassuring word “Stable” now points at different detection logic.
Google Model Armor v3 is now the Stable filter version. Any template configured with the Stable alias upgrades automatically. Versions v1 and v2 moved to Legacy status and are scheduled to retire on November 29, 2026.
This is not a reason to avoid managed guardrails. It is a reason to treat a filter promotion like a dependency update: run a fixed test corpus, compare decisions, inspect latency, and document what changed before users discover it for you.
Stable is a moving channel, not a pinned build
Google’s lifecycle documentation is explicit: an alias represents a stage, and the version underneath it can advance. When a new release becomes Stable, templates using that alias begin using the new release automatically. Teams that do not want that behavior must point to a numbered version.
| Template setting | Behavior now | Operational consequence |
|---|---|---|
| Stable | Uses v3 automatically | No migration edit, but decisions may change without a config diff |
| v3 | Pinned to the current Stable version | Controlled rollout now; another migration is required later |
| v1 or v2 | Legacy until November 29 | Short testing window before retirement |
| Retired version after November 29 | Sanitization uses the current Stable version | A stale pin does not preserve old behavior indefinitely |
That last row matters. Pinning v1 or v2 buys migration time, not permanence. Google says templates pointing at a retired version are sanitized with the current Stable version. A team that waits until retirement can receive the change at the least convenient moment.
Google reports better detection and fewer false positives
Google says v3 uses an updated prompt-injection and jailbreak detector trained to reduce false positives and improve detection and mitigation across attack vectors. Those are company-reported performance claims. The release notes do not publish a customer-specific confusion matrix for your languages, documents, tool calls, or attack mix.
“Fewer false positives” can mean a better user experience. It can also move the boundary around an uncommon attack pattern. The correct test is not whether v3 blocks a famous jailbreak. It is whether v3 makes better decisions on the traffic your application actually accepts.
Build a two-sided regression corpus
A guardrail test set needs legitimate hard cases and malicious cases. Otherwise a team can improve its block rate by making the product unusable, or improve completion rate by letting attacks through.
- Benign complexity: long policies, quoted malware descriptions, red-team reports, code, multilingual instructions, and support tickets that mention prohibited content without requesting it.
- Direct attacks: system-prompt override attempts, data-exfiltration requests, encoded instructions, role-play jailbreaks, and tool-abuse prompts.
- Indirect attacks: malicious instructions inside retrieved webpages, files, comments, metadata, and tool output.
- Boundary cases: the same request rewritten across languages, formats, whitespace, images, and long-context positions.
- Expected result: allow, block, redact, warn, or escalate, plus the reason a reviewer would accept.
Run the same corpus against the old pinned version and v3. Record changed decisions, not just aggregate pass rates. A 1% change can be harmless if it fixes false positives, or serious if it affects the one tool call that moves money.
Our review of Mistral’s policy-adaptive safety classifier explains why the policy, detector, and action must be tested as a chain. A good classifier still needs an enforcement path that fails safely.
The new input limit has a separate 256-URL ceiling
Model Armor now supports prompts and responses up to 65,536 tokens, or 262,144 characters, for several filters. Google also says it scans only the first 256 URLs found in the content.
That limit is easy to miss in agent workflows. A browser agent, research system, or security report can assemble hundreds of links. Teams should not assume that every URL in a long payload receives the same malicious-URL check. Count and normalize links before sanitization, reject pathological inputs, or split work into bounded batches with explicit provenance.
Choose alias or pin by your rollback ability
| Environment | Sensible default | Required control |
|---|---|---|
| Development | Latest or v3 | Continuous corpus testing and visible changed decisions |
| Staging | Match the intended production version | Replay real, redacted traffic before promotion |
| Low-consequence production | Stable | Automated monitoring and a rapid route to a pinned version |
| High-consequence production | Explicit version | Change window, signed test evidence, rollback, and retirement calendar |
Managed changes can be valuable because defenses adapt to new attacks. The failure is allowing a managed change to become an invisible change. This is especially important for agent gateways, where Model Armor can sit between a model and tools. Our managed-agent hooks review shows why teams must decide what happens when a safety component is unavailable, uncertain, or bypassed.
A migration plan before November 29
- Inventory every Model Armor template and record whether it uses an alias or version number.
- Export a representative corpus with expected decisions and consequence labels.
- Compare v1 or v2 with v3, then review every changed high-consequence case.
- Measure p50, p95, and p99 latency as well as timeouts and skipped detections.
- Test long inputs, multilingual content, indirect prompt injection, and more than 256 URLs.
- Choose Stable or v3 explicitly and record the reason, owner, rollback route, and next review date.
- Finish before November 29; do not treat retirement day as a deployment window.
My verdict: keep Stable, remove invisible Stable
For many applications, following the Stable channel is a reasonable trade: Google maintains the detector while the team avoids every manual version migration. I would keep it only if a version promotion automatically triggers the same evidence review as a code dependency update.
For actions involving credentials, money, external messages, public code, or regulated data, pin the tested version until a controlled v3 comparison passes. A guardrail should reduce uncertainty. An unobserved alias change creates it.
Read the primary sources
- Read Google Cloud’s Model Armor release notes.
- Review the filter-version and alias lifecycle documentation.
- Use our AI-agent security scorecard to test the surrounding identity, tool, secret, and rollback controls.
Checked August 31, 2026. Version dates, alias behavior, retirement behavior, limits, and feature claims come from Google Cloud documentation. Recommendations and test matrices are Musthave.ai’s analysis.
