Skip to content

Add support for de-identification / sanitization in ModelArmorPlugin #7369

Description

@majsterkovic

Is your feature request related to a specific problem?

Currently, ModelArmorPlugin only supports blocking (BLOCK) execution when sensitive data or policy violations (such as PII) are flagged. This halts the agent pipeline and raises an error or rejects the interaction entirely.

In production environments (e.g., customer support, document analysis), users frequently supply sensitive information like emails, phone numbers, or account IDs unintentionally. Outright blocking these requests causes high friction and degraded user experience, when the desired behavior is simply to redact or mask the sensitive tokens and allow the agent workflow to continue safely.

Describe the Solution You'd Like

Extend ModelArmorPlugin to support the de-identify / sanitize capabilities provided by the Google Cloud Model Armor API (e.g., payload transformation/redaction), rather than strictly treating violations as binary pass/block gates:

  1. Prompt Sanitization: When inspection triggers a de-identification action, update the incoming prompt payload with the sanitized text returned by Model Armor (e.g., replacing raw PII with placeholder tokens like [PHONE_NUMBER] or [EMAIL_ADDRESS]) and let the request proceed to the model.
  2. Response Sanitization: Similarly, apply redaction/de-identification to model outputs before returning them to the client or subsequent tools.
  3. Configurable Behavior: Allow configuring whether the plugin should block, de-identify, or follow the action defined directly inside the Model Armor template policy.

Impact on your work

This is a critical requirement for deploying privacy-compliant, customer-facing agents into production. Without built-in de-identification support in the plugin, we cannot safely process requests containing sensitive fields without discarding the entire interaction.

🟡 Recommended Information

Describe Alternatives You've Considered

  • Custom Pre-/Post-Processing Hooks: Calling the Model Armor API or Cloud DLP independently in custom pipeline interceptors before passing data to ADK. This duplicates plugin logic, increases boilerplate, and defeats the purpose of having a dedicated ModelArmorPlugin.
  • Catching the Block Exception: Intercepting the rejection and asking the user to re-phrase without PII, which introduces unnecessary conversation turns and degrades UX.

Additional Context

Google Cloud Model Armor natively supports both detection/blocking and sanitization/redaction via its sanitizeUserPrompt / sanitizeModelResponse APIs. Aligning ADK's ModelArmorPlugin with these native API capabilities would make it significantly more versatile for enterprise adoption.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions