Protecting LLM prompts and responses with Google Model Armor.

Every prompt and response crosses a trust boundary.

An LLM application accepts natural-language instructions that can be ambiguous, adversarial, or mixed with sensitive business data. Attackers can attempt to override system instructions, extract secrets, insert unsafe links, or persuade an agent to misuse connected tools. A model can also disclose personal data or credentials in an otherwise valid response.

The design treats users, retrieved content, model output, and tool results as untrusted data. Model Armor becomes a policy enforcement point in the application path rather than relying on the model to defend itself.

Inspect before inference. Inspect again before release.

• The application authenticates the caller, validates request size, and assigns a correlation ID.
• The prompt is sent to sanitizeUserPrompt using a versioned Model Armor policy template.
• Prompt injection, jailbreak, sensitive-data, malicious-URL, and responsible-AI results drive allow, block, or review logic.
• Only an approved prompt reaches the configured LLM; the gateway remains independent of the model provider.
• The answer is sent to sanitizeModelResponse before it is returned to the user.
• Decisions and filter metadata are recorded in Cloud Logging for investigation and policy tuning.

One template, multiple focused controls.

Fail closed for high-confidence security violations.

prompt_result = model_armor.sanitize_user_prompt(prompt)

if prompt_result.high_confidence_security_match:
    block_request(reason=prompt_result.matched_filter)
elif prompt_result.sensitive_data_match:
    redact_or_route_for_review()
else:
    response = llm.generate(prompt)
    output_result = model_armor.sanitize_model_response(response)
    return response if output_result.safe else safe_fallback()

The application owns the final decision. Production policy should distinguish a security attack from a content-policy match, handle service errors explicitly, and avoid exposing filter details that help an attacker tune later attempts.

Measure first, then enforce with evidence.

1. Start in inspect-only mode against representative traffic and approved red-team prompts.
2. Measure detection rate, false positives, added latency, failures, and cost by application path.
3. Tune confidence thresholds and Sensitive Data Protection infoTypes with application owners.
4. Enable inspect-and-block for high-confidence injection, credential leakage, and malicious URLs.
5. Use floor settings to keep future templates above the organization's minimum baseline.

Log decisions without creating a second data leak.

Audit logs capture template administration and API metadata. Full sanitize-operation logging can include prompt and response content, so it should be enabled only with deliberate retention, regional routing, access controls, and redaction. Correlation IDs connect the application request, Model Armor decision, model invocation, and user-visible outcome without placing raw secrets in routine operational logs.

Test the control against attacks and normal work.

• Direct, obfuscated, and multilingual prompt injection attempts.
• Jailbreak prompts requesting system instructions, hidden context, or policy bypass.
• Synthetic PII, financial data, cloud credentials, and API keys in inputs and outputs.
• Benign business prompts with security terminology to measure false positives.
• Timeout, quota, oversized-input, unavailable-service, and skipped-filter paths.
• Regression tests for every policy template change before production enforcement.

Runtime filtering is one layer of the AI security model.

The gateway complements strong identity, least-privilege service accounts, tool allowlists, retrieval access controls, output encoding, rate limits, secret management, and human approval for high-impact agent actions. Model Armor reduces runtime risk; it does not replace secure application design or model evaluation.