How to wear Model Armor 3: How you protect sensitive data from LLM. Do you need to?

When building Generative AI applications for the enterprise, you are likely hyper-aware of the risks surrounding sensitive data. The knee-jerk reaction for many engineering teams is to aggressively block all sensitive data ‒ ranging from PII to financial records and internal credentials ‒ from absolutely everywhere in the stack.

But a blind, one-size-fits-all approach introduces its own massive headaches. It compromises internal reasoning, ruins user experiences and breaks downstream autonomous systems. As I promised in the first “How to wear Model Armor” post, we are going to dive into exactly when to keep sensitive data out of your language models, the reasons you must often avoid de-identifying an agent’s output, and how to orchestrate this balance using Google Cloud’s Sensitive Data Protection (SDP) and Model Armor.

When should we scrub sensitive data

The conventional wisdom in GenAI security is simple: block all sensitive data on ingress to prevent sensitive data exposure, and allow it on egress so the user gets a useful answer.

However, if you are building complex, multi-tool agents, you quickly realize this black-and-white approach breaks down. Modern agents operate with fluid context boundaries. Handling sensitive data requires abandoning absolute rules in favor of Data Minimization and the Principle of Least Privilege.

The Principle of Least Privilege: Controlling what the LLM sees

This principle dictates that a model should have only sensitive data it needs to perform its immediate task, and no more.

• The Ingress Dilemma: Redacting user ingress protects against accidental memorization and keeps you compliant. If the LLM does not strictly need the data to formulate its plan, systematically redact it. But what if, for example, your healthcare routing agent needs a patient’s Medical Record Number (MRN) to successfully execute a backend API search? A blanket ingress block (e.g., replacing it with [MRN_REDACTED]) means the agent’s downstream tool calls will instantly fail. You must grant the LLM the privilege to see that data.
• Revoking the Privilege: Least Privilege is temporary. If you allow sensitive data into the context window in one call, it doesn’t mean it should be allowed next time. If you do let sensitive data into the context for a specific tool call, you must proactively shrink or prune the conversational history immediately after the call succeeds. This ensures the information doesn’t linger in the context window and accidentally leak during subsequent turns in the same session.

Data Minimization: Controlling the “Hidden Ingress” and Egress

This principle dictates that your application should only process and expose the absolute minimum amount of data necessary to satisfy the user’s request. This becomes critical when dealing with the data your agents pull from your own backend systems.

• Tool Calls & “Hidden Ingress”: Agents don’t just echo user input; they fetch rich context via function calling. Imagine an agent calling a get_claim_details API. The API might return a massive JSON payload containing the user’s status, but also their home address, SSN, and internal risk scores. This creates a “Hidden Ingress” ‒ sensitive data being injected directly into the LLM by your backend. Data Minimization requires you to scrub this payload before the agent reads it, ensuring the LLM only receives the relevant status fields it needs to answer the user.
• The Egress Danger: It is tempting to leave egress completely unfiltered, assuming that if a user asks for their own account number, they should get it. But because LLMs are non-deterministic, the “Hidden Ingress” is a liability. The agent might hallucinate or over-summarize, accidentally echoing a hidden risk score or full SSN back to the chat UI ‒ even though the user never asked for it. Applying Data Minimization to egress means auditing your traffic and masking any data leaked from your backends that the user didn’t explicitly request.

Here is how to visualize this decision tree:

  graph LR
    classDef default fill:#f9f9f9,stroke:#333,stroke-width:1px;
    classDef highlight fill:#e1f5fe,stroke:#0288d1,stroke-width:1px,color:#01579b;
    classDef alert fill:#ffebee,stroke:#c62828,stroke-width:1px,color:#b71c1c;
    classDef safe fill:#e8f5e9,stroke:#2e7d32,stroke-width:1px,color:#1b5e20;

    User(("User")):::highlight --> Ingress{"Sensitive Data<br>Needed?"}
    Ingress -- No --> Mask["Mask Data"]:::safe
    Ingress -- Yes --> Pass["Allow Data"]:::alert
    
    Mask --> LLM("LLM Core"):::highlight
    Pass --> LLM
    
    LLM --> Tool{"Tool Call?"}
    Tool -- Yes --> Backend["Backend API"]:::highlight
    Backend --> Hidden["Raw Payload<br>(Hidden Ingress)"]:::alert
    Hidden --> ScrubBackend["Scrub Payload<br>(Minimization)"]:::safe
    ScrubBackend --> Prune["Prune Context<br>(Least Privilege)"]:::safe
    Prune --> LLM
    
    Tool -- No --> Egress{"Backend Leaked<br>Data?"}
    
    Egress -- Yes --> Scrub["Scrub Egress"]:::safe
    Egress -- No --> AllowOut["Allow Original"]:::safe
    
    Scrub --> Out(("Output")):::highlight
    AllowOut --> Out

From Decision Tree to Agent Operations

The decision tree above outlines the logical flow of your agent, but translating this into code requires understanding which tools handle which actions. Mask Data (on user ingress), Scrub Egress (on agent output), and Scrub Payload (on backend tool responses) are all data transformation tasks that can be implemented using Sensitive Data Protection (SDP) to find and redact sensitive string patterns. In contrast, Prune Context is a purely logical orchestration step ‒ programmatically dropping specific messages from the agent’s memory array using Agent Developer Kit (ADK) or another agent framework, and does not involve SDP at all.

For the actions where SDP is applicable, you must decide whether to invoke it standalone or bundled within a Model Armor check. Combining SDP with Model Armor is ideal for the external boundaries of your application ‒ specifically Mask Data on ingress and Scrub Egress on the final output. At these edges, you need to protect against prompt injections, jailbreaks, and toxicity anyway, so executing SDP within Model Armor’s unified AI firewall makes architectural sense. Conversely, for internal operations like Scrub Payload, where an agent is simply parsing a trusted backend database response, invoking the full suite of Model Armor threat checks alongside SDP adds unnecessary latency and cost.

The general rule of thumb is this: use SDP within Model Armor when you are crossing a zero-trust boundary (user-to-agent or agent-to-user) and need comprehensive threat protection, but use explicit, direct SDP API calls when you are deep inside the agent’s internal reasoning loop and only need surgical data redaction. Additionally, if your organization requires enterprise-wide, centralized governance over these data redaction templates, Model Armor’s policy management capabilities often make it the preferable choice over disjointed, individual SDP API calls.

Sensitive Data Protection operation

Before moving forward, let’s briefly review exactly what an SDP operation actually does to your data. SDP operation includes two different actions:

• Discovery (Inspection): This process scans a payload and simply flags the presence of sensitive data without altering the text. This is fantastic for auditing egress traffic or routing requests to a human reviewer.
• De-identification (Mitigation): This physically transforms the data before passing it along. The three major mitigations are removal (deleting the text), masking (e.g., partially replacing a string like ***-**-1234), and tokenization (replacing the PII with a unique surrogate value that can potentially be reversed or recovered later by authorized backend systems).

All three operations we discussed use the de-identification action since they expect to inspect the input and to apply a selected mitigation. This operation requires two configuration parameters called an inspection template and de-identification template. The first template describes the type(s) of sensitive data to discover while the second defines the de-identification action to apply to the found data per type.

A frequent choice for beginners is turning on every single SDP info type (names, addresses, phone numbers, IP addresses, medical terms). It lets you de-identify all possible types of information but it is incredibly expensive both in time and monetary cost. Another thing to be aware of is the selection of info type can sometimes result in false negative discovery. For example, consider the PERSON_NAME info type. There are some person names that might not be easily derived from an input text.

Recommended practices

Do not use basic configuration: Model Armor policy supports sensitive data protection in two configurations: basic ‒ which includes a fixed list of info types, and advanced ‒ which acts like a direct call to the SDP API, using explicitly provided inspection and de-identification templates. Because the masking and scrubbing operations in the decision tree above require transforming and de-identifying data, the basic configuration cannot be used for them, as it only supports discovery. Additionally, the fixed list of info types in the basic configuration can be insufficient for most requests.

• Selectively call SDP API in functional calls: When an agent implements a function calling the sensitive data should be scrubbed from the tool’s output (see the flow). Direct SDP API is the most effective way to do it. The SDP templates should be fine tuned to the expected types of sensitive data to allow only information required/expected and masking or deleting all the rest. The templates need to be injected into code to allow API invocation. However, the control over the template definition remains “external” to code developers, allowing centralized management and control.
• Delegate invocation to integration configurations: Google Cloud provides two methods to control ingress and egress for an agent: in-code implementation ‒ write the logic of the Model Armor invocation as a part of the agent source code, and Model Armor integration policies ‒ use the Agent Gateway policies to enforce Model Armor invocation on ingress and egress including actions related to sensitive data findings. Agent Gateway allows to move the invocation and result processing logic from the code and increase governance of the policies through centralized management, extensive observability and use of Security Command Center as a single pane of glass for AI security.

Wrapping up

Data security in GenAI is not a blunt instrument; it requires surgical precision. Keep your LLM context windows clean by strictly redacting sensitive data on ingress, except when it is required for LLM processing or in further tool calls. On egress, audit the response, and only mask sensitive data that accidentally leaked from your own backends. Minimize data inspection for intermediate operations between LLM and agent, except for the cases when tool invocation may expose sensitive data. Apply the same logic for agent-to-agent communication enforcing the data boundaries and following the business workflow logic.

Finally, a quick note on governance and costs:

• Costs: Model Armor is priced heavily around GenAI workflows, at $0.10 per 1 million tokens processed (correct in August 2026). However, if you use Advanced SDP templates inside Model Armor, you pay the Model Armor token cost plus the underlying SDP byte-processing cost. Differentiate between use of Model Armor and SDP APIs to avoid paying unnecessary Model Armor invocation costs.
• Audit vs. Content Logging: By default, Model Armor’s Audit Logs capture administrative calls without recording your actual prompt text. However, if you explicitly enable log_sanitize_operations in your Model Armor template, Cloud Logging will capture the original data payload and the data that was de-identified by SDP. This configuration provides an additional governance level over standard auditing to support troubleshooting and governance forensic. Note that enabling this configuration requires limiting access to Cloud Logs, as the logs will contain the sensitive user information.