Updated: v0.29.0 · 6 providers + plugins · 4 notification channels + digest · 5 security headers · Rate limiting

• No programmatic account switching (see "Why Not Account Switching" below)
• Provider and notification secrets are stored in the OS credential manager by default; SQLite keeps only opaque references unless the operator explicitly enables the insecure plaintext fallback
• No telemetry, analytics, or phone-home
• Core Niyantra writes stay inside its own database directory; operator-trusted plugins can read/write anywhere their subprocess permissions allow

• niyantra snap: 1 HTTP POST to https://127.0.0.1:{port} (self-signed TLS, local LS)
• niyantra serve: Binds HTTP server on localhost:9222 (configurable)
• niyantra mcp: stdio only, no network
• niyantra status: 0 network calls (reads from SQLite)

• Codex: HTTPS to auth0.openai.com (OAuth token refresh) + OpenAI API
• Cursor: HTTPS to cursor.com/api/usage
• GitHub Copilot: HTTPS to api.github.com (billing endpoints)

• SMTP: TCP to configured SMTP server (plain/STARTTLS/TLS)
• Webhook: HTTPS POST to configured endpoint (Discord/Telegram/Slack/ntfy)
• WebPush: HTTPS POST to push service (Chrome FCM, Firefox autopush, etc.)

Note: All external network calls are opt-in and disabled by default. The dashboard works fully offline with only Antigravity LS detection.

The Antigravity language server uses a self-signed certificate. Niyantra connects with InsecureSkipVerify: true because:

1. The connection is to 127.0.0.1 (localhost only)
2. The CSRF token provides request authentication
3. The alternative (no TLS) would be less secure

Config keys containing secrets are masked before API transmission. When returned via GET /api/config or PUT /api/config response, the actual values are replaced with "configured".

Plugin config keys matching these suffix patterns are automatically masked: _api_key, _token, _secret, _password, _pat, _credential

For example, plugin_weather_api_key is masked automatically.

All HTTP responses include the following security headers:

Every /api/* and HTTP /mcp request requires Authorization: Bearer <dashboard_api_token>. niyantra serve creates the token with cryptographic randomness if missing and prints a tokenized first-open URL; the frontend stores the token in sessionStorage and strips it from the address bar. Use niyantra token show to print the current token and niyantra token rotate to invalidate old browser/API sessions. /healthz and static UI assets are intentionally unauthenticated.

Optional HTTP basic auth via --auth user:pass flag or NIYANTRA_AUTH environment variable can be layered on top for dashboard access. No cookie session is created. Basic auth is per-request and not confidential over plaintext HTTP.

Non-local Bind Gate: Niyantra binds to 127.0.0.1 by default. To bind a non-loopback address you must opt in with --allow-remote / NIYANTRA_ALLOW_REMOTE=true, enable --auth user:pass, and acknowledge TLS termination with --behind-https-proxy / NIYANTRA_BEHIND_HTTPS_PROXY=true. Basic auth is only an HTTP authentication scheme; it is not confidential over plaintext HTTP. Streamable HTTP MCP follows the same non-local bind policy.

Per-IP in-memory token bucket rate limiter protects all mutation endpoints from abuse:

When exceeded: 429 Too Many Requests with Retry-After header. Zero external dependencies — uses sync.Mutex + background cleanup goroutine (stale buckets cleaned every 5 minutes).

PUT /api/config validates values against their declared schema types before persistence:

Rejects malformed input with 400 Bad Request and a descriptive error message.

• All operational data is stored in a single SQLite file (default: ~/.niyantra/niyantra.db)
• Provider and notification secrets are stored in the OS credential manager by default via go-keyring
• SQLite stores opaque secret references rather than plaintext credentials unless --insecure-plaintext-secrets / NIYANTRA_INSECURE_PLAINTEXT_SECRETS=true is explicitly enabled
• Database backups created by niyantra backup or POST /api/backup/create redact sensitive config values from the copied SQLite file, including dashboard_api_token, provider credentials, notification secrets, and plugin keys matching sensitive suffix patterns
• WebPush VAPID keys auto-generated on first subscribe (P-256 ECDSA)
• Plugin API keys follow the same keychain-backed storage path as other secrets when their config key suffix matches the supported secret patterns

Plugins are operator-trusted local scripts, not a sandbox or marketplace boundary. Discovery rejects oversized manifests, manifest symlinks, and entry points that resolve outside the plugin directory. POST /api/plugins/{id}/run is retained only as a compatibility stub and returns 410 Gone; it never spawns a process. Plugin polling still requires explicit --enable-plugins / NIYANTRA_ENABLE_PLUGINS=true.

When cloud sync is enabled (opt-in):

Every snapshot is tagged with:

• capture_method: manual or auto
• capture_source: cli, ui, or server
• source_id: which data source produced it
• captured_at: timestamp

This creates an audit trail — you can always verify how and when data entered the system.

If you discover a security issue, please email security@bhaskarjha.com rather than opening a public issue.

Niyantra deliberately avoids any feature that programmatically switches IDE accounts. This is a safety decision:

• Google's Trust & Safety systems use AI-driven anomaly detection that flags programmatic OAuth/RPC manipulation (e.g., registerGdmUser, automated token injection) as "botting" or "malicious behavior"
• The punishment is account-wide: a flagged violation can result in suspension of the user's entire Google account (Gmail, Drive, Calendar, YouTube — not just the IDE service)
• Competitors that offer switching (e.g., AG Switchboard's one-click account switch) expose users to this risk by injecting OAuth credentials into the Language Server process
• Niyantra's principle: "Observe, never act" — we read quota data, we never write to or manipulate external services

This applies equally to:

• Proactive token refresh (automated credential management)
• IDE account auto-sync (detecting and reacting to external switches)
• Any feature requiring registerGdmUser or similar RPC calls