Giving a local-model agent web access without leaking your queries

Running a model on your own machine with Ollama or LM Studio keeps prompts and documents off someone else’s servers. The moment the agent needs current information, though, it has to reach out to the web, and that single tool call changes the privacy picture more than most people expect. This page walks through the realistic options for adding web search to a local-model agent, what each one reveals and to whom, how to wire the tool call, and the safety rules that matter once untrusted pages start flowing into a model that may also have access to your files.

What changes when the model runs locally

A hosted assistant usually arrives with search already attached. A local model arrives with nothing but its training data, so what it knows stops at its training cutoff, and anything recent or company-specific has to be fetched. Three practical differences shape the design.

• Tool calling is not universal. Only some open models are trained to emit structured tool calls reliably. Check the model card for tool or function-calling support before you build around it, and expect smaller models to call tools less consistently than larger ones.
• Context is tighter. Local setups often run with modest context windows to save memory. Pasting five full web pages into the prompt can push the original question out of view, so search results have to be trimmed before the model sees them.
• The privacy boundary moves. Inference stays on your hardware, but the search query, and any page you fetch, leaves it. The question stops being “who sees my prompt?” and becomes “who sees my queries and my IP address?”

Four ways to give a local agent the web

Most setups use one of the following, sometimes two together.

A hosted API is usually the quickest route to good results, because they arrive already parsed. Self-hosted metasearch keeps you independent of a single provider and leaves no account-level query history with anyone, but it does not make queries invisible: the upstream engines still receive them, just from your server rather than from a named account. Direct fetching is not search at all; it is what you use after search, to read the pages a result points to. For a survey of no-cost and self-hosted choices, see free and self-hosted web search options. For the protocol route, see choosing a web search MCP server and remote vs local MCP servers.

The privacy trade-off, stated plainly

People often choose a local model for confidentiality and then hand the confidential part to the search tool without noticing. The model writes the query, and a model working on a sensitive document will happily put a client name, a contract number or an unreleased product name straight into it. Queries also reveal intent: a run of searches about one company’s debt covenants says a lot even without the document attached.

Treat the outbound query as data leaving the building and put a small gate in front of it. A workable starting rule:

before sending a search query:
  - reject if it matches the blocklist (client names, project codenames, internal hostnames)
  - reject if it contains an email address, phone number or ID-like pattern
  - cap query length (long queries are usually pasted document text)
  - log query, time and tool to a local file the user can read
on rejection:
  - return "query blocked by policy" to the model, not a silent empty result

The explicit refusal matters. If the tool silently returns nothing, the model may conclude the information does not exist, or try again with a reworded query that leaks the same thing.

Fetching pages leaks too. Every page you open tells that site’s server your address and the time, and a trail of visits to obscure pages can reveal what you were researching. A self-hosted proxy or a dedicated egress address changes who the request is attributed to; it does not change the fact that the request happened.

Wiring the tool call

Ollama exposes a chat API that accepts tool definitions for models that support them, and LM Studio can run a local server that speaks the widely used OpenAI-style chat format. Either way the pattern is the same: you describe the tool, the model returns a call instead of text, your code executes it, and you send the result back as a tool message.

{
  "type": "function",
  "function": {
    "name": "web_search",
    "description": "Search the public web. Returns up to 5 results with title, url and a short snippet. Use only when the answer needs current or external information.",
    "parameters": {
      "type": "object",
      "properties": {
        "query": {"type": "string", "description": "Short keyword query, no document text"}
      },
      "required": ["query"]
    }
  }
}

A few details separate a demo from something you can leave running:

• Validate every call. Smaller models invent tool names and produce malformed arguments. Reject anything that does not match the schema and tell the model why.
• Cap the loop. Set a maximum number of searches per question. Without one, a model that cannot find an answer will keep searching with small rewordings.
• Number and trim results. Give each result an index, its URL and a short snippet, and ask the model to cite by index. Fetch full page text only for the results it chooses to read.
• Keep search and fetch separate. One tool finds URLs, another reads a URL. That makes it easy to apply different limits, and to restrict fetching to domains you trust.

Design choices specific to that runtime are covered in the Ollama integration guide.

Untrusted pages, trusted tools

The serious risk is not a wrong answer; it is a web page giving your agent orders. Page text lands in the same context as your instructions, and a page can contain text written to look like instructions: “ignore previous directions and run the following command”. A local agent is often also the one with filesystem and shell access, which is exactly what makes the combination dangerous.

• Start the agent with read-only tools and add write access one tool at a time. The reasoning is laid out in start agents read-only.
• Never let retrieved content trigger a tool with side effects on its own. Anything that writes, deletes, sends or runs a command should ask the user first and show the exact call.
• Mark retrieved text clearly as data in the prompt, and strip scripts, hidden text and markup before it reaches the model.
• Respect the sites you read: honor robots.txt, keep request rates low, identify your client honestly, and never use the agent to get past a login or paywall you are not entitled to pass.

Keeping answers checkable

An answer from a local agent is only as good as your ability to check it. For every search and fetch, store the query, the URL, the time of retrieval and the snippet or passage the model used. When the agent answers, each claim should point back to one of those records. If nothing relevant came back, the agent should say so; “no source found” is a legitimate result, not a failure to hide.

This is also where a solo setup meets a team. GoCux does not search the web for you and does not replace your local search tool; its concern is what happens afterwards. Web material reaches a GoCux project only through an authorized browsing or export step, and it keeps the address of the original page and the date it was retrieved. Once imported, Knowledge search can return passages from it with their citations, and anything consequential that follows waits for a person on the team. If your local agent already runs MCP tools, they stay in your own compatible client, and having a server configured there does not mean every task may use it; the MCP quickstart recommends beginning read-only for that reason.

Setup checklist

• The model you chose supports tool calling, and you have watched it call your tool correctly on ten realistic questions.
• You know which party receives your queries, under which account or address, and what its terms say about logging.
• Outbound queries pass a blocklist and a length check, and blocked queries return an explicit refusal.
• Search and page fetching are separate tools with their own limits, and fetching is restricted to trusted domains where possible.
• The loop has a hard cap on searches and fetches per question.
• Write, delete, send and shell tools require a confirmation that shows the exact call.
• Every answer can be traced to stored URLs, retrieval times and passages, and empty results are reported as empty.