BYOK requests go directly to the provider
With your own API key configured, requests travel from your device to the model provider without passing through any Neox server. The data path is independently verifiable by network inspection.
Limits enforced server-side
Billing, quota, and plan limits are determined on the server, never by trusting the client.
Credentials stored only on your device
Login credentials and API keys are stored locally with AES-256-GCM. The encryption key is bound to the device, so the file cannot be decrypted elsewhere. The encryption key never leaves the device.
Signed requests, replays rejected
Every request your device sends to the model gateway carries an HMAC-SHA256 signature. Modification on the network path breaks the signature, and replayed requests are rejected.
End-to-end encrypted device link
When a phone mirrors a desktop session, the content is end-to-end encrypted with X25519 ECDH and AES-256-GCM. The relay handles ciphertext only.
Isolated desktop UI
The desktop interface layer has no file or system access, and neither do the previews and web pages it opens. Every privileged action goes through a fixed allowlist.
Command execution confined by the OS sandbox
In Work mode, commands run by the agent are confined to the current working directory by the operating system sandbox. Coding mode can enable it manually.
Transport security
Every request from your device to the model gateway is signed. Captured requests cannot be altered or replayed.
Request signing
Every request the desktop app and CLI send to the model gateway carries an HMAC-SHA256 signature covering the full request body. A modified request fails signature verification and is rejected by the gateway. The signing key is not transmitted over the network. Mobile uses device-bound token authentication.
Replay protection
Each request carries a one-time value and a timestamp, so a repeated request is detected and rejected. The time window tolerates normal clock drift; no manual clock sync is required.
Credential storage
Login credentials and API keys are stored encrypted on your device, never in plaintext.
Encryption
AES-256-GCM before anything touches the disk, with file permissions that restrict access to your account only.
Device binding
The encryption key is derived with scrypt from an identifier for your machine, so credentials only decrypt on the device that wrote them. A copied credential file cannot be used on another machine.
Separate per app
On the same machine, the CLI and the desktop app keep their own credentials and never read or overwrite each other. You can sign in to just one.
Command execution
Whether the agent asks before running a command or editing a file depends on the approval level you choose.
Approval levels
Three levels: Manual asks before anything other than reading; Auto (the default) asks only before critical operations such as deleting system directories, formatting disks or writing shell startup files, and runs everything else; Dangerous never asks. You can switch at any time.
Dangerous level
With this level on, the agent runs every command without asking, including irreversible ones. Use it only in disposable environments, with version control and backups.
OS-level sandbox
Always on in Work mode. Filesystem and network reach are limited by the operating system itself (macOS Seatbelt / Windows AppContainer / Linux bubblewrap), not by the app deciding what to allow. Coding mode is off by default and can be enabled in your
configuration.
Desktop isolation
The desktop interface layer is pure UI. It cannot read or write files, and it cannot execute commands.
Interface process
Electron's contextIsolation and sandbox are on and nodeIntegration is off. Web pages the agent opens for preview run under the same isolation.
Allowlisted privileged actions
The interface layer can only invoke an explicitly enumerated list of actions. There is no channel that runs arbitrary code.
Data and privacy
We do not train models on your code or conversations, and we do not sell them.
Subscription mode
Requests are forwarded through the Neox gateway to the upstream model provider. We do not store conversation content; we keep only the metadata needed for metering and troubleshooting: model, token counts, time, status code, IP address and client details. Upstream providers handle requests under their own data policies, and some models are served by providers outside the United States (including in China).
BYOK mode
When you supply your own API key, requests go straight from your device to the model provider you configured, without passing through Neox. BYOK is free.
Log retention
Request logs are kept for 30 days for troubleshooting and billing checks, with prompt content stripped by default. They are deleted automatically after that.
Cloud session sync (optional)
With sync on, the cloud holds only a session index; full message bodies are not retained long term. Phone-to-desktop mirroring is end-to-end encrypted, so the relay cannot see the content.
Local data
Session history, tool call records, and agent memory are stored locally by default and removed when deleted.
Third-party extensions (MCP)
An MCP server is a separate program you install yourself, and it is not constrained by the Neox sandbox. Install MCP servers only from trusted sources.
Run privileges
An MCP server runs as your user account. Its behavior depends on that program and is outside Neox isolation.
Must be enabled explicitly
Installed MCP tools are unavailable to the agent until enabled.
Secrets stay out of prompts
Environment variables you configure for an MCP server are passed to that program only. They never appear in the prompt sent to the model.
Threat model: scope and limits
The boundaries of what Neox protects against.
In scope
Request tampering on the network pathRequest replayOther local processes reading credentialsA stolen disk or copied credential fileThe desktop UI layer reaching your filesClient-side quota and billing tampering
Out of scope
An attacker who already has code execution on your machineVulnerabilities in an MCP server itselfCommands you approved, and commands that run without approval under the Auto or Dangerous level
Credentials are bound to the device to protect against a copied disk or file. An attacker who already has code execution on your machine is out of scope. MCP servers and approved commands run with your permissions.
