An assistant that writes a suggestion and an assistant that changes a production record have very different consequences. Giving a model a tool connects its output to an operation. That connection deserves an explicit security decision.
Read the implementation, not just the name
A hypothetical tool called update_note sounds narrow. Its real capability depends on what the server accepts. Can the caller choose any workspace? Can it change an owner? Does the server check the current user’s access to the note?
A short tool description can help a model select a function. It does not replace enforcement in the function’s implementation.
Ask whose authority is being used
In a fictional team assistant, a user asks for a summary of their own notes. The assistant’s server credential may technically have access to every workspace. That credential should not silently turn the user’s request into permission to access everything the server can reach.
The MCP security guidance discusses authorization threats including the confused deputy problem and token passthrough. It emphasizes validating intended token audiences rather than accepting tokens merely because another service would accept them. MCP Security Best Practices.
For the notes example, document the end-user identity, the service identity, the requested resource, and the policy that connects them.
Make the operation concrete
Compare these hypothetical interfaces:
run_arbitrary_command(command)
read_note(workspace_id, note_id)The second interface is easier to reason about, but its name alone guarantees nothing. It still needs input validation, authorization, and appropriate failure behavior.
If an action requires approval, show the exact destination and change. A generic “allow this tool” prompt leaves the user to guess what they are authorizing.
Test a rejected action
Build a local fixture in which the assistant proposes reading a note outside the user’s workspace. The tool should reject the request even when the parameters are well formed.
Record the model proposal and tool decision separately. The model may propose an unsafe operation while the application correctly refuses it. Conversely, a sensible model response can hide an overpowered tool that simply was not exercised in that run.
That is why permission checks belong in the system that performs the action. Explore this idea in the trust-boundary lab.