AFTER-TOOL CALLBACK · REDACTION
After-tool callback: redact returned content
A customer lookup returns more than the agent needs. Redact it in an after-tool callback and count what still reaches the model, and what the agent can no longer answer.
Your experiment
The agent must tell a customer the delivery city, the order status and which card was charged. get_customer also returns an email, a phone number, the full card number, free-text notes that repeat the email and phone, and a contacts list holding a third party’s email. The opening callback removes the three obvious keys. Count what still leaks and what can no longer be answered.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Fictional record. The page assumes the result returned by the after-tool callback is what the model sees and what the stored function-response event holds; check that against the ADK Java version you run. Pattern matching is modeled as exact, apart from the card-format option. No model or tool is called.
A result bigger than the question
An after-tool callback sees a tool’s result before it re-enters the model’s context, and can return a replacement. Redaction method chooses how the replacement is built: remove named keys, scan every string for email, phone and card patterns, or rebuild the result from an allowlist of fields. Also scan nested objects and lists extends the first two methods into the contacts list. Card pattern allows spaces matters only for the pattern scan. Card number removes the number or keeps its last four digits. Where redaction runs moves the same rule onto the final answer.
The opening run: the obvious keys are gone
Removing the email, phone and card keys protects those three fields, but the same phone and email sit inside the free-text notes, and a third party’s email sits inside contacts[0]. Three pieces of personal data still reach the model and the stored event. And because the card was removed rather than masked, the agent cannot say which card was charged: 2 of 3 questions answered. Redaction by naming what to remove fails on whatever nobody named.
Scanning versus allowlisting
Tick Also scan nested objects and lists: the third-party email is protected, the notes still leak (2). Choose Scan every string for patterns: the notes are cleaned, but the card pattern expects 16 contiguous digits, so the spaced number passes through in full along with the contacts email. Tick Card pattern allows spaces and scan nested lists: no leaks, but the card is gone and the answer is 2 of 3. Keep only allowlisted fields with Mask all but the last four digits: nothing leaks and all 3 questions are answered.
Failure boundary: redacting too late
Keep the allowlist and masking, and set Where redaction runs to On the final answer only. The answer the user sees is clean, but the model read the raw record, so all six pieces of personal data were in its context and in the stored event and trace. Masking the reply does not undo what the model and the logs already received. Redact in the after-tool callback, from an allowlist, and mask rather than delete the fields the task needs.
Reading the run and its limits
Play replays the tool result, the redaction, what the model reads, what is stored and the answer over sixty inspection seconds; the table lists each piece of personal data and whether it leaked. Next event, Restart, Speed and Inspection time control the replay. Real pattern matching misses formats and flags false positives; this page treats it as exact apart from card spacing. Test redaction against realistic, messy records, including free text and nested lists.