Skip to lesson

Google CloudProfessional Agentic Architect2026-095.2 Implementing secure agent behavior and execution

Inspect and de-identify sensitive data safely

Completed by the knowledge check

Learning objective

Use Sensitive Data Protection to inspect and de-identify data, then choose a safe inspect, redact, block, or continue response. This lesson focuses on runtime content controls at agent boundaries, not data discovery across stored datasets.

Core idea

Detection and enforcement are separate decisions:

content -> inspect -> classify finding -> apply policy -> safe content or denial

Sensitive Data Protection identifies possible sensitive values. Your application decides what those findings mean for the operation. Keep this policy deterministic: map the finding type, match likelihood, content direction, recipient, and intended action to an explicit outcome.

Apply the control before untrusted content enters a model and before model or tool output crosses a trust boundary. An input check can keep credentials out of a model prompt. An output check can keep personal data out of a response, tool argument, trace, or external system.

How it works

An infoType detector recognizes a category such as EMAIL_ADDRESS or CREDIT_CARD_NUMBER. Sensitive Data Protection provides built-in detectors and supports custom regular expressions and dictionaries for organization-specific values. An inspection finding can include the infoType, its location, and a likelihood that the match is correct. Likelihood is confidence in the match, not the business severity of exposing it. The infoType documentation also warns that detectors are not perfectly accurate, so test them with your own content and requirements.

Use content.inspect when the application needs findings and will make the enforcement decision itself. Configure an InspectConfig with:

  • only the built-in and custom infoTypes relevant to the boundary;
  • a minimum likelihood, with per-infoType adjustments when needed;
  • exclusion or hotword rules to reduce known false positives or add context;
  • finding limits only when they cannot hide a policy-relevant match;
  • quote handling appropriate to the consumer.

Specify infoTypes explicitly. An empty list invokes a default set that can add cost, latency, and unwanted matches. Reusable inspection templates centralize this configuration and make behavior consistent across callers.

Avoid returning finding quotes unless a protected reviewer or workflow needs the matched value. Quotes contain the sensitive text itself and are omitted by default, as described in the quote documentation. Do not copy raw quotes into ordinary logs or metrics.

Use content.deidentify when the workflow should receive transformed content. For unstructured agent text, the request combines inspection criteria with a DeidentifyConfig. Sensitive Data Protection returns content in the same structure with matching values transformed. Common transformations include:

  • redaction or replacement when the value is unnecessary;
  • character masking when a safe fragment must remain visible;
  • bucketing or date shifting when analytics need less precise values;
  • cryptographic pseudonymization when records must remain linkable.

Choose the least revealing transformation that preserves the task. Some pseudonymization methods are reversible, while cryptographic hashing is one-way. Reversible tokens require protected keys and controlled re-identification; they are not anonymous data. See the pseudonymization guidance and the complete de-identification transformation documentation.

Key distinctions and trade-offs

Use the following outcomes as policy actions:

OutcomeChoose it whenImportant consequence
InspectA protected component needs classification or audit metadataThe original content remains unchanged
RedactThe task can continue without the raw valueDownstream components receive transformed content
BlockThe value must not cross the boundary, or safe transformation cannot preserve the taskThe operation stops with a bounded error
ContinueNo prohibited finding meets policy, or policy explicitly permits the detected type in this contextNormal authorization and output controls still apply

Inspection alone does not protect content. It reports findings. Redaction changes content, but partial masking can still expose information. Blocking gives the strongest containment but can reject legitimate work after a false positive. Continuing preserves utility, but must be an explicit policy result rather than a fallback after a scanner error.

Tune match thresholds by infoType and consequence. A lower threshold catches more possible matches but increases false positives. A higher threshold reduces false positives but can miss sensitive values. For secrets or irreversible external actions, prefer a conservative threshold and block when inspection is unavailable. For a low-impact internal workflow, a controlled error or restricted path may be more appropriate. Never treat a scan failure as “no findings.”

Architecture / decision scenario

A support agent summarizes a customer ticket and can create an issue in an external vendor system. The ticket may contain an email address, an account ID, or an access token.

Before generation, the application de-identifies email addresses and account IDs with stable tokens so the summary can preserve references without exposing raw values. It blocks a detected access token because the model does not need it. After generation, the application inspects the proposed issue body again. It redacts permitted contact data, blocks any credential finding, and sends the issue only if the output policy returns continue.

The policy uses named inspection and de-identification templates under change control. It records infoType counts, policy version, outcome, and request identifier, but not quotes. If inspection times out, the external write is denied because that boundary is high impact. Representative tests cover true values, harmless values with similar formats, custom account IDs, prompt attempts to bypass redaction, and scanner failures.

Common exam traps

  • Treating match likelihood as the sensitivity or impact of the data.
  • Inspecting content but continuing without an enforcement decision.
  • Scanning only user input and ignoring model output, tool arguments, tool results, traces, and external responses.
  • Enabling every infoType instead of selecting and tuning relevant detectors.
  • Assuming de-identification always makes data anonymous or irreversible.
  • Including finding quotes in logs when location and type metadata are enough.
  • Continuing after an inspection error at a boundary that requires protection.
  • Treating Sensitive Data Protection as a replacement for authorization, encryption, secret management, or data-retention controls.

What to remember

  • Inspect detects; your deterministic policy decides the outcome.
  • Likelihood measures match confidence, not disclosure severity.
  • Redact when utility survives transformation; block when unacceptable risk remains.
  • Inspect both ingress and egress at the trust boundaries that matter.
  • Treat scanner failure explicitly, and fail closed for high-risk disclosure or side effects.
  • Minimize raw findings and protect reversible tokens and their keys.

Knowledge check

References