Security & Privacy

Where your data lives

NevoFlux is local-first. Your sessions, knowledge base (~/.gbrain/), config, and API keys are stored on your own machine. The agent runs as a local process bundled with the browser.

What leaves your machine: the requests you send to your chosen LLM provider go to that provider, and any MCP servers or web tools you use reach their respective endpoints. With the on-device model active, the LocalOnly guard keeps model traffic on your machine. If you turn on Jev, see what it is sent.

API keys

Keys live in config.toml or in environment variables — NevoFlux does not use an OS keychain. Treat config.toml as a secret file and avoid committing it anywhere.

The agent asks before it acts

How much runs without a prompt is set by Agent execution in Settings → General. It defaults to Read-only: the agent browses, navigates and fetches freely, but anything that changes a site, a file or your machine waits for your approval. Three higher tiers — Browser auto, Browser auto + reads, Full auto — auto-approve progressively more. Raise it deliberately, and read Full auto as "any tool in this conversation may run without asking".

Tools the classifier doesn't recognize are always treated as highest-risk, so a newly added or third-party tool is never auto-approved below Full auto.

Upgrading from before v0.3.13: the old Auto-execute option never took effect, and resets to Read-only rather than becoming Full auto.

The tier is also what a remote-control session inherits — a paired phone can see the tier but cannot raise it. A paired AI agent gets its own tier per pairing, which caps the tasks it delegates.

Work that runs with nobody watching is held to the tier of the session that creates it: loops need Browser auto or Full auto depending on what they run, and creating a schedule needs Full auto (v0.3.16).

The tool gate

Since v0.3.16 every tool call the agent makes — from NevoFlux's own agent loop or from an ACP/CLI provider calling NevoFlux's tools — passes one ordered gate before it runs, in addition to the tier:

1. Pack site rules — deny or ask rules that installed or active packs contribute for particular sites.
2. Pack hooks — a pack's WebAssembly on_tool_pre check, if it ships one.
3. The run's tool list — a loop or scheduled run can only call the tools it was offered.

A refusal anywhere ends the check before anyone is asked, so you are never asked about a call that was going to be refused anyway. A rule that would ask, in a run nobody is watching, refuses instead. Pack rules can only make things stricter — there is no way for a pack to allow what your tier would not.

What the gate does not cover:

• An ACP agent's own tools (for example Claude Code's shell or file editor) run in that agent's process, so NevoFlux sees only their results. A pack rule that refuses a NevoFlux tool does not stop such an agent reaching the same result with its own tools.
• Tool calls made inside an orchestrate script are not yet routed through it.
• A site rule judges the URL a call is aimed at before it runs. A click that redirects into a restricted site is caught from the next call on, not that one.

Packs

A pack installs skills, tools and a dashboard, and a pack-protocol/0.2 pack can also add site rules, a WebAssembly hook, and the right to replace the agent's system prompt while it is active. Before installing, read the pack's pack.toml: the install preview lists skills, canvas tools (and the binaries they run), seed pages, the dashboard and the commands it may send, but does not yet list site rules, hooks or a prompt-replacement mode. Only install packs from sources you trust.

Canvas

• Canvas tools run through a whitelist: no shell, validated parameters, path confinement, output/time limits, and an audit log.
• Canvas artifacts run in a sandboxed iframe, and reach NevoFlux only through the Canvas bridge, which keeps each canvas to its own storage, sessions, shares and tabs, and lets it send only a few read-only daemon commands. A canvas cannot change settings, pairings, accounts, MCP servers or packs.

Command auto-approval

Command auto-approval is governed by the [auth] section of config.toml, including an allowlist and patterns for sensitive files.

Reporting a vulnerability

Please report security issues responsibly via the GitHub repository.