Tool use, also called function calling, is the mechanism by which a language model invokes external code. The model is given descriptions of available functions, decides which to call and with what arguments, and receives the result back as context. It is the primitive underneath every action an AI agent takes.
- The mechanism letting a model invoke external code and read the result
- The primitive underneath every agent action, and every agent-caused incident
- The model chooses the call and the arguments, from descriptions it is given
- This boundary is where AI security controls actually operate
Why are tool use and function calling important?
Tool use is the precise surface where AI security controls operate, which makes it the most consequential mechanism in agent security and the one least often described plainly. Every agent action – reading a record, writing to a database, sending a message, running code – is a tool call. An agent with no tools can only produce text.
That is why the boundary matters more than the model. Controls that inspect prompts and completions never see a tool call, because a tool invocation is not output in the sense a filter understands. An agent can be manipulated into a destructive action without a single objectionable sentence appearing anywhere in the transcript.
The second reason is that the model chooses. Given a set of tool descriptions, the model decides which function fits the goal and what arguments to pass. That decision is made from text the model was given, which means anyone who can influence a tool description or a tool result can influence the decision. It is the mechanism behind tool poisoning and much of indirect prompt injection.
What are tool use and function calling?
Tool use is a pattern in which a model is provided with structured descriptions of functions it may call, and its output can be a request to call one rather than text for a user. The application executes the function and returns the result, which the model then reasons over.
The cycle has four steps. The application supplies tool definitions – name, purpose, and parameters. The model, given a goal, emits a structured call naming a tool and its arguments. The application validates and executes it. The result returns as context and the model continues, often calling further tools.
Two details carry most of the security weight. The tool description is read by the model as guidance, so its wording shapes behavior. And the model generates the arguments, so a call can be well-formed and still wrong – a correct function invoked against the wrong record, or with a broader scope than the task required.
Function calling is the provider-level term for the same mechanism. MCP standardizes how tools are described and reached across applications rather than replacing the pattern.
Types of tool use
Tools divide by what they do to the world, which is the distinction that should drive policy.
Read tools retrieve information without changing anything. The risk is exposure – what the agent can see, and what it may pass onward.
Write tools change state in an external system. The risk is consequence, and it is the category where irreversibility lives: creating records, modifying data, deleting.
Execute tools run code, install packages, or invoke shells. These are the highest-consequence category, since they convert an agent's decision into arbitrary computation with the agent's permissions.
Communicate tools send messages outside the organization – mail, chat, tickets, API posts. The risk is both exfiltration and external visibility, since the output reaches someone who did not know an agent produced it.
Meta tools let an agent change its own configuration, permissions, or tool catalog, or spawn further agents. Rare, and the most consequential class when present.
Tool use & Onyx
The tool call is the boundary Onyx enforces at. Every invocation is evaluated before it executes, with policy able to allow it, block it, or steer it – modifying arguments, narrowing scope, redirecting to a safer target, masking sensitive elements in the result, or escalating to a person.
Inspection covers both directions. Tool calls are evaluated on the way out, and tool descriptions and results are evaluated on the way in, which is what catches a poisoned description steering the model before any call is made. For MCP-brokered tools the MCP Gateway is where that happens, and Just-in-Time access determines what a given call is permitted to reach rather than relying on a standing role. Action-class controls handle the categories where consequence concentrates, including destructive operations and package installation.
