Tool Calling with Least Privilege

Tool calling lets a model propose a typed operation; trusted application code decides whether and how to execute it. Every tool needs a narrow purpose, minimal arguments, server-bound identity, schema validation, resource authorization, idempotency, time and effect limits, approval policy, and an audit trail. A tool description is not a security control.

What will you be able to do?

• distinguish read, draft, reversible, and consequential tools;
• keep identity and tenant out of model-controlled arguments;
• validate a proposed call before execution;
• require approval and prevent duplicate effects.

What makes a safe tool contract?

Instead of run_sql(query) or call_api(url, body), define intent:

ToolContext is constructed by the server and never exposed as model arguments. The executor loads the ticket within the tenant, evaluates permission, checks run budget, validates state, and returns a bounded result.

How should tools be classified?

The approval record binds the exact normalized arguments, resource version, actor, policy version, expiry, and idempotency key. Changing arguments invalidates approval.

How do you execute safely?

1. Accept the model proposal as untrusted data.
2. Validate name and typed arguments against the allowed registry.
3. Bind trusted context from the current run.
4. Re-load resources and current authorization.
5. Enforce call count, time, data, and monetary budgets.
6. Require approval where policy says so.
7. Execute with idempotency and timeout.
8. Validate and minimize the result before returning it to the model.
9. Record proposal, policy decision, effect ID, and outcome.

Why does this matter in AI-native systems?

Tools turn text errors into real-world effects. Indirect prompt injection in a document can attempt to call a tool; server policy must make the attempt harmless. Sandboxing code is useful but does not grant it permission to access customer data or networks.

Common mistakes

• Tool arguments include is_admin, tenant, price, or permission scope.
• Broad tools expose arbitrary SQL, filesystem paths, URLs, or shell commands.
• Approval UI displays a friendly summary but binds different hidden arguments.
• Tool results return unlimited private data to the model.
• Retry repeats a charge, email, or refund.
• The model can recursively call tools without a step budget.

AI Pair-Programmer Prompt

Exercise

Design draft_reply, assign_ticket, and issue_refund tools. Only the first may run without confirmation; refund requires exact approval.

Acceptance criteria: tests prove model-supplied tenant/admin fields are rejected, wrong-tenant IDs disclose nothing, modified refund arguments invalidate approval, and duplicate execution produces one effect.

Knowledge check

1. Who establishes tool identity and tenant?
2. Why bind approval to normalized arguments?
3. Is a system prompt a tool permission boundary?

---

Answers

1. Trusted server context.
2. So a different action cannot reuse the approval.
3. No; executable server policy is the boundary.

Completion checklist

• Tools are narrow and typed.
• Consequential effects require bound approval.
• Duplicate and injected calls are harmless.

Primary references

• OWASP LLM Excessive Agency
• OWASP SSRF Prevention