Agentic Application Risks
| Class | Inherent agentic-system behavior (goal hijack, tool misuse, memory and context poisoning, deceptive or rogue multi-agent behavior), mapped to the OWASP Top 10 for Agentic Applications |
| Status | Inherent to autonomous AI agents; not a remediable application defect on its own; out of scope as a vulnerability unless proven as part of a chain with a legitimate Open WebUI vulnerability per the Security Policy |
Summary
Open WebUI respects and appreciates the OWASP Top 10 for Agentic Applications; it is a valuable framework for reasoning about how autonomous, tool-using AI systems fail. Many of the behaviours it catalogues, however, are not classical security vulnerabilities. They are risks inherent to giving a language model agency, carried by any application that lets a model plan, use tools and act, rather than introduced by a defect in a particular vendor's code. These risks build directly on the model-level behaviour covered in LLM Output Unpredictability, and the two overlap heavily: an agent is a language model given tools and autonomy, so the same steerability that produces unsafe output can also drive unsafe actions.
Agentic systems plan, decide, call tools and carry context across steps, and they do so on the basis of untrusted natural-language input. Because of that, an agent can be steered by a crafted prompt, a poisoned document or web page, a deceptive tool output, or a message from a peer agent into pursuing a hijacked goal, misusing a tool it was granted, acting on poisoned memory, or persuading a human to approve something they should not. These are properties of how autonomous LLM agents work. They are not defects in Open WebUI's code.
What we mitigate
Open WebUI's role is to provide the platform and to control what an agent is allowed to do. Our meaningful controls are user-gated permissions, privilege limits, access control and isolation:
- Capability is gated, not granted by default. An agent can only act through Tools and Functions. Tool use is governed by the
workspace.toolspermission, which is disabled by default for non-administrators, and Function authoring is restricted to administrators. Granting either is documented as equivalent to giving that user shell access to the server (see the Security Policy, Rule 10). - An agent cannot exceed the calling user's own privileges. Acting on a user's behalf, it is bound by that user's role and RBAC permissions and by per-user data scoping; it cannot read or reach what the user could not.
- Isolation of execution. Server-side code execution is opt-in and administrator-configured, and for production the Terminals orchestrator runs execution in per-session, container-isolated environments with configurable security-context and resource policies.
- Operator guardrails. Filters, human-in-the-loop confirmation and content checks let a deployment add its own policy layer around what agents may do.
These controls bound the consequences of a steered or misbehaving agent. They do not, and cannot, make an autonomous agent's decisions reliably safe in every case.
What remains, and why it is not treated as a vulnerability
A risk whose entire impact is the agent behaving as agents inherently can (a hijacked goal, a poisoned memory, a tool used unsafely within the privileges it was already granted, a human persuaded by a confident agent) is inherent to autonomous agents and is not, on its own, an Open WebUI vulnerability. It is bounded by the state of the art in model and agent alignment, not by anything Open WebUI's code can patch.
We therefore do not accept reports as vulnerabilities when the whole impact is an agent being talked into misusing a capability it was already permitted to use, or producing undesirable output or actions within its granted scope. That is an accepted, inherent property of running an autonomous agent.
This is a scoping statement about agent behavior, not a blanket exemption. A report is in scope, and is treated as a real vulnerability, the moment crafted input crosses from "the agent was steered" into a concrete flaw in Open WebUI's own code or controls, for example:
- an agent action that escalates privilege, reaches another user's data or gains code execution through an Open WebUI code path rather than through a capability the operator granted;
- a bypass of an access-control, permission, or isolation check (for example a tool reaching data the calling user has no rights to); or
- any flaw where the agent is merely the trigger for an underlying application bug.
Those are Open WebUI defects and are fixed as such. The distinction mirrors the framework's own: an agent misusing a tool strictly within its granted privilege is inherent agentic risk, whereas privilege escalation or code execution through a platform flaw is a defect. See the Security Policy for the full reporting scope.
The test is where the defect lives, not who triggered it
The carve-out above turns on the tool's implementation, not on the agent's use of it. Stated plainly: if a tool does something we did not intend it to do, that is the bug, and the agent abusing it is not.
Read it in both directions.
- The tool behaves as designed and the agent puts it to a use we would rather it had not. That is agentic risk, and it stays out of scope however creative or expensive the outcome is. The tool did what it was built to do, and the absence of a limit on how often or how heavily an agent may use it is a configuration and hardening question rather than a defect.
- The tool itself does something we did not intend, such as a shipped built-in tool missing an access check, and an agent reaches data through it. The missing check is the vulnerability. The agent is only the trigger, exactly as in the third bullet above.
This is also why the carve-out is aimed at the tools Open WebUI ships: there, intended behavior is our intent and can be checked against our code. For a tool a user wrote or imported themselves there is no such thing as an unintended bypass, because the author defines what the tool does, and the permission to create or import tools is root-equivalent on its own.