NSP Production Readiness Checklist: Security and Reliability

​

Section 1 — Security

• Enable API key authentication.
  Open C:\ProgramData\Nelieo\axon.toml and confirm the [auth] section requires a key:
  [auth]
  require_key = true
  keys_file   = "C:\\ProgramData\\Nelieo\\axon_keys.json"
  
  Generate your production key from platform.nelieo.com. Never set require_key = false outside of a fully isolated development machine.
• Bind only to localhost.
  The host field controls which network interface the daemon listens on. In production it must always be 127.0.0.1. Setting it to 0.0.0.0 exposes the daemon to every network interface on the machine, including any that are publicly reachable.
  [server]
  host = "127.0.0.1"
  port = 7842
  
• Disable wildcard CORS.
  If you have any dashboard or browser-based tooling that calls the daemon, enumerate those origins explicitly. Never allow all origins.
  [cors]
  allow_all_origins = false
  allowed_origins   = ["https://your-dashboard.example.com"]
  
• Store API keys in environment variables, not in source code.
  The Python SDK reads NSP_API_KEY automatically:
  # Set in your deployment environment, CI secrets manager, or Windows credential store
  set NSP_API_KEY=nsp_live_sk_a1b2c3d4e5f6789...
  
  # No key in code — the SDK picks it up from the environment
  async with nsp.NSPClient() as client:
      session = await client.attach("Gmail")
  
• Rotate keys regularly.
  Visit platform.nelieo.com to issue a new key, update your deployment environment, then revoke the old key. The daemon’s in-memory verification cache will invalidate the revoked key within seconds.

​

Section 2 — Reliability

• Install the daemon as a Windows Service with automatic startup.
  Run the following command once from an elevated (Administrator) terminal:
  axon-daemon.exe install
  
  This registers the NSPDaemon service with start type Automatic, which means it comes back on every reboot without any manual intervention.
• Configure service recovery actions.
  The installer sets sensible defaults (restart after 30 s, 60 s, then 120 s), but you should verify these are in place or tune them to your requirements:
  sc.exe failure NSPDaemon reset= 86400 actions= restart/30000/restart/60000/restart/120000
  
  The reset= 86400 argument resets the failure counter after 24 hours of clean operation.
• Set min_confidence to 0.4 or higher.
  This prevents the daemon from wasting resources tracking processes it cannot reliably identify. The default is already 0.4 — confirm it has not been lowered:
  [watcher]
  min_confidence = 0.4
  
• Tune poll_interval_secs for your latency needs.
  The default of 2 seconds is the right balance for most production workloads. Lowering this value increases CPU load on the host; raising it increases the staleness of cached state. Adjust only if you have a specific latency or resource budget.
  [watcher]
  poll_interval_secs = 2
  
• Poll GET /health from your monitoring system.
  The health endpoint returns a lightweight JSON payload and never requires authentication. Add it to your uptime monitor or Nagios/Datadog check:
  curl http://localhost:7842/health
  
  {
    "status": "ok",
    "version": "1.0.0",
    "uptime_secs": 3600,
    "tracked_processes": 3,
    "auth_enabled": true
  }
  
  Alert on anything other than "status": "ok".

​

Section 3 — Agent Safety

• Require verify_expression for all irreversible_write actions.
  Any action whose schema has "reversibility": "irreversible_write" — such as send_reply, delete_permanently, or submit_form — must be called with a verify_expression that confirms the action actually took effect. The daemon rejects the call with 400 missing_verify_expression if you omit it, but your code should be explicit regardless:
  result = await session.execute(
      "send_reply",
      parameters={
          "thread_id": thread_id,
          "body": "Thanks, I'll review this shortly.",
      },
      verify=True,
      verify_expression="inbox.sent_count > 0",
  )
  
• Tune verify_timeout_ms to match your app’s response time.
  The default verification timeout is 5 000 ms. If your target application is slower (for example, a Salesforce form that takes 8 seconds to confirm), raise this value. If it is faster, lower it to fail quickly:
  {
    "action": "send_reply",
    "parameters": { "..." : "..." },
    "verify_expression": "inbox.sent_count > 0",
    "verify_timeout_ms": 8000
  }
  
• Test your agent on a staging environment before production.
  Run your agent against a staging instance of the target app with non-production data. Confirm that every irreversible_write path behaves as expected and that verify_expression values match real post-action state.
• Handle NSPVerificationFailedError correctly — do not retry blindly.
  When you receive this error it means the action executed but the post-action state did not match your verify_expression. The action may or may not have succeeded in the application. Retrying immediately risks a double-execution. Log the error, inspect the state manually, and alert a human if necessary:
  try:
      result = await session.execute("send_reply", ...)
  except nsp.NSPVerificationFailedError as e:
      # The action ran — do NOT retry automatically.
      logger.error("Verification failed after send_reply: %s", e)
      alert_human(e)
  
• Handle NSPRateLimitError with exponential backoff.
  The daemon enforces 10 action executions per second per API key by default. Bursting past that limit returns a 429 which the SDK surfaces as NSPRateLimitError. Back off exponentially and add jitter:
  import asyncio, random
  
  async def execute_with_backoff(session, action, params, max_attempts=5):
      for attempt in range(max_attempts):
          try:
              return await session.execute(action, parameters=params, verify=True,
                                           verify_expression="inbox.sent_count > 0")
          except nsp.NSPRateLimitError:
              if attempt == max_attempts - 1:
                  raise
              wait = (2 ** attempt) + random.uniform(0, 1)
              await asyncio.sleep(wait)
  

​

Section 4 — Monitoring

• Poll GET /health from your monitoring system.
  If you have not done this under Reliability above, do it now. This endpoint is unauthenticated by design so your monitoring agent does not need a key.
• Configure Windows Event Log monitoring.
  The daemon writes all significant events — startup, shutdown, probe errors, auth failures — to the Windows Application event log under the source NSPDaemon. Point your log aggregator (Splunk, Datadog Agent, Elastic Agent, etc.) at this source, or set up a manual alert:
  # View the last 50 NSPDaemon events
  Get-EventLog -LogName Application -Source NSPDaemon -Newest 50
  
  In Event Viewer: Windows Logs → Application → Filter Current Log → Source: NSPDaemon.
• Use level = "info" in production — not "debug".
  Debug logging is verbose and will fill your log storage quickly. Set the level to "info" unless you are actively investigating a problem:
  [logging]
  level  = "info"
  format = "json"
  
• Use format = "json" for structured log ingestion.
  JSON-formatted logs can be parsed, filtered, and indexed by any modern log aggregator without custom grok patterns. The "text" format is human-readable but unstructured — reserve it for local development:
  [logging]
  format = "json"
  

​

Production axon.toml Reference

[server]
host = "127.0.0.1"
port = 7842

[auth]
require_key = true
keys_file   = "C:\\ProgramData\\Nelieo\\axon_keys.json"

[cors]
allow_all_origins = false
allowed_origins   = []

[watcher]
poll_interval_secs = 2
min_confidence     = 0.4

[rate_limit]
enabled           = true
state_per_second  = 100
action_per_second = 10

[logging]
level  = "info"
format = "json"

[service]
name         = "NSPDaemon"
auto_start   = true