Security

Security at NeuronGate

You send us prompts and hold a balance with us, so this page lists the specific controls that protect them, and says plainly where a control stops. It describes what the running system does, not an aspiration.

Overview

Prompts aren't logged

Usage logs hold metadata only: model, tokens, cost, latency, status.

Keys stored as hashes

256-bit random keys, shown once, kept only as SHA-256 hashes.

Two-factor sign-in

TOTP with single-use backup codes; mandatory for admins.

Strict browser policy

Per-request nonce CSP on signed-in pages; framing blocked everywhere.

Verified payments

Every payment callback is HMAC-checked; we never touch card data.

Audited admin actions

Admin access needs 2FA, and sensitive actions are logged.

Your request data

A request passes through the gateway to the model provider and back. Here is what is kept along the way:

  1. 01

    Your app

    Prompt sent over TLS

  2. 02

    NeuronGate

    Checks key and balance; forwards allowed fields only

  3. 03

    OpenRouter

    Routes to a provider hosting the model

  4. 04

    Model provider

    Generates the completion

Where request data goes
What NeuronGate stores about a request
DataStored?Details
Prompt and completion textNoNot written to usage logs, application logs or error reports.
Request metadataYesModel, token counts, cost, latency, status, request id and time. Powers your logs and invoices.
Provider error messagesYes, if a request failsThe provider's error text, up to 500 characters, so you can see why it failed.
Idempotent responsesOnly if you askWith an Idempotency-Key header, the response is kept 24 hours to answer retries, then deleted.
Your request headersNoNot stored and not forwarded upstream.

To serve a request we send it to OpenRouter, which forwards it to a provider that hosts the model. Their handling of request data is governed by their own policies; see the privacy policy for the full list of processors.

The console stays in your browser

Conversations in the web console are saved in your browser's local storage (the last 20), not on our servers. Clear them from the console or by clearing site data.

API keys

API key protections
ControlHow it works
Generation256 bits from a cryptographic random source, formatted sk-ng-…
StorageOnly a SHA-256 hash and an 8-character prefix for display. We can't show you a key again.
Shown onceThe full key appears only in the response that creates it.
Monthly spend capOptional per key. Requests that would exceed it are refused with 402.
Model allowlistOptional per key: up to 50 model ids; anything else is refused.
RevocationImmediate. A revoked key fails on its next request.
Rate limit60 chat completions per minute per key.
Requires a verified accountKeys of an account with an unverified email don't work.

Creating a key sends a notification email, so a key you didn't create doesn't go unnoticed.

Accounts and sign-in

Account protections
ControlHow it works
PasswordsHashed with bcrypt (cost 12). At least 8 characters with upper and lower case and a digit.
Brute-force protection10 failed sign-ins for an email within 15 minutes locks further attempts; sign-in, sign-up and reset are also rate-limited per IP.
Two-factor authenticationTOTP from any authenticator app, with 10 single-use backup codes shown once. Repeated wrong codes lock verification for 15 minutes.
Email verificationRequired before keys work. 6-digit codes expire after 15 minutes.
Password resetSingle-use links valid for 1 hour. The token is in the link's fragment, so it isn't sent to servers or logged. A reset signs out every session.
SessionsShort-lived access tokens (15 minutes) held in memory, refreshed by an httpOnly, Secure, SameSite=Strict cookie scoped to sign-in endpoints.
Ending sessionsSigning in on a new device doesn't end older sessions, and they can't be ended one at a time. Signing out, Sign out everywhere in Settings, or a password change ends every session at once.
Deleting an accountDeactivates it straight away: sign-in is refused and every API key stops working. Full erasure of personal data is by email request.
Security emailsSent for sign-ins from a new IP, password changes, 2FA changes and new API keys.

Two-factor secrets are stored encrypted. Administrator accounts can't use the dashboard until 2FA is set up, and can't turn it off.

Transport and browser security

  • TLS 1.2 and 1.3 only. Plain HTTP redirects to HTTPS, and HSTS tells browsers to use HTTPS for a year, including subdomains.
  • Content Security Policy. Signed-in and sign-in pages get a fresh nonce on every request and run only scripts carrying it. No page can be framed by another site.
  • Headers. nosniff, a strict referrer policy, and camera, microphone and location access disabled.
  • CORS. The dashboard API answers only our own site. The /v1 API is for servers and is authenticated by key.
  • Rate limiting at the edge (per IP) and in the application (per IP and per key).

Payments

Top-ups are crypto payments processed by NOWPayments. We never see or store card details because there aren't any. A payment is credited like this:

  1. 1

    You create a payment

    We record the USD amount and ask NOWPayments for a deposit address.
  2. 2

    NOWPayments confirms it

    It calls our webhook signed with HMAC-SHA512. We check the signature in constant time and reject callbacks older than 10 minutes.
  3. 3

    We credit the recorded amount

    The payment row is locked while it's processed, duplicate callbacks are ignored, and the amount credited is the one we recorded, never a figure taken from the callback.

Infrastructure

  • Only the web server is reachable from the internet. The database, cache and application run on a private network.
  • Application containers run as unprivileged users.
  • Secrets are supplied at deploy time, and production refuses to start with a default or weak secret key.
  • Administrator access requires 2FA, and sign-ins, key, payment and admin actions are written to an audit log.
  • Error reports are scrubbed of keys, tokens, emails and cookies, and never include request bodies.

Your checklist

  1. 1

    Turn on two-factor authentication

    In Settings, and store the backup codes somewhere safe.
  2. 2

    Use one key per app or environment

    Revoking one then doesn't break the others, and logs show which app spent what.
  3. 3

    Cap and restrict each key

    Give it a monthly spend cap and an allowlist of the models it needs.
  4. 4

    Keep keys server-side

    Never ship a key in a browser or mobile app; call NeuronGate from your backend.
  5. 5

    Rotate when people leave

    Create a new key, deploy it, then revoke the old one.

Reporting a security issue

Found a vulnerability? Email privacy@neurongate.net with "Security report" in the subject, steps to reproduce and the impact you expect. Please give us a reasonable time to fix it before disclosing it, and don't access other people's data or degrade the service while testing.

FAQ

Do you train models on my data?

No. We don't keep prompts or completions, so there's nothing to train on. The model provider that serves a request handles it under its own terms.

Can NeuronGate staff read my prompts?

Prompts and completions aren't stored, so there is nothing to read. The one exception is opt-in: a response cached for 24 hours because you sent an Idempotency-Key. Staff can see request metadata (model, tokens, cost, status) to support your account.

What happens if my API key leaks?

Revoke it in API keys; it stops working on the next request. A monthly spend cap on every key limits what a leaked key can cost you in the meantime.

Are you SOC 2 or ISO 27001 certified?

Not at this time. This page describes the controls we do run; we'll say so here when that changes.