Function calling does not give a model direct control of a system. The model proposes a tool name and arguments. Application code remains responsible for validation, authorization, execution, and audit records.
The loop contains two model requests
For a read-only get_order_status tool, the application sends the question and tool schema. The model returns a proposed call. The application validates the name, arguments, user access, and rate limit, then executes the query. Its structured result is sent back as a tool message so the model can produce the final response.
A schema constrains shape but does not prove authorization. A model may still produce an unknown tool, extra fields, or an order ID owned by another user. Route calls through an explicit allowlist and check resource ownership against the authenticated identity.
Never resolve a model-provided name through globals() or interpolate its text into a shell command. Each tool needs a fixed argument model, timeout, error policy, and redacted log path.
State-changing tools require approval
Deleting data, restoring a backup, restarting a service, and sending a message change external state. Show the exact target, environment, action, and expected effect before requesting confirmation. “The model decided it was necessary” is not authorization.
Tool results also need validation. A service may time out, return an empty payload, or violate the expected schema. Preserve source and observation time, but do not send credentials, internal stack traces, or database connection details back to the model.
Test the failures
Exercise valid arguments, missing fields, unauthorized resources, unknown tools, timeouts, and rejected approvals. The application should stop at the correct stage in every case. If creative model output can bypass the allowlist or permission check, the implementation is not ready.