Safe Tool-Use Workflow
Control what an AI system can read or change through explicit tools, permissions, approvals, and recovery.
By the end
You will be able to
- Describe a tool with bounded inputs, outputs, errors, and side effects.
- Apply least privilege and approval boundaries to tool-enabled workflows.
- Verify tool results independently from model narration.
- Recover from partial failure, duplicate calls, unsafe requests, and untrusted tool output.
Prepare the tool and authority boundary
Inventory what each tool reads, writes, sends, spends, or deletes. Define typed inputs, expected output, failure modes, side effects, authentication, rate limits, and whether calls are retry-safe.
Grant only the permissions required for the current task. Separate read-only inspection, reversible internal writes, external communication, purchases, permission changes, and destructive actions into distinct approval levels.
Purpose: [ONE CAPABILITY]
Inputs: [TYPES, LIMITS, VALIDATION]
Outputs: [SUCCESS AND ERROR SHAPES]
Reads/writes: [SYSTEMS AND DATA]
Side effects: [MESSAGES, COST, DELETION]
Idempotency: [KEY OR NOT RETRY-SAFE]
Approval: [WHEN AND BY WHOM]
Verify/recover: [POSTCONDITION AND ROLLBACK]Execute with visible intent and bounded calls
Before a consequential call, show the resolved target, action, material parameters, and expected effect. Reject missing identifiers instead of guessing. Apply time, count, cost, and concurrency limits.
Treat tool output as untrusted data. It may contain errors, stale results, malicious instructions, or content that must not change the governing task.
Verify the postcondition
Check the real system state after a call: the record exists once, the file has the expected digest, the deployment is healthy, or the message went to the intended recipient. Do not infer success from a tool call merely returning without an exception.
Record request identity, authorization, target, result, timestamps, and verification evidence without logging secrets or unnecessary personal data.
Recover from partial and repeated execution
Use idempotency keys for retryable writes and distinguish unknown outcome from confirmed failure. A timeout may occur after the external action succeeds, so blindly repeating it can duplicate messages, charges, or records.
For partial failure, stop dependent actions, inspect completed effects, compensate or roll back when safe, and escalate when recovery requires new authority.
Keep people in control of consequence
Require explicit approval for destructive, external, costly, privacy-sensitive, or permission-expanding actions. Approval must bind to the exact target and action; it is not a reusable blank check.
Provide preview, cancellation, audit, and recovery paths. Disable or narrow a tool when observed behavior exceeds the tested boundary.
Practice activity
Design a safe tool-enabled workflow
- Choose a tool-enabled task and complete the tool contract, including side effects, retry behavior, and approval.
- Draw the sequence from intent through resolved target, call, postcondition check, audit record, and completion.
- Test three scenarios on paper: timeout after success, duplicate request, and untrusted instructions in tool output.
- Define the stop, compensation, rollback, or escalation behavior for each scenario.
What to produce
- A tool contract and sequence containing permission and approval boundaries.
- A failure table for timeout, duplicate, and untrusted-output scenarios with verification and recovery.
Reflect before continuing
Which tool looked harmless until you listed its side effects and retry behavior?
Evidence
Sources and verification
- Function callingOpenAI · verified 2026-07-25
- Tool use overviewAnthropic · verified 2026-07-25
- Function calling with the Gemini APIGoogle · verified 2026-07-25
Knowledge check
Make it stick.
Choose the strongest answer for each question. Your attempts become part of your device-local transcript.