Nexora

Security model

Your workspace stays local. Requests go to the providers you choose. Credentials are stored in the OS keyring, not Nexora's database. This page describes how Nexora handles data, provider requests, permissions, shell execution, and what it cannot guarantee.

Technical diagram

One restrained view of where information goes:

Workspace→local SQLite
Credentials→OS keyring
Requests→provider you choose

Security overview

Nexora is a local-first AI coding workspace. Everything you write - conversations, prompts, attachments, and settings - lives in a single SQLite file on your disk. There is no mandatory Nexora account and no Nexora cloud sync. The network is touched only when you send a request to a provider you configured yourself, and that request is made from the application backend.

What stays local

  • Your workspace. Conversations, prompts, attachments, and settings live in a single portable SQLite file nexora.db in your per-user application-data directory. Copy it, back it up, or delete it.
  • Offline by default. Browsing history, search, and settings changes need no connection. Startup never blocks on the network.
  • Nothing is uploaded until you press send to a provider you chose.

What leaves your device

Only what you explicitly send:

  • The prompt and any attached context you include go to the selected AI provider.
  • Provider API requests are made from the application backend, not from your browser.
  • Provider responses return to your local workspace only.
  • No credentials are sent to a Nexora server. Nexora does not operate a sync or credentials server.

Credentials

Credentials are stored in the OS keyring, not Nexora's database. API keys live in the operating system keyring only - they are never written to SQLite, logs, or error text. Provider requests are signed in the backend. A key that appears in SQLite, logs, or reports is itself a vulnerability.

Agent permissions & approvals

Three autonomy levels - supervised, semi-autonomous (default), and full-autonomous. Approval gates park anything that needs a human decision. Shell commands always require your explicit approval unless you choose full-autonomous mode, where the agent runs to the end without stopping per-action. Every run exposes pause, resume, and cancel controls.

Shell execution

Shell execution is treated as dangerous. It is not a sandbox. Commands run on your machine with your user's permissions. Shell commands require explicit approval in supervised and semi-autonomous modes. In full-autonomous mode, mutating actions may run without per-action approval where current policy permits it. Dangerous shell execution still requires approval.

Prompt injection / untrusted content

Untrusted content can reach the agent through tool output, file contents, or provider responses. Treat tool results and file contents as untrusted input. Review diffs before accepting changes. Be cautious pasting content from untrusted sources into prompts - it can influence agent behavior, including tool calls.

Audit & rollback

Every agent run leaves an append-only audit trail. Run snapshots, checkpoints, and rollback let you review and undo changes. A read-only run inspector shows what happened in each run, and a self-audit gate reviews actions before they execute where policy permits. Git integration - status, log, diff, and explain-diff - helps you review changes before committing.

Application hardening

  • Rust unsafe_code = "forbid".
  • Open-source MIT code: inspect it yourself.
  • Restrictive Content Security Policy (CSP) in tauri.conf.json.
  • No remote crash upload.
  • No conventional remote product telemetry - no telemetry upload anywhere.
  • Error text carries no secret material.

Telemetry & diagnostics

Nexora does not send conventional product telemetry. There is no remote crash upload and no telemetry upload anywhere. Diagnostics stay local. When you report an issue, you choose what to share - never include API keys, tokens, or message content.

Known limitations

  • Selected AI providers receive the prompts and context you send to them.
  • Shell execution is not a sandbox.
  • Nexora can't guarantee the security or privacy of third-party providers.
  • Full-autonomous mode may execute mutating actions without per-action approval where current policy permits it.
  • Dangerous shell execution still requires approval.
  • Open source does not equal an independent security audit.

Threat model

In scope:

  • Approval bypasses, sandbox escapes, and prompt-injection-to-tool-execution paths.
  • Credentials appearing in SQLite, logs, or error text.
  • Mutating shell or file actions running without intended approval.

Out of scope:

  • Provider-side outages and billing (OpenAI, Anthropic, Gemini, OpenRouter, NVIDIA NIM, OpenCode Zen, and custom OpenAI-compatible endpoints).
  • Compromise of your operating system or user account. If your OS is compromised, local keyring protection is limited.

Reporting vulnerabilities

Use GitHub → Security → Report a vulnerability (private vulnerability advisory). Do not open a public issue for anything that could leak data, bypass approvals or permissions, or exfiltrate credentials.

Include: version + OS, what you did, what you expected, what happened, and redacted logs. Never include API keys, tokens, or message content.