Security & trust

Know which protection is doing the work.

Nyx AI reduces the risk of model-run actions; it does not make an untrusted computer safe. The user, the operating system and the settings you configure in the app are trusted. The model, repository content, remote content and connected services are the main adversarial inputs.

The four isolation levels, and the off switch

The AppContainer launch check performs a live allowed-write and denied-write sample. That is evidence about the sampled write boundary, not proof that every path or future Windows condition is contained.

Automatic

Tries Windows AppContainer when its live launch check passes. It may fall back to Standard if AppContainer is unavailable or a launch fails — but not for a window you consented to, and not when a sandbox-permission cleanup cannot be proved, where the command is refused instead. Briefly at start-up, and on a machine where neither backend can be created, a screened command can run with command and path screening only and no OS jail — the tier badge, not the setting, is what tells you which level actually ran.

Standard

Uses command and path screening plus best-effort Job-Object resource and lifecycle limits. If those limits cannot be applied, execution may continue under the always-on floor and be reported as degraded. It is not a filesystem or network jail.

Sandbox + internet / no internet

Uses AppContainer, the stronger OS-enforced write boundary. Explicit Sandbox levels fail closed instead of silently using Standard. The network choice applies to the contained child, not every app feature.

Isolation off

Runs shell with your ordinary Windows account permissions and no raw-command path screening. Brokered file-tool path checks, risk screening and approval rules still apply, and AI-written Python and the built-in CSV analysis raise a native Windows confirmation before they run in this state: the Python dialog shows the exact code, and the CSV dialog names the exact file or data.

AppContainer controls where contained code can write; it is not a promise that everything outside your workspace is unreadable. No sandbox is 100%.

Approvals and their bounded exceptions

Everyday approvals

Default can run eligible low-risk writes and shell commands automatically and asks before higher-risk ordinary model-issued actions. Auto-accept accepts more and Bypass asks least. Enabled Auto-verify can run its documented screened commands without another per-command prompt; the guided Build pipeline would use a similar path, but it has no entry point in the current free interface. Outside a Sandbox isolation level, one native Allow for repository-controlled execution covers later commands in that category in the same workspace for the rest of the app session, including later model-issued commands; high- and critical-risk commands keep their own confirmation. This approval control is separate from automatic model routing. Review proposed edits and commands even when they look routine.

Native Windows confirmations

High- and critical-risk model-authored shell commands use a separate Windows dialog or are refused. Other designated sensitive actions require a fresh one-shot decision in the app unless that operation has its own native gate. The model cannot approve either kind of prompt.

The always-on floor also contains brokered file-tool workspace path checks, a hard command blocklist, risk classification, secret-environment scrubbing and screening for recognised references to many common credential-store paths. With isolation off, raw shell and Python paths are not screened. Pattern screening is a floor, not proof that every dangerous command was recognised.

What can leave the device

Choosing Sandbox · no internet seals the contained child process. It is not, however, an air gap for the whole app, and the gap is wider than the level's name suggests: the default-on update check, a dependency install you approve, and the one-time component downloads Nyx AI needs all still reach the network, and cloud code indexing keeps flowing once you have set it. For a real air gap you need local models and no networked integrations, previews or tasks as well as that level.

A previewed page can load remote images or scripts like any browser view, so close previews when you want a strict air gap. The preview window sits outside Allow internet access for AI-run code deliberately: that switch reaches the model-driven side of previews, not the window in front of you.

Local models: a loopback Ollama model can keep model prompts on this PC. A remote Ollama address, an Ollama model tagged :cloud or -cloud, or a direct cloud provider is off-device. Auto normally prefers configured cloud routes for heavier roles; Prefer local has cloud fallback.

Other features: web research, remote images, HTTP/SSE MCP servers, update checks and other integrations make their own network requests. Language servers run outside AppContainer with your user permissions. Eligible local MCP, hook or plugin children can optionally use the active execution backend; remote MCP services cannot be contained by a local process sandbox. Some language-server setups may download a pinned component, and package-runner MCP configurations may fetch a runner. A preview can also be shared to devices on your Wi-Fi through a token link, but only after a native Windows confirmation you approve for that specific preview, and the listener expires.

Telemetry: Nyx AI sends NYX LIMITED no product usage telemetry, analytics or crash reports. The update check is on by default, can be disabled, and sends the app version while exposing the ordinary request IP to the update host.

Sanitizer: when enabled, the outbound model-text sanitizer tries to remove recognised secrets. The default secrets-only setting does not remove ordinary emails, phone numbers, everyday file paths or IP addresses, though your workspace and allowed-folder path prefixes are replaced with <workspace>. Images, web requests and MCP traffic follow their own controls.

The runaway-loop checkpoint

One checkpoint lives in the interface rather than in Windows: after an unusually long run of tool calls in a single chat, Nyx AI stops and asks whether to continue, and each approval extends the run by a further block. It is a checkpoint, not a hard ceiling. It exists to catch a runaway loop, not to bound what an approved task can do.

What runs outside the sandbox

The app itself, previews, document rendering and language servers run with your Windows account permissions. Trusted project toolchains and repository scripts may execute project code. Trust only workspaces and integrations whose code you are prepared to run, keep backups, and close previews when you want a strict air gap.

Local records and deletion

Logs and history

Chats and the Action log are local plaintext under your Windows account. The optional Forensic log is encrypted and hash-linked, but the key is on this machine, so it is a self-check rather than evidence for an adversarial party. Neither log proves that every external effect was observed.

Delete all my data

A native confirmation removes app-owned settings, chats, memory, logs and recorded workspace state. It does not stop at the workspace you have open: it clears those folders in every workspace this installation has recorded you opening, from a full list rather than the short recent-workspaces menu, so a project you opened once and never returned to is covered too. Project source outside the listed app-owned folders is not deleted. Locked or unknown old workspace data can remain, and the app reports known residues instead of claiming a perfect wipe.

Limits, plainly

  • Prompt injection is not solved. Treat fetched pages, files, tool output and model replies as untrusted.
  • Nyx AI does not defend against a hostile operating system, administrator, logged-in user or same-user malware.
  • It is proprietary beta software, has not yet been independently audited, and AI output can be wrong, incomplete or insecure.
  • Windows 10 or 11 x64 is supported; Windows on ARM, macOS and Linux are not supported, distributed or tested.

Fixed, and recorded here rather than dropped: releases up to Nyx AI v1.5.451 had known non-shell gaps in a compound Automatic policy-barrier state, where model-authored Python and the automatic TypeScript and refactor validation helpers could miss a barrier that shell already enforced. v1.5.452 closed those gaps, and they remain closed in v1.5.493.

Stop remains a user-control backstop rather than instantaneous revocation: a process that survives termination is reported as still running rather than assumed dead, and a job you explicitly launched in the background keeps its documented independent lifetime. Prefer an explicit Sandbox level, review approvals and keep backups rather than relying on Stop alone to contain code you have already approved.

Report a vulnerability

Please email customerservice@nyxlimited.com with the subject “SECURITY”. If details are sensitive, make first contact without them and we will arrange a channel.