Security and key management

• Your agent calls api.routexor.com over HTTPS with a ROUTEXOR key (sk-at-...).
• We hash the key with SHA-256 and look up the digest. Unknown, disabled or known-compromised keys get a 401, and the account must be active.
• The key's rate limit (60 requests a minute by default) and the plan's daily limit are checked. If the store that holds these limits is unreachable, the request is refused with a 503 and never sent to a provider.
• The spend preflight sets an explicit output ceiling, prices the worst case and reserves that amount atomically against the key's monthly cap and the task profile's daily cap.
• We decrypt your provider key for that call, write a vault audit record and call the provider over TLS. Redirects are refused. Google keys travel in a header, never in a URL.
• We record usage metadata and settle the reservation against actual usage.
• If a provider fails before any output, the request can move to the next model in your task profile's fallback chain. A provider rejecting your key returns a 502 to your agent, so agent harnesses fail over to their next model instead of locking you out. Once output has started, we do not switch providers.

• Envelope encryption. Each stored provider key gets its own random 256-bit data key and is encrypted with AES-256-GCM, which also detects tampering. That data key is encrypted with a key-encryption key derived for your account (PBKDF2-SHA512, 100,000 iterations, from a master secret and your account ID).
• The master secret lives in our hosting platform's environment settings, not in code or the database. The API refuses to start if it is missing or shorter than 32 characters.
• Server-side decryption. The API decrypts a provider key only to make a call you requested or a key check you started. This is not end-to-end encryption, and we do not offer keys that only you can decrypt.
• Every decryption writes a vault audit record: account, provider, key ID, IP address and user agent. Each account can read its own vault log through the dashboard API.
• Optional IP allowlist per provider key, checked before decryption. Denials are logged. It matches exact addresses only.
• More than 1,000 decryptions of one key in a day raises an anomaly flag in the log. It flags; it does not revoke.
• Only the last four characters of a key are ever shown back. You can rotate or delete a provider key in the dashboard at any time, and deleting it stops routing on it immediately.
• Your keys only. Since July 28, 2026, customer traffic never falls back to a platform key. With no key for a provider, the call fails with a clear error.

• ROUTEXOR API keys are shown once, at creation, and stored only as a SHA-256 digest plus a short display prefix. A list of known-compromised digests is blocked at authentication.
• Each key carries its own rate limit and an optional monthly dollar cap. A cap of $0 blocks all spend.
• Dashboard passwords are hashed with bcrypt (cost 12). Sign-in attempts are throttled per account, 10 per 15 minutes.
• Sessions are httpOnly cookies backed by a signed token that expires in 7 days. Every request re-checks account state and revocation. Logout, password change and "sign out everywhere" revoke existing sessions.
• Browser changes require an exact trusted Origin. Pages send a strict Content-Security-Policy with a fresh nonce per response, refuse to be framed, and use HSTS.
• Support access: an administrator can open a read-only view of an account for at most 15 minutes. It cannot create credentials, change the account or make paid calls, and each start and stop is written to an admin audit log.

• Enforced today: a per-call output ceiling, a monthly dollar cap per ROUTEXOR key and a daily dollar cap per task profile. All are checked before the call is sent.
• The worst-case price of each call is reserved atomically before dispatch, so a burst of parallel calls cannot all slip past a cap that only one of them fits under. The price envelope includes long-context, cache-write and peak-rate pricing. Reservations settle to actual usage afterward.
• Fail closed: invalid limits, corrupt counters, missing reservation state or an unreachable limit store refuse the request instead of letting it through.
• Limits of this design: the reservation is based on catalog prices and a token estimate, so it is not a guarantee about your provider invoice. Provider-side tools, image billing or a provider ignoring an output limit can cost more. Counters live in Redis with 40-day retention and are not a durable financial ledger. Keep spending limits at your providers as well.
• Not live: cumulative budgets per agent run or job. That backend is built and deployed with new admissions switched off until it has been tested with design partners. A job_id on a request is metadata only.

Recorded for every routed call: timestamp, model and provider, token counts (including cache and reasoning tokens), latency, estimated provider cost, status code, task profile, which of your provider keys was used and the outcome category. Routing decisions are recorded too.

Not recorded by ordinary routing: the text of your prompts and responses. We process them in memory to deliver the result.

• Evaluation datasets you create store the messages and expected answers you upload.
• Outcome feedback stores whatever you put in its metadata.
• Ensemble sends your prompt to several models, and the judge model also sees their answers.
• RUDY, the dashboard analyst, sends your question and a compact usage summary to a model on your own key.

• The web app runs on Vercel. The API, PostgreSQL and Redis run on Railway. Billing runs through Polar as merchant of record, so card numbers never reach us.
• HTTPS everywhere, with HSTS on routexor.com and api.routexor.com. Database connections outside the platform's private network require verified TLS (certificate and hostname), and settings that would skip verification are rejected.
• The API runs as a non-root Node 24 container. Schema changes ship as reviewed migrations applied before the new version starts, with lock and statement timeouts.
• A scheduled availability check runs from GitHub Actions, and the API records its own self-check every five minutes for routexor.com/status.

Every change to the main branch runs through CI, and a release needs it to pass:

• secret scanning of the full Git history with a pinned Gitleaks release;
• dependency advisory gates for the web app and the API, each recording a software bill of materials;
• a scan of the actual API container image with Trivy, whose binary provenance is verified before it runs;
• type checks, unit tests and integration tests against fresh PostgreSQL and Redis, plus a boot test of the real image with its migrations.

• No SOC 2 report, ISO 27001 certificate or third-party penetration test. Nothing on this page has been audited by an outside firm.
• The master secret is an environment variable, not a cloud KMS or hardware security module, and there is no automated master-key rotation. Rotating it today means re-encrypting every stored key.
• Our servers can decrypt your provider keys. There are no customer-managed keys and no bring-your-own-KMS option.
• No multi-factor authentication, SSO or SAML for dashboard accounts, and no self-service email verification or password recovery yet.
• Bot protection on signup is built but not switched on.
• IP allowlists match exact addresses only, and trusted client-IP provenance behind every proxy is not established.
• Cumulative per-run budgets are built and switched off. Caps are not a guarantee about your provider invoice.
• Status history starts October 12, 2026. There is no uptime SLA, no 24/7 on-call rotation and no published recovery objectives (RPO and RTO) or tested restore drill.
• One hosting region, with no data-residency choice.
• Account deletion and data export happen by request, not self-service, and older logs and backups follow their own retention.
• The vault audit log is readable through the API but not yet shown in the dashboard.

Today ROUTEXOR has no SOC 2 report. The dates below are targets. They assume our pre-seed round closes by the end of 2026; its use of funds includes $80,000 for the SOC 2 Type 1 audit and a security review.

Email team@aterna.ai with "Security" in the subject line. Include steps to reproduce. Please don't include live credentials or customer data.

Version 1.0, October 12, 2026: first publication.