NSP Security: Authentication, Rate Limits, and Safety

The NSP daemon binds to localhost:7842 by default and exposes powerful capabilities — reading live application state and executing typed actions across every tracked process on the machine. That power demands deliberate security configuration. This page is your security reference: a checklist you can verify before going to production, and signposts to the detailed guidance on each layer.

​

Pre-Production Security Checklist

Work through these items before you expose your deployment to any real user or production data. Every item maps to a concrete setting you can verify in your axon.toml or environment.

• Enable API key authentication — set auth.require_key = true (this is the default; verify it has not been overridden)
• Never expose port 7842 to the network — keep server.host = "127.0.0.1" and never change it to 0.0.0.0 without a firewall rule
• Lock down CORS — set cors.allow_all_origins = false and list only the exact origins your agent dashboard needs in cors.allowed_origins
• Always supply verify_expression for irreversible_write actions — the daemon will reject requests that omit it, but build this habit into every agent you ship
• Set appropriate rate limits — lower rate_limit.action_per_second from the default of 10 to whatever your workload actually needs; the tighter the better

​

The Three Security Layers

NSP security is built from three independent, composable layers. Each layer can stop a threat on its own, but all three together give you defense in depth. Authentication is the first layer. Every request must carry a valid X-Substrate-Key header whose value is a key issued on platform.nelieo.com. The daemon verifies keys against the platform and caches the result in memory, so authenticated calls pay sub-millisecond overhead after the first check. A request that arrives without a valid key never reaches your state or actions. Rate limiting is the second layer. Even a fully authenticated API key can only send requests at the rate you configure. The daemon uses a per-key token-bucket algorithm to enforce separate limits on state reads, action execution, and heap snapshots. This protects you from runaway agent loops, accidental denial-of-service, and unexpected cost spikes. Action safety gates are the third layer. Before dispatching any action to a runtime probe, the daemon classifies it into one of three reversibility tiers — read, reversible_write, or irreversible_write — and enforces the conditions for that tier. Irreversible operations require a verify_expression that must evaluate to true against post-action state before the response is returned. An action that fails its safety gate never executes, regardless of whether the caller is authenticated.