GUARDRAILS · CALLBACK BOUNDARIES
Integrating guardrails at agent and tool boundaries
Send six requests through input, tool-argument, tool-result and output checks and see which boundary catches each harm, and which benign request is blocked.
Your experiment
Six fixed requests: a bulk deletion, a refund with a wrong amount, a web page carrying an injected instruction, an answer that leaks another customer’s phone number, and two benign requests. Start with only the broad input screen, then add one boundary at a time.
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
Deterministic model of where checks sit, using the before-model, before-tool, after-tool and after-model callback positions that ADK exposes. The model’s tool proposals are fixed per case; the sanitizer is assumed to recognise the injected sentence and the PII check to recognise the phone number. Real detectors miss and over-match; this model isolates placement, not detector quality.
Four boundaries, six requests
A tool-using agent offers four places to check: before the model sees the user input, before each tool call runs, after a tool returns, and after the model writes its answer. Six fixed requests pass through them. G1 asks to delete every customer record, G2 is a refund the model proposes as 5000 when the customer paid 50, G3 summarizes a web page whose text tells the assistant to email the conversation to dump@attacker.test, G4 gets an answer containing another customer’s phone number, and G5 (delete my own draft) and G6 (refund 40) are benign.
An input filter alone
The opening run uses only a broad input screen that blocks any request containing the word delete. It catches G1, but it also blocks the benign G5, and the three harms that never appear in the user’s words escape: the oversized refund, the injected email and the leaked phone number. Choose Targeted for the input screen: G5 is served and G1 is still caught, because the targeted rule looks for bulk deletion rather than a word.
Checks where the harm happens
Check Tool-argument policy. The proposed refund of 5000 exceeds Refund limit enforced by the tool policy (500) and is caught before the tool runs, and in G3 the injected send_email to an outside address is caught as well. The limit only matters while the tool policy is on: at 5000 the refund passes because it is not above the limit, at 4900 it is caught. With the input screen off, G1 is still stopped, now by the tool policy on delete_records.
Results and answers need their own checks
Check Tool-result sanitizer: the injected sentence is removed from the fetched page, the model never proposes the email, and G3 is caught at the tool result instead. Check Output PII check: the phone number in G4 is caught after the model. With the targeted input screen and all three later boundaries on, the run reports zero escaped harms and zero false blocks, with one catch at each boundary.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time show each request’s path, what the model proposed and where it stopped, across sixty seconds; the table repeats the full path and verdict. The model fixes what the language model proposes and assumes each detector recognises its pattern, so it measures placement, not detection accuracy. Real guardrails also need logging, appeal paths and tests with paraphrased attacks.