# Local AI Deployment Security Checklist

Source: localaiops.com

Use this checklist when deploying self-hosted AI models (Ollama, Open WebUI,
llama.cpp, LM Studio) on Linux systems.

## Network Security

- [ ] Ollama API (port 11434) is NOT exposed to the internet
- [ ] Open WebUI is behind a reverse proxy with HTTPS (Nginx, Caddy, or Traefik)
- [ ] Firewall rules restrict AI service ports to localhost or trusted IPs only
- [ ] If remote access is needed, use a VPN or SSH tunnel -- not port forwarding
- [ ] DNS resolution for AI services is internal only (not in public DNS)

## Authentication and Access

- [ ] Open WebUI has authentication enabled (not anonymous access)
- [ ] Admin account uses a strong, unique password
- [ ] OAuth/SSO configured if available (Open WebUI supports OIDC)
- [ ] API access requires authentication tokens where supported
- [ ] Default credentials changed on all services

## Container Security (Docker deployments)

- [ ] Containers run as non-root user where possible
- [ ] Docker socket is NOT mounted into AI containers
- [ ] Read-only filesystem enabled where supported (--read-only flag)
- [ ] Resource limits set (--memory, --cpus) to prevent resource exhaustion
- [ ] Container images pulled from official sources only (ollama/ollama, ghcr.io/open-webui)
- [ ] Images pinned to specific versions in production (not :latest or :main)
- [ ] Docker network isolation: AI services on a dedicated bridge network

## Data Protection

- [ ] Model files stored on encrypted filesystem (LUKS or similar)
- [ ] Chat history and user data volumes have restricted permissions (chmod 700)
- [ ] Backup strategy in place for persistent volumes
- [ ] No sensitive data in environment variables visible via docker inspect
- [ ] Secrets passed via Docker secrets or .env files (not command line arguments)

## Model Security

- [ ] Models downloaded from trusted sources only (ollama.com, huggingface.co)
- [ ] Model file checksums verified after download
- [ ] Custom/fine-tuned models scanned before deployment
- [ ] Model output is treated as untrusted input in downstream systems
- [ ] Rate limiting configured to prevent abuse (especially for multi-user setups)

## System Hardening

- [ ] Host OS is fully patched and on a supported release
- [ ] Automatic security updates enabled (unattended-upgrades on Debian/Ubuntu)
- [ ] GPU drivers updated to latest stable version
- [ ] Fail2ban or CrowdSec configured for brute-force protection
- [ ] System logs forwarded to central logging (journald, syslog, or SIEM)
- [ ] AppArmor or SELinux profiles active for container runtime

## Monitoring

- [ ] Resource usage monitored (GPU VRAM, CPU, RAM, disk)
- [ ] Alerts configured for abnormal resource consumption
- [ ] Access logs reviewed regularly for unauthorized access attempts
- [ ] Docker container health checks configured and monitored
- [ ] Disk space alerts set (model files can be 4-50GB+ each)

## Incident Response

- [ ] Know how to stop all AI services quickly (docker compose down)
- [ ] Documented procedure to rotate API keys and tokens
- [ ] Backup restoration tested at least once
- [ ] Contact info for GPU/hardware vendor support available