ADK TOOLS · AUTHORITY AT THE BOUNDARY
ADK application overview: check authority at the tool boundary
Let an agent propose six tool calls for a customer and see which ones a system instruction, a before-tool callback or per-tool checks actually stop.
Your experiment
Customer u-ana owns order o-1. The model proposes six calls: two legitimate ones on o-1, a read of someone else’s order, a refund the customer may not issue, a 300.00 refund to order o-7 planted by a note in o-1, and an export of every customer’s orders through a tool added in the last release. Find where each call is stopped.
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
The proposed calls are a fixed fixture: under the instruction-only setting the model declines the out-of-scope read and refund but follows the injected note and uses the new tool, which illustrates the risk without predicting any real model. The callback compares order ownership, scopes and amounts with the session principal before a tool runs. No model or order system is called.
Authority belongs to the tool boundary
An ADK agent turns model output into tool calls, so the model decides what to attempt, but something deterministic must decide what is allowed. Where authority is checked chooses nowhere, only the system instruction, a before-tool callback that inspects every call’s arguments before the tool runs, or a check written inside each tool using its ToolContext. Principal scopes is what the signed-in user may do, Injected note in order o-1 adds text that asks for a refund, and Tools exposed to the agent decides which tools the model can see.
The opening run: the instruction is not a control
With System instruction only, the legitimate read and address update on o-1 run, and the model declines the read of o-7 and the refund it may not issue. But the 300.00 refund to o-7, planted by the note in o-1, runs, and so does export_orders with scope=all from a tool added in the last release: 2 unauthorized actions. Untick Injected note in order o-1 and one remains, the export: the instruction never mentioned the new tool.
One callback, every tool
Set Where authority is checked to Before-tool callback: every call is compared with the session principal’s ownership and scopes before any tool runs, the injected refund and the export are denied, and nothing legitimate is blocked. Set it to Inside each tool: the same decisions for the three tools that have checks, but the new export tool shipped without one, so 1 unauthorized action runs. Set it to Nowhere and all 4 out-of-scope calls run. A central check covers tools that do not exist yet.
Failure boundary: scopes and least privilege
Change Principal scopes and the same callback gives different correct answers: a read-only customer is denied the address update, and a support principal may read o-7 and refund the 49.00 on o-1, but not the 300.00 injected refund, which exceeds its 100 limit. Set Tools exposed to the agent to Only tools the scopes could authorize: the refund tool disappears for a customer, so the injected refund cannot even be attempted, but the export still runs under the instruction-only setting. Least privilege shrinks the attack surface; it does not replace a per-call check.
Reading the run and its limits
Play replays the six proposed calls and the outcome over sixty inspection seconds; the table shows each call, the policy for this principal, what happened and whether it was right. Next event, Restart, Speed and Inspection time control the replay, and any input change recomputes it. The calls are a fixture, not a prediction of how a model behaves; a real deployment also needs authenticated principals, audit logs and confirmation for high-risk actions.