Connect a model to one tool
Read the function-calling guide, then trace how a tool request moves through the application that executes it.
Start with: Function calling
RedLectern topic
Tool calling · APIs · action validation · permissions · human review · bounded automation.
For: Developers · workflow builders
After this page you can: Connect a model to a tool with explicit action controls.
Page reviewed
Part of: Artificial Intelligence › AI agents
Tool use lets a model request an operation from software, such as retrieving information or changing a record. In a function-calling flow, the model supplies a tool name and arguments; the application hosting the model decides what to execute, runs it, and can return the result to the model. The request is not the action itself. OpenAI’s function-calling guide, checked 2026-10-09, describes this application-mediated flow.
Start with one narrow operation and define its inputs. Check that the request matches the expected shape, then check the user’s authorization and the application’s rules before calling an API. A correctly shaped request can still be unauthorized. For actions with meaningful effects, add a human approval step. OWASP recommends limiting available extensions, their functions and permissions, and requiring approval for high-impact actions. Set out which operations are available, what each is allowed to change, and when the workflow must stop for review.
Read the function-calling guide, then trace how a tool request moves through the application that executes it.
Start with: Function calling
Use OWASP’s excessive-agency guidance to review permissions, function scope, and approval points.
Start with: LLM06:2025 Excessive Agency
A tool call is a structured request from a model to the application hosting it. It names an operation and supplies arguments; application code decides whether to run it, executes the operation, and can return the result to the model. OpenAI’s function-calling guide, checked 2026-10-09, describes this application-mediated flow. Schemas can constrain the expected shape of arguments, but they do not decide whether an action is authorized. Keep tool descriptions specific, expose only the operations needed for the task, and make any approval step part of the application’s action path.
Recommendations for limiting tool scope and requiring human approval.
Tool calling
A model requests a software operation with structured arguments for a host to execute.
Human in the loop
A workflow assigning a person a review or decision step.
Least privilege
Granting only the access necessary for an operation.
Sandbox
An isolated execution environment intended to limit permitted actions.
A model requests `send_email` with a recipient and message. What should the host check before sending, and what result should it return to the model?
Check the arguments and the user’s permission for that recipient, then apply the workflow’s approval policy. If approved, call the email API and return its result or a clear error.
Validation has more than one job. First check that the requested operation exists and its arguments meet the expected schema. Then check the action against application rules and the user’s authorization before calling a downstream API. OWASP advises enforcing authorization in downstream systems and validating requests against security policies, instead of relying on the model to decide whether an action is allowed. Its excessive-agency guidance recommends using only necessary functions and preferring granular functions to open-ended extensions. Treat each model output as a request to inspect: a well-formed request still needs policy checks.
Documentation on tool schemas and how an application handles function calls.
A request passes the argument schema for `delete_record`. Name two further checks the host should make before executing it.
Check that the authenticated user may delete that specific record, then apply the application’s approval policy for deletion before calling the API.
Bound automation by limiting the tools, functions, and permissions available to it. OWASP recommends minimizing extension functionality and permissions, and using human approval for high-impact actions. A sandbox is a controlled environment that restricts access to resources the software is not authorized to use. Choose its boundaries for the task, and keep a person in the review path for actions with meaningful effects. Set a clear stopping condition for work that exceeds the workflow’s scope. These controls make the permitted actions and escalation path visible to the people responsible for the workflow.
NIST glossary definitions describe controlled execution environments with restricted resource access.
NIST glossary definitions describe restricting access privileges to what assigned tasks require.
A workflow can read project records and archive them. Propose one tool limit, one permission limit, and one review point.
Expose separate read and archive operations; grant read access by default and archive permission only when needed; require a person to approve each archive action.
No recent updates are available.
Chip Huyen · 2025
A durable framework for building foundation-model applications and evaluating agents. Check current provider documentation for changing tool-call details.
John J. Geewax · 2021
Shows how API patterns can make actions more predictable, including request validation and duplicate-request handling. It covers API design rather than LLM tool calling.
Paul Iusztin and Maxime Labonne · 2024
A production-oriented LLM application walkthrough that connects architecture, tooling, and workflows. Its examples are tied to a particular stack, so check current documentation for version-specific details.