Open WebUI Deep Dive: Users, Models, Documents, Prompts, and Safe Sharing

The short answer: Open WebUI is suitable for a personal or shared homelab only when you patch it, keep signup controlled, separate admin and user accounts, grant models and knowledge bases explicitly, restrict tools, and back up the complete data volume. Self-hosting gives you control; it does not make every provider, plugin, upload, or tool private or safe.

This article is for the person administering a personal, family, or small-team instance. It assumes Open WebUI is already running in Docker and that you can manage volumes, logs, DNS, TLS, and firewall rules. The interface changes quickly: this guidance was fact-checked against the v0.10.2 release and current documentation on July 15, 2026, but you should recheck the release notes before publication or upgrade.

http://localhost:3000

If you are on another device on the same network, replace localhost with your server IP:

http://192.168.1.100:3000

Use this deep dive as a map of what to configure after the first successful login.

Quick Feature Map

Interactive Open WebUI Map: What Each Area Does

Click each step to see what it means in a beginner-friendly local AI setup.

1Chat2Models3Knowledge4Admin5Security

Select a step

Choose a box above to view details.

UsersAccounts

ModelsSwitching

KnowledgeDocs/RAG

AdminSettings

Area	What it does	Beginner example
Chat	The main place you talk to models	Ask Llama 3.1 to explain a log file
Models	The list of available AI models and custom model presets	Switch between a coding model and a writing model
Knowledge/Documents	Upload files so the AI can search them	Ask questions about a PDF manual
Prompts	Reusable slash commands	Type /summarize instead of pasting a long instruction
Users/Groups	Control who can log in and what they can use	Give family access but hide admin tools
Connections	Tell Open WebUI where model APIs live	Connect Ollama, OpenAI, LiteLLM, vLLM, OpenRouter, or another compatible API
API Keys	Let scripts call Open WebUI	Use a local automation script to send chat requests
Admin Settings	Instance-wide switches	Enable/disable signup, API keys, model defaults, RAG settings
Backups/Updates	Keep data safe and software current	Back up the Docker volume before pulling a new image
Proxy/VPN	Safer network access	Use Tailscale or Nginx instead of opening a random port to the internet

First Login and Users

The first account you create is the admin account. Save that login in your password manager. If you lose the first admin account, approving later users and changing settings can become annoying.

Open WebUI has three simple system roles:

Role	What it means	Give it to
Admin	Full control of users, settings, connections, and resources	Only the homelab owner or trusted maintainers
User	Normal chat access, limited by permissions and groups	Family, teammates, or your own non-admin account
Pending	Signed up but not approved yet	New accounts waiting for review

Beginner-safe setup:

1. Log in with the first admin account.
2. Open Admin Panel.
3. Go to Users.
4. Approve only the accounts you recognize.
5. Keep new users as User, not Admin.
6. Use groups when different people should see different models, prompts, or knowledge bases.

Groups are useful because permissions add together. If a person is in two groups, they get the combined permissions from both. There is no strong "deny" rule that overrides an allowed permission, so keep groups simple.

Good starter groups:

Group	Purpose	Example permissions
Family	Basic household chat	Chat and selected models
Power Users	Trusted technical users	More models, file uploads, maybe API keys
Admin Helpers	People who help manage the instance	Carefully selected admin-like permissions
Kids/Guests	Limited access	Only safe models, no API keys, no workspace tools

Important security note: be careful with workspace tools and functions. Some Open WebUI extension features can execute code on your server. Do not give that power to untrusted users.

Model Switching

The model selector is usually near the top of the chat screen. It decides which model answers the next message.

Simple model switching steps:

1. Open a chat.
2. Click the model name near the top.
3. Pick a different model.
4. Send a new message.
5. Compare the answer quality, speed, and style.

You can switch models inside the same conversation. The chat history remains visible, but the new model may understand the conversation differently. A small model may struggle with a long chat that a larger model handled fine.

Common model types:

Model type	Best for	Tradeoff
Small local model	Quick simple questions, private offline use	Weaker reasoning
Larger local model	Better answers on your own hardware	Needs more RAM/VRAM
Coding model	Code, scripts, error messages	May be less friendly for general writing
Cloud model	Strong reasoning and broad capability	Sends prompts to the provider you configured
Custom Open WebUI model preset	A reusable "agent" with system prompt, tools, and knowledge attached	Needs setup time

Open WebUI also has a Workspace > Models area. This is not just a download list. It lets you create a custom model preset on top of a base model.

Example: You have one base model called llama3.1. You can create:

Preset	Base model	Added behavior
Home IT Helper	llama3.1	Uses a system prompt about explaining steps slowly
Recipe Helper	llama3.1	Uses a cooking prompt and pantry knowledge base
Log Analyzer	llama3.1	Uses a troubleshooting prompt and lower temperature

This is easier for beginners than remembering which settings to attach every time.

Documents and Knowledge

Documents are where Open WebUI becomes more than a chat box. You can upload files and ask questions about them. This is often called RAG, short for Retrieval-Augmented Generation. In plain English: Open WebUI searches your documents, finds relevant chunks, and gives those chunks to the model so it can answer with context.

There are two common ways to use files:

Method	When to use it	Example
Chat upload	One-off file for one conversation	Drop in a PDF and ask for a summary
Knowledge base	Reusable collection of files	Build a "Homelab Manuals" collection

Beginner document workflow:

1. Open Open WebUI.
2. Go to Workspace.
3. Open Knowledge or Documents, depending on your version and menu layout.
4. Create a new knowledge collection, such as Homelab Notes.
5. Upload PDFs, text files, Markdown files, spreadsheets, or code files.
6. Wait for processing to finish.
7. Start a chat and attach or reference that knowledge collection.
8. Ask a specific question, such as: "Using the Homelab Notes knowledge base, how do I restart the media server?"

Tips for better document answers:

Tip	Why it helps
Use text-based PDFs when possible	Scanned images may need OCR before the model can read them well
Split huge topics into separate knowledge bases	"Networking", "Docker", and "Recipes" are easier to search than one giant pile
Ask specific questions	"What port does the guide say to use?" beats "Explain this"
Keep private docs private	Uploaded files live on your server, but approved users may access shared knowledge
Delete stale files	Old notes can cause wrong answers

File cleanup matters. In current docs, Open WebUI has file management under settings/data controls. Deleting unused files can also clean up related retrieval data, depending on the file manager path you use.

Prompts

Prompts are reusable commands. Instead of typing the same long instruction over and over, you save it once and call it with a slash command.

Example:

/summarize

A prompt can be simple:

Summarize the text below in plain language. Use short bullets. End with action items.

Or it can use variables:

Summarize this for {{audience}}. Keep the tone {{tone}}. Focus on {{topic}}.

Beginner prompt workflow:

1. Go to Workspace.
2. Open Prompts.
3. Create a new prompt.
4. Give it a short command name, such as summarize.
5. Paste the instruction.
6. Save it.
7. Open a chat.
8. Type /summarize.
9. Fill in any fields if the prompt asks for them.

Useful starter prompts:

Prompt command	Purpose	Example use
/summarize	Condense long text	Meeting notes, articles, PDFs
/explain-like-newbie	Slow explanation	Error messages and logs
/rewrite-email	Make a message clearer	Support emails or work replies
/docker-help	Troubleshoot containers	Paste docker logs output
/compare	Compare options	Mini PC vs used workstation

Keep prompts boring and clear. A good prompt tells the model the task, the audience, the format, and what to avoid.

Admin Settings That Matter First

Open WebUI has many settings. Do not try to learn all of them on day one. Start with the settings that affect access, models, documents, and safety.

Admin area	What to check	Beginner recommendation
Users	Who can log in	Keep unknown users pending
Groups	Shared permissions	Make a small number of clear groups
Connections	Model provider URLs and keys	Verify Ollama or OpenAI-compatible providers work
Models	Visible models and defaults	Hide models you do not want users to pick
General/Auth	Signup and API keys	Keep signup controlled; enable API keys only if needed
Knowledge/RAG	File handling and retrieval	Test with one small knowledge base before uploading everything
Data Controls	Files and exports	Learn where uploaded files are managed
Security/Network env vars	CORS, URL, cookies, secret key	Set these when using HTTPS or a reverse proxy

Good beginner defaults:

Setting idea	Safer choice
New user role	pending
Number of admins	As few as possible
API keys	Disabled until you need them
Workspace tools for regular users	Disabled
Public internet exposure	Avoid unless you understand reverse proxies and authentication
Backups	Before every update, plus scheduled backups

If you use Docker, many settings can be passed as environment variables in docker run or docker-compose.yml. For a normal homelab, Docker Compose is easier to maintain than a very long docker run command.

Connecting OpenAI-Compatible Providers

"OpenAI-compatible" means a service speaks an API shaped like OpenAI's API. It does not always mean you are using OpenAI. Many tools can provide an OpenAI-compatible endpoint, including LiteLLM, vLLM, LocalAI, OpenRouter, some cloud providers, and other gateways.

There are two different directions people confuse:

Direction	What it means	Example
Provider into Open WebUI	Open WebUI calls another model API	Add OpenRouter or LiteLLM under Admin Settings > Connections
Client into Open WebUI	Another app calls Open WebUI's API	A script sends a chat request to /api/chat/completions

Add a Provider to Open WebUI

Steps:

1. Log in as admin.
2. Open Admin Panel.
3. Go to Settings.
4. Open Connections.
5. Find the OpenAI-compatible section.
6. Add the provider base URL.
7. Add the API key.
8. If model auto-detection does not work, manually add allowed model IDs.
9. Click verify or save.
10. Return to chat and pick the new model from the model selector.

Example provider table:

Provider style	Base URL example	Notes
LiteLLM on your LAN	http://192.168.1.50:4000/v1	Useful as a gateway to many providers
vLLM OpenAI server	http://192.168.1.60:8000/v1	Common for self-hosted inference
OpenRouter	https://openrouter.ai/api/v1	Add a model allowlist to avoid clutter
Google Gemini OpenAI-compatible endpoint	https://generativelanguage.googleapis.com/v1beta/openai	Watch exact URL format in current docs

Beginner translation: the base URL tells Open WebUI where to send requests. The model ID tells Open WebUI what to ask for at that address.

Use Open WebUI as an API Endpoint

Open WebUI can also act like a model gateway for your own tools.

Basic steps:

1. Enable API keys if your admin settings require it.
2. Open your user settings.
3. Go to Account.
4. Generate an API key.
5. Store it like a password.
6. Call Open WebUI with a bearer token.

Example chat request:

curl -X POST http://localhost:3000/api/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1",
    "messages": [
      {
        "role": "user",
        "content": "Explain Open WebUI in one paragraph."
      }
    ]
  }'

API key safety:

Rule	Why
Treat API keys like passwords	They can use the account's permissions
Use a separate account for automation	Easier to disable if a script leaks
Restrict API key permissions if available	Limits damage
Do not paste keys into WordPress posts, GitHub, Discord, or screenshots	Leaked keys get abused

Backups

Your Open WebUI data is more important than the container. The container can be recreated. Your chats, users, uploaded files, database, settings, and vector data need backup.

Common Docker volume layout:

Data	Typical location inside container
Open WebUI database	/app/backend/data/webui.db
Uploads	/app/backend/data/uploads
Vector database	/app/backend/data/vector_db
Cache/log data	/app/backend/data/cache, /app/backend/data/audit.log

If you used the common Docker volume:

-v open-webui:/app/backend/data

then the Docker volume is usually named open-webui.

Simple cold backup for a Docker volume:

docker stop open-webui

docker run --rm \
  -v open-webui:/data:ro \
  -v "$PWD":/backup \
  alpine \
  tar czf /backup/open-webui-backup-$(date +%F).tgz -C /data .

docker start open-webui

What this does:

1. Stops Open WebUI so the database is not changing during backup.
2. Mounts the open-webui volume read-only.
3. Creates a compressed .tgz backup in the current folder.
4. Starts Open WebUI again.

Restore test checklist:

Check	Done?
Backup file exists and is not tiny
You know where the file is stored
You copied it off the server
You tested restoring to a spare volume or test machine
You wrote down the container name and volume name

A backup you have never tested is only a hope.

Updates

Open WebUI updates usually mean replacing the container image while keeping the same data volume.

Safe beginner update flow:

1. Read the release notes if this is an important instance.
2. Back up the data volume.
3. Pull the new image.
4. Recreate the container with the same volume.
5. Check logs.
6. Open the UI.
7. Test one chat and one document search.

Docker run style:

docker rm -f open-webui
docker pull ghcr.io/open-webui/open-webui:main
docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

If your original install used extra flags, keep them when you recreate the container. For example, local Ollama setups often need --add-host=host.docker.internal:host-gateway, and GPU setups may need --gpus all.

Docker Compose style:

docker compose pull
docker compose up -d

For a shared family or team instance, consider pinning a version instead of always using :main. Pinning means your docker-compose.yml names a specific release tag. That gives you more control, but you must remember to update intentionally.

Update safety table:

Situation	Recommended approach
Personal test box	:main is convenient
Daily family use	Back up first, then update manually
Team or production use	Pin versions and read release notes
Something breaks after update	Stop, preserve the volume, review logs, then consider rolling back image tag

Also set a persistent WEBUI_SECRET_KEY for serious deployments. If the secret changes unexpectedly, users may get logged out or encrypted tokens may stop decrypting correctly.

Reverse Proxy Basics

A reverse proxy sits in front of Open WebUI. Users connect to the proxy, and the proxy forwards traffic to Open WebUI.

Why use one?

Reason	What it gives you
HTTPS	Encrypted browser connection
Nice URL	https://ai.example.com instead of http://192.168.1.100:3000
Central access control	Add IP allowlists, SSO, or extra auth
Cleaner network layout	Open WebUI can listen only on localhost

Beginner mental model:

Browser -> HTTPS reverse proxy -> Open WebUI container -> model provider

If the proxy runs on the same server, bind Open WebUI to localhost so it is not directly exposed to the whole LAN:

ports:
  - "127.0.0.1:3000:8080"

Then point the proxy to:

http://127.0.0.1:3000

Simple Caddy example:

ai.example.com {
  reverse_proxy 127.0.0.1:3000
}

Simple Nginx location example:

location / {
  proxy_pass http://127.0.0.1:3000;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_buffering off;
  proxy_cache off;
}

Reverse proxy settings to remember:

Setting	Why it matters
WebSocket upgrade headers	Needed for streaming and live UI behavior
proxy_buffering off	Prevents broken or delayed streaming output
CORS_ALLOW_ORIGIN	Should match your real HTTPS URL when needed
WEBUI_URL	Helps links and OAuth callbacks use the right public URL
Secure cookies	Use when Open WebUI is served over HTTPS

For many homelabs, Caddy is the easiest reverse proxy. Nginx gives more manual control. Nginx Proxy Manager gives a web UI for people who do not want to hand-edit config files.

LAN and VPN Security

Do not confuse "local network" with "safe." A LAN can include guest Wi-Fi devices, old phones, compromised laptops, smart TVs, and visitors. If Open WebUI can reach powerful models, private documents, or API keys, protect it.

Access options:

Access style	Good for	Risk level
Localhost only	One person on the server	Lowest
LAN IP and port	Home use on trusted network	Medium
VPN/Tailscale	Remote private access	Lower than public port forwarding
Reverse proxy with HTTPS	Named domain and browser trust	Depends on auth and exposure
Public port forward	Internet access	Highest

Beginner-safe recommendation:

1. For one machine, use localhost.
2. For home devices, use LAN access only if your Wi-Fi is trusted.
3. For remote access, use Tailscale, WireGuard, or another VPN.
4. For public access, use HTTPS, strong authentication, rate limiting, and careful user permissions.
5. Do not expose Open WebUI directly to the internet with plain HTTP.

Tailscale-style flow:

Laptop/phone on tailnet -> encrypted VPN -> homelab server -> Open WebUI

Why VPN is beginner-friendly:

Benefit	Plain explanation
No public port required	Your router does not need to expose Open WebUI to everyone
Device-level access	Only your approved devices can connect
Works away from home	Use your home AI from a laptop or phone
Can still use HTTPS	Tailscale and proxies can provide browser-friendly HTTPS options

Minimum security checklist:

Task	Recommendation
Admin password	Use a long unique password
Signup	Keep new users pending or disable signup after setup
Admin accounts	Keep the count small
API keys	Enable only when needed
Tools/functions	Restrict to trusted admins
Documents	Share only with the users/groups that need them
Backups	Encrypt backups if they contain private chats or documents
Router	Avoid public port forwarding unless you know why
Updates	Back up first, then update
Logs	Review failed logins or strange traffic if exposed beyond localhost

A Simple First-Day Configuration Plan

If you are new, do this in order:

1. Confirm Open WebUI works from the server browser.
2. Create and save the first admin account.
3. Connect one model provider, such as Ollama.
4. Send one test chat.
5. Create one regular user account for yourself and keep admin separate.
6. Upload one small document and test a question.
7. Create one prompt shortcut.
8. Back up the Docker volume.
9. Decide how you will access it: localhost, LAN, VPN, or reverse proxy.
10. Only then invite other users.

Troubleshooting Quick Table

Problem	Likely cause	First thing to try
Other devices cannot connect	Server firewall, wrong IP, container bound to localhost	Test from server, then check http://SERVER-IP:3000
Model list is empty	Provider connection is wrong	Check Admin Settings > Connections
Ollama works on host but not in container	localhost inside Docker means the container	Use host.docker.internal or the host LAN IP
Streaming looks broken behind proxy	Proxy buffering or WebSocket headers	Disable buffering and set upgrade headers
New user cannot chat	Account is pending or lacks permissions	Approve user and check groups
Uploaded document gives bad answers	Bad extraction, wrong knowledge base, weak model, small context	Try a text file, ask a specific question
Update did not change anything	Old container still running	Pull image, remove old container, recreate
Chats disappeared after restart	No persistent volume or wrong volume mounted	Stop and inspect the Docker volume before changing more

Evidence and Security Validation

Evidence status: this article is documentation-backed. TechGeeks reviewed current Open WebUI documentation, v0.10.2 release notes, and independent GitHub Security Lab analysis on July 15, 2026. TechGeeks did not deploy a fresh multi-user instance or independently reproduce an access-control vulnerability for this revision. The following is a reader-run acceptance and regression test, not a report of completed lab work.

Patch before testing. GitHub Security Lab documented a tool-restriction bypass in v0.6.43, and current release notes continue to include security and access-control fixes. Do not infer safety from the product being self-hosted, and do not expose an old instance while you decide whether to upgrade.

1. Inventory the deployment. Record the immutable image digest, database type, volume, WEBUI_SECRET_KEY handling, providers, API keys, enabled tools/functions, signup policy, groups, public URL, and reverse-proxy rules.
2. Create negative-test accounts. Use a pending account, an ordinary user, a group-limited user, and a separate administrator. In a private browser session, confirm each user sees only the assigned models, knowledge bases, chats, prompts, tools, and API features.
3. Test the API, not only the menus. From the ordinary account, directly request an unassigned resource and invoke a disabled tool through the supported API path. Both attempts must fail server-side; hiding a button is not authorization.
4. Plant canary content. Put a unique harmless string in a private knowledge base and another in a different user's file. Queries from unauthorized accounts must not retrieve either string. Repeat after group changes and after an update.
5. Test untrusted documents. Upload a benign file containing an instruction to ignore the user and call a tool. The application must not grant a document more authority than the user, and write-capable tools should require an explicit approval or remain unavailable.
6. Trace egress. Send a local-model chat while observing DNS and outbound connections. Repeat with web search, remote embeddings, image generation, and each plugin disabled and enabled so the privacy effect of every integration is known.
7. Restore, then upgrade. Restore the complete data volume and secret to a separate test instance, sign in as both admin and user, open a chat, retrieve a document, and call an allowed tool. Upgrade the clone first and repeat all negative tests.

Break-Glass and Data Boundaries

If authorization fails, stop public or cross-VLAN access first. Disable the affected tool or provider, revoke exposed API and OAuth tokens, preserve container, proxy, authentication, and audit logs, and keep the data volume unchanged for investigation. Do not erase the instance before determining which users, resources, and outbound services were reachable.

A rollback requires the previous image digest and a database copy from before migration. Recreating an older container against a database already changed by a newer release may not be supported. Keep the original backup read-only, restore to a new volume, and verify login and retrieval before switching traffic. Preserve the same secret when restoring encrypted tokens; rotate external credentials if the secret or backup may have leaked.

Uploads, chats, generated memories, logs, and vector indexes can contain personal data, copyrighted documents, source code, and secrets. Collect only what users are authorized to provide, define retention and deletion expectations, encrypt off-host backups, and review the privacy and data-use terms of every remote model, embedding, speech, image, and search provider. Open WebUI access control does not grant legal permission to process the content.

What This Evidence Does Not Prove

• Passing role and group tests on v0.10.2 does not prove future releases or every API endpoint preserve the same authorization behavior.
• A private knowledge-base setting does not prove retrieved chunks cannot cross a boundary through a plugin, shared model, administrator action, backup, log, or software defect.
• HTTPS protects traffic in transit; it does not secure an overprivileged tool, weak account, exposed origin, compromised browser, or remote provider.
• A successful backup archive does not prove recovery. Only a clean restore that exercises login, chats, files, retrieval, and tools validates the recovery path.
• A local Ollama connection does not prove the entire workflow is local when web search, remote embeddings, image generation, speech, pipelines, or cloud models are enabled.

Related TechGeeks Reading

• Remote Access Without Opening Router Ports
• Tailscale vs WireGuard vs Cloudflare Tunnel vs Reverse Proxy
• Docker Compose for Normal People
• RAID, ZFS Snapshots, Sync, and Backup

References

Sources fact-checked on 2026-07-15:

1. Open WebUI Docs - Home: https://docs.openwebui.com/
2. Open WebUI Docs - Sharing Open WebUI: https://docs.openwebui.com/getting-started/sharing/
3. Open WebUI Docs - Roles: https://docs.openwebui.com/features/authentication-access/rbac/roles/
4. Open WebUI Docs - Groups: https://docs.openwebui.com/features/authentication-access/rbac/groups/
5. Open WebUI Docs - Permissions: https://docs.openwebui.com/features/authentication-access/rbac/permissions/
6. Open WebUI Docs - Models: https://docs.openwebui.com/features/workspace/models/
7. Open WebUI Docs - Knowledge: https://docs.openwebui.com/features/workspace/knowledge/
8. Open WebUI Docs - Retrieval Augmented Generation: https://docs.openwebui.com/features/chat-conversations/rag/
9. Open WebUI Docs - File Management: https://docs.openwebui.com/features/chat-conversations/data-controls/files/
10. Open WebUI Docs - Prompts: https://docs.openwebui.com/features/workspace/prompts/
11. Open WebUI Docs - OpenAI-Compatible Provider Setup: https://docs.openwebui.com/getting-started/quick-start/connect-a-provider/starting-with-openai-compatible/
12. Open WebUI Docs - API Keys: https://docs.openwebui.com/features/authentication-access/api-keys/
13. Open WebUI Docs - API Endpoints: https://docs.openwebui.com/reference/api-endpoints/
14. Open WebUI Docs - Backups: https://docs.openwebui.com/tutorials/maintenance/backups/
15. Open WebUI Docs - Updating Open WebUI: https://docs.openwebui.com/getting-started/updating/
16. Open WebUI Docs - HTTPS and Reverse Proxies: https://docs.openwebui.com/reference/https/
17. Open WebUI Docs - HTTPS using Nginx: https://docs.openwebui.com/reference/https/nginx/
18. Open WebUI Docs - HTTPS using Tailscale: https://docs.openwebui.com/reference/https/tailscale/
19. Open WebUI Docs - Hardening Open WebUI: https://docs.openwebui.com/getting-started/advanced-topics/hardening/
20. Open WebUI Docs - Connection Errors: https://docs.openwebui.com/troubleshooting/connection-error/
21. Open WebUI v0.10.2 release notes: https://github.com/open-webui/open-webui/releases/tag/v0.10.2
22. Open WebUI security advisories: https://github.com/open-webui/open-webui/security
23. GitHub Security Lab, GHSL-2026-002 tool-restriction bypass analysis: https://securitylab.github.com/advisories/GHSL-2026-002_Open_WebUI/
24. OWASP GenAI Security Project, prompt-injection risk: https://genai.owasp.org/llmrisk/llm01-prompt-injection/