Designing and Securing Tools

Narrow, validated, least privilege

The model chooses tools by their name, description and schema, so write them like documentation for a reader who knows nothing else: one clear job per tool, say when to use it, constrain arguments (enums, patterns, ranges), return concise results and clear error messages. Then secure them: the model's arguments are untrusted input, so validate them in code; enforce per-user permissions inside the tool, not in the prompt; give tools least privilege (read-only by default, scoped credentials, allow-listed hosts and folders); require human approval for irreversible or costly actions (payments, deletions, external emails); treat tool output as data, not instructions (it may contain injected text); set step, time and cost limits; and log every call.

Put permissions in the tool

A prompt saying "only show the user's own orders" can be argued around. A tool that takes the authenticated user id from your server and filters by it cannot.

Quick check: Where should "only this user's data" be enforced?

• Nowhere
• Only in the system prompt
• Only in the model's memory
• In the tool code, using the authenticated user id