Security

Neondeck is local-first, not zero-trust. The server is a trusted local application that can hold provider credentials, call GitHub, inspect registered repositories, run scheduled work, and—when enabled—execute commands. The browser is an operator surface over that trusted process.

The practical security model is layered: keep secrets server-side, expose only bounded model capabilities, require confirmation or approval for sensitive effects, bind autonomous delivery to current facts, and preserve an audit trail. See safety and sandboxes for the detailed boundary of each work surface.

Local trust boundary

The dashboard and local API are intended for the person using the machine. Mutating requests are protected by local-origin checks, but Neondeck does not provide a complete multi-user authentication, authorization, or internet-facing deployment layer.

Do not expose the local server directly to an untrusted LAN or the public internet. If remote access is required, place it behind your own authenticated transport and treat agent-submission inspection, reports, and runtime state as sensitive.

Authenticated reverse proxies may be allowlisted with exact server.trustedOrigins entries in runtime-home config.json. This extends the operator trust boundary to those browser origins; it does not provide user accounts, authorization roles, or an authentication layer.

Secrets and credentials

Provider keys, GitHub tokens, SSH credentials, and connected-service tokens stay in the server environment or protected runtime state. Ordinary settings refer to secret variable names rather than storing secret values. The browser receives sanitized operational data, not the underlying provider or GitHub credential.

ChatGPT OAuth credentials are stored in data/neondeck.db. Before credential access, Neondeck restricts the runtime data/ directory to the current user and protects the database plus existing WAL and shared-memory sidecars on POSIX systems. OAuth tokens are never sent to the browser.

Do not place secrets in agent personality text, runtime skills, prompts, memories, scheduled instructions, or dashboard settings. Those surfaces can enter model context or appear in audit and inspection views.

Registered repositories

Registering a repository grants Neondeck deliberate, bounded access to that checkout. Chat-side file operations use relative paths, containment and symlink checks, denied-path rules, stale-write protection, worktree locks, and audit events. Autonomous changes are directed to managed worktrees rather than the primary checkout.

A managed worktree is an isolation boundary between coding tasks, not a security boundary between Neondeck and the operating system. The current Autopilot owner shell runs as the local Neondeck user and must be treated as trusted host code.

Commands and approvals

Direct local or VM commands use a separate policy. Preapproved commands run immediately, other interactive commands require operator approval, and commands submitted as unattended are limited to preapprovals. Hardline destructive patterns remain blocked. Approval resolution is operator-owned; the model cannot approve its own request.

Keep manual approval enabled unless the machine and all model-visible instructions are fully trusted. Disabling approvals does not turn the local backend into a sandbox—it broadens what the trusted host process may execute.

GitHub and external delivery

GitHub facts and mutations run server-side. Watched-PR Autopilot keeps coding authority separate from delivery authority: prepare modes cannot push, approval mode can deliver only from an exact current reviewed-revision approval through Active Watches or the typed API, and autonomous mode receives narrowly bound push and response capabilities. Generic owner messages never approve delivery.

Before an autonomous push, Neondeck rechecks the current PR head, destination, permissions, identity, clean committed worktree, and watch authority. Delivery is non-force and expected-head guarded. If the outcome becomes uncertain, Neondeck blocks and retains the local commit instead of guessing or repeating the effect.

PR review

Model-assisted PR review is read-only and revision-bound. It can inspect bounded evidence and create a local briefing or draft findings, but it cannot edit the repo, submit a review, choose a GitHub verdict, reply to a thread, or resolve one. Those actions remain human-owned dashboard controls.

Scheduled work

Scheduled occurrences are claimed, recorded, and run as bounded work. They do not receive a mounted host workspace by default, but general scheduled instructions can still use permitted Neondeck or connected service capabilities. The default fresh-session target cannot use the normal interactive commit or push path; a task explicitly attached to an existing agent session inherits that session's linked context and authority. Keep scheduled instructions narrow, review their result history, and do not assume “background” means “read-only.”

Briefings are explicitly informational. They are instructed not to mutate external systems and must continue with partial data when a source is unavailable, denied, logged out, or waiting for approval.

Connected services

Connected tool calls have their own allow, ask, or deny policy. An approval is bound to the specific server, tool, and arguments; changing that scope invalidates it. Tools and returned content should be treated as untrusted external input even when the connection itself is authenticated.

Skills, memories, and prompt overrides

Runtime skills, durable memory, and full prompt overrides can strongly influence model behavior. They cannot add a server-side capability that was not supplied for the current turn, but they can change how the model uses capabilities it already has. Treat changes to these surfaces as trusted local configuration and review learned skill patches before applying them in sensitive environments.

Inspection and audit data

Conversation history, agent submissions, app-operation records, command records, tool arguments, reports, diffs, and output previews may reveal source code, paths, prompts, or operational details. Output redaction catches some common token formats but is not a general secret scanner. Keep runtime storage and inspection views private, and rotate a credential if it is ever exposed to model context or logs.