Because a tool call can trigger a real action, every tool call request needs to be treated as untrusted input — validated and permission-checked before execution, exactly like any external input in traditional application security.
The Core Principle
The LLM's tool call request is a SUGGESTION, not a command.
Your application code is the actual authority that decides
whether to execute it — validating arguments, checking
permissions, and applying business logic constraints BEFORE
any real action happens.Validation Before Execution
def execute_tool_call(tool_call, current_user):
if tool_call.name == "cancel_order":
order_id = tool_call.arguments.get("order_id")
# Validate the argument itself
if not is_valid_order_id_format(order_id):
return {"error": "Invalid order ID format"}
# Validate PERMISSION — does this user actually own this order?
if not user_owns_order(current_user, order_id):
return {"error": "Not authorized to cancel this order"}
# Only now, actually execute
return cancel_order(order_id)Every one of these checks matters — skipping any of them means a manipulated or mistaken tool call request could act on the wrong data or on behalf of the wrong user.
Least Privilege
A tool should only be able to do what it's genuinely meant to do — a "get order status" tool shouldn't have the technical ability to modify or delete data, even if you trust the current prompt design not to misuse it. Limiting what's technically possible is a stronger safeguard than relying solely on prompting/instructions to prevent misuse.
Prompt Injection Risk Extends to Tool Calling
If a tool call's arguments are influenced by untrusted content (e.g. text from a retrieved document, or a webpage the model summarized), that content could theoretically attempt to manipulate what arguments get passed to a tool — see Prompt Injection. This is a real reason tool argument validation matters even when the immediate request seems to come from a trusted user.
High-Impact Actions Need Human Approval
For genuinely consequential actions (payments, deletions, sending communications on someone's behalf), requiring explicit human confirmation before execution — rather than fully automatic execution — is a critical, standard safeguard. See Human-in-the-Loop for the fuller pattern.
Common Mistakes
- Executing tool calls without validating both argument correctness AND user permissions
- Giving a single tool broader technical capability than the specific task actually requires
- Fully automating high-impact, hard-to-reverse actions (payments, deletions) without any human approval step
Interview Relevance
Q: "Should you always execute whatever tool call the model requests?" — no; every request needs validation and permission checking, treating the model's output as untrusted input, the same discipline applied to any external system input.
Practice Question
Design the validation checks needed before executing a send_refund tool call, including both argument validation and authorization.
