kern runs servers on your machine, so the trust boundaries worth knowing are concrete.

• ·no admin rights. the windows installer is per-user (%LOCALAPPDATA%), macos and linux builds run unprivileged. kern never asks for elevation.
• ·no telemetry, no accounts. nothing leaves the machine except the update check and the requests you configure (registry, webhooks). there is no kern cloud.
• ·files stay local. config, logs, backups, and audit history live under the app data dir and your instance folders. deleting the app doesn't touch your server folders.

• ·bound to loopback only (127.0.0.1) — nothing on the lan can reach it.
• ·bearer-token auth; the token is a random 64-hex string written to automation.json in the app data dir and reused across restarts so scripts keep working.
• ·plain http on purpose: loopback traffic never hits a network, so a self-signed https handshake would add trust prompts without adding a boundary.
• ·who can read the token: anyone who can read your user's app data dir. that's the same trust level as your user account — files in ~ are already readable by processes running as you.

see web remote. short version: https with a self-signed cert (or a real one via the tunnel), per-device tokens paired with single-use invites, roles (viewer / operator / admin) with optional per-server scoping, and no listener on the lan at all if you bind 127.0.0.1. the optional cloudflare tunnel (quick or named) exposes it publicly — still device-token gated, but a public URL plus a valid token is full control, so enable it deliberately, revoke devices you don't trust, and put cloudflare access in front for anything long-lived. every remote mutation is attributed in the audit log.

• ·plugin secrets and stored credentials go to the os credential vault (windows credential manager / macos keychain / secret service), never to config.json.
• ·the rcon password is stored in the vault too.
• ·config.json holds no passwords. instance .env files are user content and are never uploaded or synced by kern.

plugins are a capability boundary, not a sandbox — plugin ui shares the host webview realm. the boundary works by allowlist: every host command maps to a permission the manifest must declare and you must consent to at install time. read plugin security before installing community packages.

the in-app updater verifies a minisign signature against a public key embedded in the binary before installing anything. if verification fails, the update is refused. keys are never shipped to clients.

archives are plain zips under <instance>/backups/ — confidential if your world is. backups are not encrypted and not uploaded anywhere; treat them like the world folder itself.

lifecycle actions, config changes, plugin installs, backups, and task runs are appended to audit.log in the app data dir (bounded and rotated). it's local-only, exportable from settings, and a good way to answer "who restarted this at 2am".

security issues: open a github issue for non-sensitive reports; for anything exploitable, use github's private vulnerability reporting on the repo.