The tool-call security playbook

Every function your agent can call is a privilege. Every argument it can pass is a parameter to that privilege. When a framework hands you an 'easy' way to expose 40 tools to an LLM in one decorator, what it's really offering you is a 40-element attack surface. Here's the checklist I wish more teams had before their first incident.

First: inventory. Write down every tool, who can invoke it, what it returns, and what side effects it has. If any of those four facts aren't obvious to a new hire in 30 seconds, you have a documentation problem that's masking an access-control problem.

Second: scope each tool. Tool = verb + object. 'read_file' is not a tool. 'read_file_from_workspace_foo_owned_by_user_bar' is a tool. Fold the authorization context into the tool signature, not into runtime branches that the LLM might route around.

Third: bound every fan-out. If a tool can operate on 'all users' or 'every row', it will eventually be invoked to operate on all of them. Cap recipient lists, result sets, and row counts at the tool level — not at the prompt level.

Fourth: require human-in-the-loop for destructive actions. Delete, wire, publish, email-to-external — these should prompt an out-of-band confirmation. Yes, it adds latency. It also prevents the single incident that ends your category.

Fifth: rate-limit per tool, per user, per session. Token-bucket on three dimensions. Report the rates to your observability layer — unusual rate patterns are a precursor signal.

Sixth: validate arguments deterministically. Don't trust the LLM to produce valid JSON. Don't trust it to stay within your enum. Validate and reject — loudly — with rich error signals the agent can actually recover from.

The remaining six — argument-length caps, recursive-call depth limits, return-value sanitization, timing-attack protection, allow-list domains for network tools, and audit logging of every invocation — are table stakes for production.