Security

Last updated June 15, 2026  ·  Questions? support@smashcost.com

SmashCost sits in the critical path of your AI requests. This page describes the controls we have in place to protect your data and API keys. Every guarantee listed here is covered by automated tests that run on every code change.

🔑Provider API keys — encrypted at rest

Your provider API keys (OpenAI, Anthropic, Groq, Google) are encrypted with industry-standard symmetric encryption before being stored. The encryption key is never stored alongside the data — it lives in a separate secure environment variable and is required at startup. Keys are decrypted in memory only for the duration of a single request.

• Plaintext keys are never persisted to disk or database.
• The encryption key can be rotated independently of the database.
• Decrypted values exist only within the scope of the active request — they are never cached, persisted, or returned in any response.

🙈Prompts and responses — never stored, never logged

SmashCost uses a bring-your-own-keys (BYOK) model. Requests are forwarded directly to your configured providers. We store only request metadata for cost and routing analytics: model name, token counts, latency, routing decision, and cost. The content of your messages is never written to our database.

As a defense-in-depth measure, prompt content is scrubbed at the logging layer. Every log record produced anywhere in the process — including third-party libraries — passes through a scrubbing filter before emission. Records whose content contains fields associated with request content are redacted automatically, even if a future code path accidentally tries to log them.

An automated canary test embeds a unique sentinel string inside a user message and asserts it is absent from all log output across multiple failure scenarios. The test verifies both that the canary is blocked and that normal metadata is still present.

🔒Data in transit — TLS enforced

All traffic between clients and SmashCost is served over HTTPS with TLS 1.2+. Connections to upstream AI providers are made over HTTPS with certificate validation enabled. Plain-text HTTP connections are rejected in production.

🪪Authentication and session security

Dashboard sessions use cryptographically signed cookies with a secret key required at startup. Cookies are HttpOnly and Secure in production.

Passwords are hashed with bcrypt. The plaintext password is never stored or logged.

Gateway access uses API keys stored as one-way hashes. The raw key is shown to the user once at creation and is never retrievable again.

The admin panel requires two independent credentials at login: a server-side secret and a time-based two-factor code. After login, the browser receives a short-lived signed HttpOnly cookie — credentials are not stored in the browser or sent with every admin request.

State-changing requests that rely on session cookies are protected with a same-origin check in production. Cross-site requests with a missing or untrusted origin are rejected before reaching application handlers.

🔐Session isolation — scoped by organization

Routing decisions cached per session are always scoped to the organization that made the request. Two organizations using the same session identifier cannot share or observe each other's routing state. This property is verified by automated tests that assert distinct cache keys for distinct organizations and stable keys for the same organization across calls.

🚦Rate limiting

Each organization is subject to a sliding-window rate limit enforced before the request reaches any upstream provider. Limits apply at the organization level — rotating or creating additional API keys does not increase the allowed request rate.

🪝Webhook integrity — HMAC-SHA256

Paddle billing webhooks are verified using HMAC-SHA256 signature checking against a shared secret. Requests with missing or invalid signatures are rejected with HTTP 401 before any processing occurs.

🛡HTTP security headers

Every response includes security headers enforced via server-side middleware:

• Content-Type sniffing prevention
• Clickjacking protection (framing denied)
• XSS protection
• Strict referrer policy
• Permissions policy restricting camera, microphone, and geolocation
• Content Security Policy restricting scripts, styles, fonts, connections, and forms to trusted sources
• HTTP Strict Transport Security in production

🌐CORS policy

In production, cross-origin requests are restricted to smashcost.com and www.smashcost.com. Only the specific headers required by the gateway are permitted.

⚡Provider circuit breaker

SmashCost uses a per-model circuit breaker that tracks failure rates for each upstream provider and model pair. When a provider becomes consistently unavailable, traffic is temporarily stopped to that model and shifted to fallbacks — reducing the blast radius of provider outages.

🔍Routing audit log and savings integrity

Every request records exactly how the model was selected: classifier-driven routing, session cache, client override, or passthrough. The unit prices used to compute cost are frozen at request time and stored with the log entry, so the savings calculation is always reproducible without depending on current price tables.

Override requests are excluded from the savings ledger. When a client specifies a model manually, no cost delta is attributed to SmashCost's routing. The savings report only counts decisions made by the router, preventing inflated figures.

👁Shadow routing — observable before commitment

During the free observation period, SmashCost operates in pure passthrough mode: your traffic is forwarded using the exact model you requested, with no substitutions. Simultaneously, the gateway computes — in memory, with no extra latency — what models would have been selected and stores projected costs in the request log.

This gives you an auditable record of what SmashCost would have done before you commit to enabling routing. The observation guarantee is tested explicitly: the real request always uses your original model — SmashCost never substitutes a model while in shadow mode.

📋Audited state transitions and kill switch

Every change to an organization's subscription status must pass through a single canonical function in the codebase. This function validates that the transition is legal, applies the change, and writes an immutable audit record with the old status, new status, actor, and timestamp. The audit table is append-only; records are never deleted by application code.

Activation requires explicit confirmation in the request body. The kill switch allows an operator to deactivate a live organization in a single authenticated call, returning it to observation mode.

🗓Observation funnel — automated and gateway-safe

Scheduled jobs manage the observation funnel (conversion report, reminders, window close). All jobs are designed so that a failure mid-run cannot leave the system in an inconsistent state. Crucially, the window-close job never blocks gateway traffic. Only an explicit operator action can block an organization's requests. The passthrough invariant is verified by a dedicated automated test.

📡Streaming — same privacy guarantees

SmashCost supports Server-Sent Events (SSE) streaming for all supported providers. The streaming path has the same privacy guarantees as the non-streaming path: message content in SSE chunks is never written to logs, the database, or error messages. Only usage metadata — token counts and latency — is captured at the end of the stream for cost calculation.

• Each SSE chunk is forwarded to the client as received from the upstream provider. SmashCost does not buffer or inspect message content.
• The prompt-scrub filter described above covers the streaming path — accidental log emission containing content is redacted automatically.

🤝Shared responsibility model

SmashCost's security controls cover the gateway layer. Certain responsibilities remain with you as the customer. Understanding this boundary prevents misunderstandings about what SmashCost does and does not protect.

SmashCost cannot protect against: compromise of your own systems or credentials; actions taken by third-party AI providers; or events outside our infrastructure boundary.