Built for a narrow trust boundary.

Last updated: April 2026

Avery NXR is designed so that the cloud side of the product has as little to do with your code as possible. Most of what a normal “AI coding tool” hands to a vendor, Avery NXR keeps on your machine.

Loopback-only service

The local daemon (nxrd) binds to 127.0.0.1:19274. It does not expose a network port. The desktop app is the only client that talks to it, over an authenticated WebSocket.

Signed plugins and updates

Every generator plugin ships as an Ed25519-signed tarball. The daemon refuses to load unsigned or tampered plugins. Desktop app updates ship through the same signed channel — the Tauri updater verifies the manifest against the pinned public key.

Credential handling

• BYOK API keys live only in the OS keychain — Keychain on macOS, DPAPI on Windows, Secret Service on Linux. They never transit our servers.
• License signing keys (Ed25519) exist only in the central server runtime. Rotating them requires a desktop update so the new public key is pinned before the private key changes.
• The Tuning Bench and Plugin Forge use distinct signing keys so the blast radius of a single-key compromise stays bounded.

Data boundary

Consult Mode requests go direct from your machine to the frontier provider you picked with your BYOK key. The central server is not a proxy. We cannot read what you send or what comes back, because it never touches our infrastructure.

Telemetry

Opt-in and schema-bounded. The Zod schema that guards the /api/telemetry/ingest endpoint uses .strict() — any field name not on the allow-list is rejected at the boundary. No prompts, no file paths, no user identifier.

Vulnerability disclosure

If you think you've found a security issue, email support@avery.software. We publish an acknowledgement within 48 hours and we credit reporters unless you prefer otherwise.