Add Agentic Application Risks page; expand accepted-risks and roles

Adds an Agentic Application Risks accepted-risk page for the OWASP Top 10 for Agentic Applications, framed like the LLM Output Unpredictability page: the catalogued behaviours are risks inherent to autonomous, tool-using systems rather than classical vulnerabilities, bounded by gated permissions, per-user privilege limits and isolated execution, and in scope only when chained with a concrete platform flaw. Cross-links it with the LLM page. Also expands the authentication timing page (GHSA link, fix summary, and the accepted residual bounded by physical and runtime limits), adds an OWASP LLM Top 10 acknowledgement to the LLM page summary, and documents the primary administrator, what it is and how to swap it generically, on the Roles page.

Author: Classic298

docs/features/authentication-access/rbac/roles.md

@@ -66,6 +66,20 @@ Administrators can change a user's role at any time via **Admin Panel > Users**.
 *   Promoting a user to `admin` grants them full control.
 *   Demoting an admin to `user` subjects them to the permission system again.
 
+## The Primary Administrator
+
+The first account created on an instance (see [Initial Setup](#initial-setup)) is the **primary administrator**. There is no special flag for it: internally it is simply the earliest-created account, determined by its creation timestamp.
+
+The primary administrator has one small piece of extra protection. The interface does not show a delete control for it, and the backend refuses to delete it through the user API. This exists purely to prevent the original bootstrap account from being removed by accident, which could otherwise leave an instance without its founding administrator or trigger an unwanted role reassignment.
+
+This is a convenience safeguard, not a security boundary. All administrators share full control of the system, so any administrator can still change or remove any account, including the primary one, at the data layer.
+
+### Swapping the Primary Administrator
+
+Sometimes the primary administrator legitimately needs to change, for example when the person who first set up the deployment leaves the organization. Because the role is decided purely by creation timestamp, the primary administrator is whichever administrator account is oldest, so reorganizing or removing accounts at the database level changes which one is treated as primary.
+
+This is deliberately a data-layer operation rather than a one-click button, so that changing the founding account stays an intentional, considered action. Back up your database before making the change, and perform it while the instance is idle. We do not list exact queries here because the database schema evolves between releases; work against your current schema, and reach out on our community channels if you need guidance for your version.
+
 ## Headless Admin Account Creation
 
 For **automated deployments** (Docker, Kubernetes, cloud platforms) where manual interaction is impractical, Open WebUI supports creating an admin account automatically on first startup using environment variables.

docs/security/accepted-risks/agentic-application-risks.mdx

@@ -0,0 +1,50 @@
+---
+title: "Agentic Application Risks"
+---
+
+# 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](../security-policy) |
+
+---
+
+## Summary
+
+Open WebUI respects and appreciates the [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/); 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](./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.tools` permission, 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](../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](/features/open-terminal/terminals) runs execution in per-session, container-isolated environments with configurable [security-context and resource policies](/features/open-terminal/terminals/orchestration/policies).
+- **Operator guardrails.** [Filters](/features/extensibility/plugin/functions/filter), 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](../security-policy) for the full reporting scope.
+
+## References
+
+- [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
+- [LLM Output Unpredictability](./llm-output-unpredictability)
+- [Tools and Functions security model](/features/extensibility/plugin/tools)
+- [Open WebUI Security Policy](../security-policy)

docs/security/accepted-risks/auth-timing.mdx

@@ -8,7 +8,7 @@ title: "Authentication Timing Side-Channel (CWE-208)"
 | :--- | :--- |
 | **Class** | CWE-208, Observable Timing Discrepancy |
 | **Status** | Exploitable signal mitigated; sub-millisecond residual accepted |
-| **Tracked as** | GHSA-7rw5-9f7q-xj36 |
+| **Tracked as** | [GHSA-7rw5-9f7q-xj36](https://github.com/open-webui/open-webui/security/advisories/GHSA-7rw5-9f7q-xj36) |
 
 ---
 
@@ -18,10 +18,12 @@ The sign-in endpoint took measurably longer for an existing account than for a n
 
 ## What we mitigated
 
-Authentication now performs a bcrypt comparison against a fixed dummy hash on the paths where no user, or no active credential, is found. Every sign-in attempt therefore pays the same bcrypt cost regardless of whether the account exists.
+This was reported to us and is tracked as [GHSA-7rw5-9f7q-xj36](https://github.com/open-webui/open-webui/security/advisories/GHSA-7rw5-9f7q-xj36). We addressed it in the sign-in path: authentication now performs a bcrypt comparison against a fixed dummy hash on the paths where no user, or no active credential, is found. Every sign-in attempt therefore pays the same bcrypt cost regardless of whether the account exists.
 
 Measured, this collapses the difference from roughly 20-40x down to about 1.03x (bcrypt against bcrypt), which is indistinguishable from ordinary run-to-run variance. The practically exploitable enumeration oracle is removed.
 
+The millisecond residual that remains is accepted as-is. This is not a matter of further effort: what is left is bounded by physical and runtime limits (the database, the Python interpreter, CPU behaviour, operating-system scheduling and network jitter) rather than by anything Open WebUI's code can improve, so there is little more to be gained from here. The reasoning is set out in [What remains, and why it is not fixable](#what-remains-and-why-it-is-not-fixable) below.
+
 ## What remains, and why it is not fixable
 
 Perfectly constant-time authentication is not achievable in application-level code. Once the dominant bcrypt cost is equalised, the remaining differences are sub-millisecond and are produced by layers Open WebUI does not control:

docs/security/accepted-risks/index.mdx

@@ -44,5 +44,6 @@ A residual whose practical impact is dominated by network and scheduling noise,
 
 | Risk | Class | Mitigation | Status |
 | :--- | :--- | :--- | :--- |
+| [Agentic application risks](./agentic-application-risks) | Inherent agentic-system behavior (OWASP Top 10 for Agentic Applications) | Capability gated by permissions; agent bound by caller's privileges; isolated execution | Inherent to autonomous agents; out of scope on its own, unless chained with a legitimate vulnerability (see [Security Policy](../security-policy)) |
 | [LLM output unpredictability](./llm-output-unpredictability) | Inherent model behavior (OWASP LLM Top 10) | System hardened around the model; model bound by caller's privileges | Inherent to LLMs; out of scope on its own, unless chained with a legitimate vulnerability (see [Security Policy](../security-policy)) |
 | [Authentication timing side-channel](./auth-timing) | CWE-208, Observable Timing Discrepancy | bcrypt cost equalised across all sign-in paths | Mitigated, residual accepted |

docs/security/accepted-risks/llm-output-unpredictability.mdx

@@ -13,6 +13,8 @@ title: "LLM Output Unpredictability"
 
 ## Summary
 
+Open WebUI respects and appreciates the [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/); it is a valuable framework for reasoning about how AI systems fail. Many of the behaviours it catalogues, however, are not classical security vulnerabilities. They are risks inherent to large language models themselves, carried by any application built on one rather than introduced by a defect in a particular vendor's code. Where those models are given tools and autonomy, the same risks extend into agent behaviour; see [Agentic Application Risks](./agentic-application-risks).
+
 Large language models are non-deterministic and steerable by their input. A model can be convinced, through a crafted prompt, injected content in a fetched web page or uploaded document, or adversarial conversation, to produce unsafe, misleading, or attacker-desired output: a jailbreak, a prompt injection, a hallucinated fact, an unsafe recommendation, or an attempt to use an available tool in a way the user did not intend.
 
 This unpredictability is a property of how language models work. It is **not a defect in Open WebUI's code**.
@@ -44,4 +46,5 @@ Those are Open WebUI defects and are fixed as such. See the [Security Policy](..
 ## References
 
 - [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/)
+- [Agentic Application Risks](./agentic-application-risks)
 - [Open WebUI Security Policy](../security-policy)