A water utility agent has two tools: one that creates work orders with write access, and one that looks up billing history and is strictly read-only, both governed by Agent Identity. What does scoping these two tools to different permission levels within the same agent accomplish?
Select an answer to reveal the explanation.
Short Explanation
Think of it like giving two employees different keycards even though they're on the same team: one can open the supply closet and rearrange the shelves, the other can only look through the window. Scoping each tool separately means a manipulated call that misuses the billing-lookup tool still can't create a work order, because that tool never held write access. Per-tool scoping contains the damage a bad call can do - it isn't just a preference order.
Full Explanation
Per-tool permission scoping through Agent Identity means each tool carries its own grant rather than the agent inheriting one blanket permission set, so the billing-lookup tool's identity can be constrained to read-only operations while the work-order tool separately carries write access - and critically, a failure mode that causes the agent to misuse the billing-lookup tool still can't produce a write, because that capability was never granted to that tool's identity. This directly limits blast radius: the worst outcome from a compromised or malfunctioning read-only call is an unauthorized read, not an unauthorized change. Framing this as the agent preferring one tool over another misreads a permission boundary as a behavioral preference - which tool the agent chooses to call for a given task is an orchestration decision, separate from what each tool is authorized to do once called. Skipping authentication for a read-only tool ignores that read access to billing history is still sensitive customer data requiring authenticated, authorized access, not an unauthenticated shortcut. And sharing one OAuth token across both tools would undo the whole point of scoping them separately, since a token broad enough to cover both operations collapses the read/write boundary the design was built to enforce. The scope caveat: per-tool scoping only helps if the tools are genuinely implemented against separate grants rather than a single grant checked loosely inside application code. A concrete check: attempt a write call through the billing-lookup tool in a test environment and confirm the identity layer rejects it.