LLM 0.32's Server-Side Tools Widen the Prompt-Injection Attack Surface
Simon Willison's LLM CLI ships reasoning traces, OpenAI Responses support, and provider-hosted tool execution in one release — the tool-calling changes are the ones security teams should read closely.
Key Takeaways
- LLM 0.32, released by Simon Willison, adds visible reasoning traces, a redesigned content-addressable SQLite log store, and **server-side provider tools** — OpenAI's CodeInterpreter and WebSearch, plus Anthropic's WebSearch, WebFetch, CodeExecution, and AnthropicMCP via the companion llm-anthropic 0.26 plugin.
- "Server-side" means the model calls the tool on the provider's own infrastructure rather than through your client code — which is convenient, but it removes the local hook many teams rely on to inspect, filter, or block a tool call before it runs.
- Two of the new tools (WebFetch and AnthropicMCP) let a model pull external content or invoke arbitrary MCP servers directly — exactly the kind of untrusted-input-to-tool-call path that prompt injection exploits.
- None of this is a disclosed vulnerability in LLM itself; it's an architecture shift that expands what an agentic setup can do, so the risk assessment belongs on whoever wires these tools into a workflow with write access or secrets.
What shipped
Simon Willison, creator of the llm CLI and Python library, released version 0.32 on 4 August, calling it "the most significant new version of LLM since the initial launch of the project." The release adds visible reasoning traces (piped to standard error so they don't pollute stdout, with a new -R/--hide-reasoning flag to suppress them), out-of-the-box support for the GPT-5.6 model family — with the lightweight GPT-5.6 Luna now the default model — a new llm openai endpoint command for hitting arbitrary OpenAI-compatible endpoints without logging, and a rebuilt SQLite log store that addresses messages by content hash instead of duplicating JSON per conversation turn. A companion release, llm-anthropic 0.26, adds support for the Claude 5 model family.
The part worth a second look: server-side tools
The headline feature for security teams is server-side provider tools. Instead of llm defining a local Python function the model can call, OpenAI and Anthropic now run certain tools on their own infrastructure and hand results straight back into the conversation. LLM 0.32 exposes OpenAI's CodeInterpreter (llm --tool CodeInterpreter) and WebSearch; llm-anthropic 0.26 adds Anthropic's own WebSearch, WebFetch, CodeExecution, and — notably — AnthropicMCP, which lets the model invoke Model Context Protocol servers directly.
This is a genuine usability win, but it changes the shape of the attack surface. A tool call that used to route through code you wrote — and could log, rate-limit, or reject — now happens inside the provider's runtime. If a WebSearch or WebFetch result contains adversarial instructions (a classic prompt-injection payload embedded in a web page or search snippet), that content flows back into the model's context with less opportunity for the calling application to sanitise or gate it first. Handing a model direct MCP invocation compounds this: MCP servers frequently expose file, shell, or API access, so an injected instruction that reaches AnthropicMCP has a shorter path to real-world effect than one that has to pass through an application's own tool-dispatch layer.
What to check before enabling these
- Treat any content returned by WebSearch/WebFetch as untrusted input, not as trusted context — the same discipline you'd apply to user-supplied text.
- Audit which MCP servers are reachable via AnthropicMCP in your deployment; a model that can reach a write-capable or secret-holding MCP server inherits whatever that server can do.
- Confirm your logging captures server-side tool invocations and their inputs/outputs, not just the final model response — the new content-addressable SQLite store is a good place to check this lands correctly.
- Scope API keys and CodeInterpreter/CodeExecution environments as if they were internet-facing, since a WebFetch call can be steered by page content the model reads.
Bottom line
None of this is a disclosed flaw in LLM or in OpenAI's or Anthropic's tool implementations — it's a legitimate feature that more vendors are converging on. But every time tool execution moves further from application code and closer to the model itself, the injection-to-action chain gets shorter. Teams adopting llm 0.32's server-side tools, or the equivalent features directly from OpenAI's Responses API or Anthropic's Claude 5 tool APIs, should scope and log those tools with the same rigor they'd apply to any new internet-facing capability.
Frequently Asked Questions
What does "server-side tool" mean in LLM 0.32?
It means the tool (e.g. OpenAI's CodeInterpreter or WebSearch, Anthropic's WebFetch or AnthropicMCP) runs on the AI provider's own infrastructure rather than being implemented and called by your local application code. The model requests it and the provider executes it, returning results into the conversation.
Is this a new vulnerability in LLM or llm-anthropic?
No CVE or disclosed vulnerability is associated with this release. The security consideration is architectural: server-side tools reduce the application's visibility into and control over tool execution, which raises the stakes of existing prompt-injection risk rather than introducing a new bug.
What should a team do before turning on AnthropicMCP or WebFetch in production?
Inventory which MCP servers or fetch targets are reachable, scope their permissions as if they were exposed to untrusted input, and confirm tool calls are logged — the same due diligence PyramidLedger applies when red-teaming agentic AI deployments.
Sources
- 1New release of LLM adds support for reasoning traces, OpenAI Responses, server-side tools, and smarter logging — Simon Willison
- 2LLM: Access large language models from the command-line — Datasette / Simon Willison