Running an AI model on your own server can keep a deployment under your control, but it does not make the surrounding application safe by itself. A model server may sit beside a web interface, plugins, file upload handlers, databases, credentials and tools that can run code or call other services. Before inviting users or opening a network route, map those parts and decide what each one is allowed to reach.
This guide is a deployment checklist, not a security certification or a claim that VIBPS tested a particular model or product. It applies to self-hosted inference and the applications around it. The Australian Signals Directorate and partner agencies' 2026 guidance for open-weight models recommends treating deployment as a system, including its environment, interfaces, dependencies and operational controls.
1. Draw the request and data path
Write down how a request travels: user, proxy or gateway, AI interface, inference server, model files, tools and any database or external service. Mark where prompts, uploaded files, generated output, logs and secrets are stored or sent. Include administrative routes and background jobs. If you cannot say which component can read a file or reach a service, pause exposure until you can inspect the configuration.
Start with the smallest useful boundary. Keep the inference service in a separate network segment from sensitive systems and data, and separate development from production. Allow only the connections each component needs. In particular, restrict outbound traffic where possible: an application that can call every internal service or arbitrary internet host has a much larger impact if compromised. Give administrators a separate, protected route from ordinary inference requests.
2. Keep the interface private until access controls are ready
A model endpoint or chat interface should not become public merely because its page loads. Put authentication in front of every user-facing and administrative route. Require strong administrator authentication, preferably multifactor authentication, disable open registration if it is not needed, and give each person only the role they need. Use TLS, narrow cross-origin rules and request limits at the boundary. Check that API endpoints receive the same access controls as the visible page.
Open WebUI's own hardening guide says the application is intended for private, trusted networks and calls for additional access controls before internet exposure. Its examples include VPN or zero-trust access, an authenticated reverse proxy, rate limits, restricted signup and careful administrator and plugin permissions. Those are product-specific instructions, but the general lesson applies broadly: a login screen is only one part of the boundary, so review every route and integration.
Source: Open WebUI documentation: Hardening
3. Treat tools and plugins as code
An AI tool that can browse, execute code, read files or call APIs has the permissions of the component running it. Decide which tools are actually required, disable the rest, and restrict who can add or change them. Review imported functions and plugins like software dependencies: inspect their source, understand what data and network access they receive, and test them in a restricted environment before production.
Isolation must match the threat. A browser-side execution feature is not automatically a server-side security boundary. A regular container is also not a reason to mount the host's Docker socket into an app: Docker's documentation explains that access to that socket can grant control over the host environment. If a feature needs to run untrusted code, use a dedicated sandbox design with explicit filesystem, network, resource and lifecycle limits; verify the guarantees of the specific sandbox you choose.
Source: Docker documentation: AI Sandboxes security and isolation
4. Give the service narrow, replaceable credentials
Create separate credentials for the interface, model service and each integration. Grant only the necessary actions and data scope; avoid reusing a personal or administrator token. Keep secrets out of prompts, source control, images and ordinary logs. Store them in an appropriate secret manager, rotate them after staff or system changes, and make revocation a tested operation. If a tool only needs to read one dataset, a credential that can modify every database is unnecessary risk.
5. Make updates and vulnerability reports actionable
Maintain an inventory of the interface, inference server, runtime, plugins, libraries, model files and infrastructure. Subscribe to their security advisories and assign someone to review them. Prioritize a reported issue based on severity, whether a fix exists, whether the vulnerable component is present and reachable in your deployment, and what access it has. Apply tested security updates promptly, keep a rollback path and retire components that no longer receive fixes.
A 2026 BirdyFoot analysis counted 737 GitHub-reviewed security advisories across 17 open-source AI tools from 2023 through October 28, 2026. That is a count of reports in a selected dataset, not a count of attacks, proof that every listed issue affects every installation, or a measure of risk for all AI software. The authors also caution that disclosure volume does not establish that tools became less secure. Use such counts as a reason to maintain an update process, not as a prediction about your own server.
Source: GitHub documentation: Understanding vulnerability exposure and prioritizing alerts
6. Limit abuse and protect the records you keep
Set request and concurrency limits, input and upload size caps, timeouts and per-user quotas. Watch GPU, memory, storage and network consumption so one account cannot exhaust shared capacity. Decide whether prompts and outputs need to be logged at all. If you retain them for incident response or debugging, tell users, collect only what is needed, restrict access and retention, and protect the records as sensitive data.
Monitor authentication failures, unexpected administrator changes, unusual tool use, repeated resource spikes and outbound connections. Send security events somewhere an attacker with access to the application cannot quietly erase. Logging should help answer who accessed which system and when, while avoiding unnecessary copies of private prompts or uploaded documents.
7. Rehearse the stop and recovery steps
Before launch, test how you would disable public access, stop inference, isolate the service, revoke credentials, preserve relevant logs and restore a known-good version. Confirm that backups can be restored and that a rollback does not quietly re-enable an exposed route. Give the on-call person a short runbook and the authority to take the service offline. A response plan that has never been tried may fail at the point it matters.
- Every user and admin route has an intentional access rule, and the service is not exposed until those rules are checked.
- Inference, tools and data stores have separate boundaries and only necessary network paths.
- Plugins and code-running features are restricted, reviewed and isolated according to their permissions.
- Credentials are scoped, protected, replaceable and absent from prompts and routine logs.
- There is an owner for dependency and security advisories, tested updates and rollback.
- Authentication, resource use and unusual tool activity are monitored with privacy-conscious retention.
- The team has rehearsed isolation, access revocation and restoration from a known-good state.
If one of these checks is unknown, keep the deployment on a private network while you resolve it. For a maker preparing a software project for other people, this operational checklist complements the separate work of protecting source files during AI-assisted editing and testing an app's user flows before invitations. Publishing a project page can help people find what you made; it does not certify the deployment.
Protect your project while an AI agent edits it
Test an AI-built app before inviting users
How maintainers can triage AI-generated vulnerability reports