Open WebUI

Open WebUI is a multi-user service with real accounts and roles, and its built-in tools act on behalf of the requesting user: chat, memory, note and knowledge tools check ownership or access grants before touching data, and plugin tools are only loaded for users granted access. But the service itself holds every provider API key and connector credential, and plugin tools (admin-written Python) run inside the server process with all of that authority. The first account to register is an admin, and in the shipped Docker image the server runs as root.

Open WebUI has a per-call tool approval feature that pauses each tool call and shows the user the tool name and exact arguments with Allow/Deny buttons, and only the chat owner (or an admin) can resolve it. However it is off by default twice over: the admin must enable tool permissions, and then each user must switch the chat from 'full' to 'ask'. Scheduled automations and channel chats always run with full permissions, and the gate does not cover every path. In the shipped configuration every tool call, including deletes, runs without a human.

The built-in tools are mostly narrow, typed operations (create a calendar event, view one of your chats, add a memory) with ownership checks, and the URL fetcher has a strong SSRF defence: it rejects non-public addresses at connection time, blocks cloud metadata endpoints, and does not follow redirects by default. Plugin, OpenAPI and MCP tools get no shared validation layer. The default tool set includes write and delete tools for the user's notes, memories and calendar.

Model-written code never runs on the Open WebUI server by default: the code interpreter sends it to Pyodide (Python compiled to WebAssembly) in a web worker inside the user's own browser, and the optional Jupyter engine is an operator choice. That keeps the server host out of reach, but the worker has unrestricted network and its authority boundary is not strict.

Retrieved documents are wrapped in <context>/<source> tags in a prompt template, and tool results enter the conversation as ordinary tool messages; nothing in code limits what the model can do after reading untrusted text. In the default setup a hijacked model can read the user's chats, memories and knowledge, delete data with tools, and leak information through an exfiltration path. Tool approval, which would interpose a human, is off by default.

Memory is on by default and the model has tools to add, rewrite and delete memories with no validation or approval; saved memories are injected into the system message of later chats. Memories are stored per user and queries filter by user id, and users can view and delete them in settings. The model can also create scheduled automations (where permitted) whose stored prompts later run with full tool permissions.

Tools and Functions are Python source that Open WebUI exec()s directly inside the server process, with access to the app state, database and every stored credential. Only admins can add them by default (users need an explicit permission), and the code is shown in an editor when imported, but there is no signing or hash check, URL imports pull the head of a GitHub branch, and any 'requirements' line triggers an unpinned pip install into the server environment by default. MCP and OpenAPI tool servers are remote HTTP services whose tool lists are re-fetched without change detection.

Provider API keys and connector secrets live in plaintext in the configuration table, and plugin 'valve' secrets are only encrypted if an operator opts in; OAuth session tokens are encrypted. Telemetry is off by default and the Docker image disables library analytics. Redaction is minimal: the opt-in audit log masks only password fields and event webhooks drop secret-looking keys. Any in-process plugin tool can read the long-lived keys.

Every saved chat stores the model's tool calls, their arguments, results, and approval/rejection status in the database, tied to the chat owner, so most agent activity can be reconstructed. Temporary chats are not saved, the dedicated audit log is off by default, and users (or anything acting with their session) can edit or delete chats. Records are written during streaming rather than guaranteed before each action.

The only default bound is a cap of 256 tool-call iterations per response. Outbound HTTP calls to models and tool servers, and calls to the browser code interpreter, have no timeout by default, and there is no token or cost budget. Stopping a response cancels the asyncio task cooperatively, but scheduled automations keep running and sub-agents (opt-in) get their own fresh iteration budget.