Designing Safe Tool-Using Workflows with Claude

Tool use changes Claude from a system that proposes text into one that can request data or actions. That power should be designed as a typed, permissioned interface. According to Anthropic's official explanation of how tool use works, Claude emits a structured request; client code executes user-defined tools and returns the result. The application—not the model—owns authorization and side effects.

Start With the Smallest Tool Set

Give the model only the operations needed for the current workflow. Prefer narrow tools such as get_order_status(order_id) over a general database query tool. Separate reads from writes and low-risk actions from consequential ones.

Every tool should have a clear name, precise description, strict input schema, bounded output, timeout, and documented error behavior. Avoid overlapping tools whose descriptions make selection ambiguous.

Validate Everything in Application Code

Treat model-generated arguments as untrusted input. Validate type, format, length, range, tenant, resource ownership, and business rules. Resolve the authenticated user outside the prompt; never accept an arbitrary user ID because the model supplied it.

For a refund tool, application code should check order ownership, refund eligibility, amount limit, currency, duplicate status, and actor permission. A prompt saying “only issue valid refunds” is not an authorization control.

Add Approval Based on Consequence

Use automatic execution only for low-risk, reversible operations. Require a human confirmation screen for sending messages, changing access, moving money, deleting data, publishing content, or modifying production.

The approval should show the exact action, target, arguments, source evidence, and expected effect. “Allow Claude to continue?” is not meaningful consent.

Defend Against Untrusted Content

Web pages, emails, tickets, and documents may contain instructions designed to redirect the agent. Treat retrieved content as data, not policy. Keep system rules and tool authorization separate from external text. Allowlist network destinations and sanitize files before processing.

Do not return secrets in tool results. Minimize customer data and isolate tenants throughout retrieval, caching, logs, and execution.

Run a Controlled Agentic Loop

Handle every tool call ID, result, error, and stop reason. Set limits for iterations, elapsed time, cost, and repeated calls. Detect cycles such as alternating searches that never improve the answer. Return structured errors so Claude can recover or escalate instead of inventing a successful result.

Use idempotency keys for side effects. A retry after a timeout must not create a second invoice or duplicate email.

Log for Investigation

Record authenticated actor, model and prompt version, tool name, validated arguments with sensitive fields redacted, approval identity, result status, latency, and correlation ID. Preserve enough evidence to reconstruct an incident without storing unnecessary private content.

Alert on unusual tool frequency, repeated permission failures, large transactions, new destinations, and rising human override rates.

Test Adversarial Cases

Your evaluation set should include malformed arguments, unauthorized resources, prompt injection in retrieved content, conflicting tool results, partial outages, timeouts, stale data, duplicate actions, and attempts to bypass approval. Test both model behavior and application enforcement.

Run in read-only or shadow mode before enabling writes. Release to a limited cohort and define a kill switch and rollback procedure.

Define the Boundary of Responsibility

Claude can select a tool and construct proposed arguments. The application authenticates, authorizes, validates, executes, and audits. A human or deterministic policy approves consequential actions. The business owner defines acceptable outcomes and handles remediation.

Safe tool use is not achieved by a stronger model alone. It comes from conventional security engineering wrapped around a probabilistic planner.

Review Tool Outputs as Carefully as Inputs

A tool may return stale, partial, or malicious content. Validate status, timestamp, provenance, tenant, and expected shape before feeding a result back to Claude. Distinguish “no record found” from “the service failed,” because converting both into an empty result can produce a false business conclusion.

Large results should be bounded and paginated. Do not return an entire customer database when one record is required. If output contains URLs, executable content, or user-supplied text, preserve its untrusted classification through the rest of the loop.

Create a threat model for each tool: assets, actors, entry points, side effects, likely abuse, detection, and recovery. Review it whenever scopes, endpoints, or supported actions change. A safe read tool can become consequential when a later release adds export or sharing.