Your hardware, your rules.
Designed to be auditable.

The agent runs on your hardware. NodeMesh is the control plane — it tells the agent what to do, but it does not hold your game data, your world files, or elevated privileges on your machine.

The relationship is deliberately one-directional: your agent registers with NodeMesh and opens a persistent gRPC stream. NodeMesh can only send the commands the agent's allowlist permits — nothing else crosses that channel. Your machine initiates the connection; nothing from the internet reaches it unless the traffic proxy is enabled for a specific instance.

The agent uses a dumb-terminal architecture: all game intelligence lives in the NodeMesh backend. The agent registers, sends heartbeats, executes a narrow set of permitted operations, and streams stdout/stderr back. It does not parse or interpret game protocol.

This is the headline security improvement shipped in the R4 hardening round (v0.2.13). The agent's Execute RPC used to allow bash, sh, java, steamcmd, and PowerShell. All of those except PowerShell have been removed from the allowlist. Linux game servers no longer use the Execute RPC at all.

All seven supported Linux games (Minecraft, Valheim, Hytale, Rust, Palworld, Satisfactory, Project Zomboid) install and launch via dedicated GameSetup and GameStart RPCs. These execute Go code directly — no shell in the middle. The install specification is a declarative JSON manifest; the agent resolves download URLs, verifies checksums, writes config files, and spawns the game binary — all in native Go with no intermediate shell interpreter.

• The current Execute allowlist contains only powershell and powershell.exe — used exclusively by the Windows Minecraft beta path. Bash and sh have been removed.
• No arbitrary shell command can reach a Linux agent through the NodeMesh API.
• The Windows agent (beta) still uses PowerShell for the Minecraft setup path. This is a known limitation and will be removed when the Windows manifest path is production-ready.

Every agent is issued a unique credential at registration. No shared secrets, no bearer tokens that work across machines.

• At registration, the backend generates a 32-byte random secret, bcrypt-hashes it, and stores only the hash in nodes.secret_hash. The plaintext is returned once in the registration response and never stored server-side.
• Every subsequent gRPC call must carry x-node-id and x-node-secret metadata. Server-side interceptors validate via bcrypt on every RPC. Nodes without a stored hash are rejected — fail closed.
• The command stream binds to the authenticated identity: the heartbeat node ID must match the credential's node ID. A rogue client cannot displace a legitimate agent's connection.
• In production, agents dial api.nodemesh.app:443 over TLS (Let's Encrypt certificate, Caddy-terminated). The gRPC listener and proxy control channel bind loopback only — they are never directly reachable from the internet.

The agent's manifest installer is constrained in two ways:

• Path traversal prevention: every file write and executable launch goes through safeJoin, which resolves and prefix-checks the path against the instance directory. A manifest that tries to write outside its directory is rejected before any I/O occurs.
• Working directory root: the Execute RPC's working directory must fall under the allowed install root (derived from NODEMESH_DATA_DIR). Requests outside this boundary are rejected and the instance is marked stopped so the UI reflects the failure immediately.
• SHA-256 verified game downloads: artifacts downloaded by the manifest installer are checked — non-empty body, and SHA-256 hash verified before writing to disk. A corrupted or truncated download is discarded and the install fails with an explicit error.
• Mod downloads: Modrinth mod downloads are verified against the Modrinth-provided SHA-512 hash (SHA-1 fallback) before writing to the instance directory. Empty or mismatched files are rejected.

The Linux install script (curl … | sudo sh) now fetches a SHA256SUMS manifest alongside the agent binary and verifies the download before it is installed:

• On hash mismatch the download is deleted and the script aborts — the corrupted binary is never installed.
• If SHA256SUMS is unavailable the script prints a warning and continues — this prevents install breakage when the checksum manifest hasn't been published yet for a new release.
• The SHA256SUMS file is served at GET /SHA256SUMS from the release directory on the same host. The deploy step generates it via sha256sum nodemesh-agent-* after building the release binaries.

We think honesty matters more than marketing polish. These are the things we haven't done yet:

• No third-party security audit. NodeMesh has not been audited by an external security firm. We document what we've built accurately; we don't claim ISO 27001, SOC 2, or any certification.
• Windows agent is beta. The Windows agent is in beta and is the one remaining place where PowerShell execution is used. It has not been verified end-to-end on production hardware.
• Agent is not yet open-source. The agent source is planned to be published under an open-source licence after open beta. Until then, you are trusting the binary. The checksum verification above lets you verify the binary you install matches what we published — but you cannot inspect the source yet.

These are the next planned security improvements. None of these are committed to a release date.