Choose guardrails by the kind of judgment

Learning objective

Choose deterministic guardrails for hard policy constraints and model-based checks for judgments that require understanding meaning or intent. Human approval, Model Armor configuration, and sensitive-data inspection are outside this lesson’s scope.

Core idea

Use this rule:

model interprets meaning -> code enforces boundaries

A deterministic guardrail evaluates explicit data and state with code or a policy engine. Given the same inputs and policy state, it returns the same decision. Use it for an invariant that the system must never waive, such as an allowed tool list, an identity and access management (IAM) decision, a transaction limit, or a valid destination.

A model-based check uses a language model or specialized classifier when the decision depends on context, phrasing, intent, or other semantic meaning. Use it to judge whether a proposed action matches the user’s request, whether text contains a disguised instruction, or whether a response makes an unsupported claim.

Google Cloud describes a dual-layer policy architecture: access controls establish resource boundaries, while semantic policies interpret natural-language intent before execution. See 20 questions for the agentic enterprise.

How it works

Start by rewriting each policy statement as a decision question. If trusted fields and current system state are sufficient to answer it, implement an executable predicate. Typical deterministic checks include:

• schema, type, length, range, enum, and format validation;
• tool, operation, host, path, and recipient allowlists;
• identity, role, resource, tenant, and environment authorization;
• spending, rate, iteration, time, and data-volume limits;
• state preconditions, uniqueness constraints, and deny rules.

Run these checks in trusted code outside the model’s reasoning. Recheck them at the last enforcement point before a tool causes a side effect. A prompt that says “never spend more than $500” can guide planning, but only the tool wrapper or policy engine can prevent a call with amount = 501. Google Cloud’s security guidance likewise separates model screening from programmatic validation of data types, formats, and ranges; see the AI and ML security perspective.

Use a model-based check when converting the rule to a predicate would discard the meaning that matters. Give the checker the original request, candidate response or action, and a precise rubric. Require ALLOW, DENY, or REVIEW with a policy identifier and confidence. Validate that result’s schema in code and map it to a fixed workflow transition.

Either path ends in code: a predicate is rechecked at the last enforcement point, and a model verdict is validated and mapped to a fixed workflow transition.

Model-based checks can screen three boundaries:

1. Input: Does the request or retrieved content contain an instruction that conflicts with its role as data?
2. Output: Does the response violate a contextual communication policy or make an unsupported claim?
3. Action: Does the proposed tool call remain aligned with the user’s stated intent?

The OWASP prompt-injection prevention guidance places model-based guardrails at these boundaries, but treats them as a layer beside input validation, least privilege, and human approval rather than a replacement for those controls.

Define the failure behavior for every check. A hard guardrail must not execute the prohibited action when its policy service fails or required context is missing. For a semantic check, choose DENY, REVIEW, or a restricted safe path according to the consequence of a false negative. Log the policy and checker versions, verdict, reason, and final action.

Key distinctions and trade-offs

The following table separates the two control types:

A deterministic check is not necessarily a keyword or regular-expression blocklist. Those mechanisms are repeatable, but attackers and ordinary users can express the same meaning with different words. Conversely, asking a model for JSON makes its output structured, not its judgment deterministic. Even a fixed seed provides only mostly deterministic generation, not a guarantee, according to the Vertex AI content generation parameters. CX Agent Studio reflects the same control choice by supporting custom guardrail rules defined with either natural-language behavior or code; see Guardrails.

Model checks require calibration. Test them against human-labeled, representative, and adversarial examples. Measure false-positive and false-negative rates by policy category, set thresholds from the cost of each error, and repeat the evaluation when the model, prompt, rubric, or traffic changes. Google Cloud’s judge-model evaluation guidance compares model judgments with human ratings by using balanced accuracy, F1, and confusion matrices. Runtime semantic checks need the same discipline.

Architecture / decision scenario

A retail support agent can issue refunds. The business policy permits an automatic refund only when the caller owns the order, the order is less than 30 days old, no refund already exists, the amount does not exceed the captured payment, and the amount is at most $500.

Implement all five rules in the refund tool’s trusted wrapper. The wrapper reads the authenticated principal and current order record; it does not accept those facts from the prompt. The model can propose a refund, but it cannot override a failed predicate.

Add a semantic action check before the wrapper to compare the user’s request with the proposed call. If the user asks for an $80 partial refund but retrieved text manipulates the agent into proposing $800, the semantic checker should return DENY because the action does not match the request. If that checker misses the mismatch, the deterministic amount rules still stop the call.

The model interprets the conversation; the wrapper guarantees the transaction boundary.

Common exam traps

• Treating a system instruction as enforcement for a hard policy.
• Using a model to decide an exact limit or permission that code can evaluate.
• Using keywords or regular expressions for a policy whose meaning survives paraphrase.
• Assuming structured model output, low temperature, or a fixed seed makes a semantic verdict deterministic.
• Letting a semantic checker directly execute a tool instead of validating and enforcing the resulting action in trusted code.
• Treating a passed content or intent check as authorization.
• Checking a proposed action early but not rechecking live policy and resource state immediately before execution.

What to remember

• Put exact, non-negotiable boundaries in deterministic enforcement code.
• Use models for meaning, intent, ambiguity, and contextual policy judgments.
• Let model checks produce signals; let trusted workflow code choose the action.
• Combine semantic screening with schemas, authorization, limits, and tool-side checks.
• Calibrate model checks, define failure behavior, and log every decision.

Knowledge check

References

• Google Cloud, 20 questions for the agentic enterprise
• Google Cloud Architecture Center, AI and ML perspective: Security
• Google Cloud, Guardrails in CX Agent Studio
• Google Cloud, Evaluate a judge model
• Google Cloud, Content generation parameters
• OWASP, LLM Prompt Injection Prevention Cheat Sheet