loading…
How models request capabilities while deterministic code retains execution authority, permissions, and side-effect control.
A model does not directly call your database or send an email. It produces a structured request. The host application decides whether to execute that request, runs the tool, and returns the result to the model.
Tool names and descriptions should be specific, and arguments should use narrow schemas. Avoid a single universal tool such as run_any_sql or call_any_url. Prefer capability-shaped tools such as get_order_status and request_refund_review.
A good tool contract states what the tool does, what it does not do, required permissions, side effects, expected errors, and whether repeated calls are safe.
| Class | Examples | Control |
|---|---|---|
| Read | Search docs, fetch account status | Permission and data minimization |
| Reversible write | Create draft, add label | Validation, audit log, undo path |
| High-impact / irreversible | Transfer funds, delete data, deploy | Explicit approval, narrow scope, transaction controls |
Agents and distributed systems retry. A write tool should accept an idempotency key or otherwise detect duplicates so a timeout does not create two tickets or charge twice. Return machine-readable error classes: retryable, validation, authorization, not found, conflict, or permanent failure.
Code execution should run in an isolated environment with resource limits, network policy, temporary credentials, and a disposable filesystem. Treat generated code as untrusted input even when the model wrote it for a legitimate task.
Giving the model a shell with ambient production credentials turns a reasoning error or prompt injection into a security incident.
Tool outputs can be stale, malformed, or malicious. Validate the response shape and label its source. A webpage or issue description returned by a tool may contain indirect prompt injection and must not gain instruction authority merely because it arrived through a tool.