Reference

Threat model and best practices

What veil protects against, what it does not, and how to use it safely.

What you will do: Check the limits of veil before you rely on it, and follow the practices that keep it safe.
Before you start: It helps to know how it works.
What comes next: The known limitations and FAQ.

Threat model

The tool's vendor seeing your home IP. The vendor sees a Cloudflare WARP address instead.
The tool reaching any host outside the allowlist. When the gateway is down, the tool has no network.
The tool reading or writing host files outside the workspace and the dedicated home.
The tool inheriting your environment, such as API tokens, SSH_AUTH_SOCK or proxy variables.

Cloudflare. Cloudflare sees your home IP and the traffic metadata.
Linking sessions. Accounts, prompts, code and behavior can still link your sessions. The WARP exit address does not rotate.
Your local network. Anyone on your local network can use or impersonate the gateway until issue #2 is done.
Kernel exploits, a compromised host or privileged processes.
Files left in the workspace. Anything you put in the workspace is visible to the tool. A file the tool writes there, such as .git/hooks/*, Makefile or .envrc, runs on the host if you execute it later.

Use a disposable or dedicated workspace, and keep secrets out of it. The tool can read everything in the workspace.
Use one --home directory per tool, so each tool's login and state stay apart.
Never run veil with sudo.
Review the files the tool wrote, such as .git/hooks, Makefile and .envrc, before you run them on the host.
Never share, copy, print or commit the warp-data volume. It holds the WARP private key.
Keep the gateway on a trusted local network (LAN), and never publish port 8118 to the internet.
Do not paste real IP addresses, keys, tokens or WARP account files into issues. Use placeholders such as gateway.local and 192.168.0.0/24.