Use tools with a permission boundary

Some local models can request tools.

You describe a function and its parameters. The model may return a tool call instead of a final answer. Your application decides whether to execute it.

That last sentence is the security boundary.

The model does not gain permission because it produced valid JSON. Validate the tool name and arguments, authorize the operation for the current user, apply limits, and ask for confirmation before an irreversible action.

A safe loop looks like this:

model proposes call
       |
       v
validate -> authorize -> confirm if needed -> execute
       |
       v
return narrow result to model

Start with read-only tools. A function that returns today’s activity is easier to contain than one that deletes files or sends messages. Expand scope only after logging and tests cover the narrow case.

Tool output is also untrusted data. A document or web result cannot grant itself new permissions by telling the model to ignore your rules. Sanitize strings before you pass them back into the prompt or store them.

My advice is to keep an allow-list of tool names in code. Unknown names fail closed. Arguments should validate against a schema the same way model output does.

When you add Ollama tool calling to a local agent, mirror the server pattern you would use for a cloud agent. Local weights do not make the model trustworthy. They only keep the inference on your machine.

Reject unknown tools in code:

const allowed = new Set(['get_today_activity'])

if (!allowed.has(toolCall.name)) {
  throw new Error(`Blocked tool: ${toolCall.name}`)
}

You should see blocked names in logs long before a dangerous handler exists.

Try this on your own project: implement one read-only tool and log every proposed call without executing it for a day. You will learn how often the model reaches for tools you did not expect.