Security

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

SmashCost sits in the critical path of your AI requests. This page describes the main controls we use to protect your data and API keys, without exposing operational details that could weaken the system. Key security controls are 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.
• Key material is stored separately from application data.
• 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, application logs are scrubbed for fields commonly associated with prompt or response content. Records containing those fields are redacted before emission, reducing the chance of accidental content leakage.

Automated tests cover the logging protections so normal metadata remains useful while prompt and response content stays out of logs.

🔒Data in transit — TLS enforced

All production 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, and production responses include HSTS.

🪪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 rate limits 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 provider health controls to reduce the blast radius of upstream outages. When a provider or model becomes consistently unavailable, eligible traffic can be shifted to fallbacks instead of repeatedly hitting a failing route.

🔍Routing records 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 savings calculations. 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 a reproducible 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 security events

Security-relevant actions are recorded with timestamps and actor context, including API key creation and revocation, provider configuration changes, invites, member removal, and admin actions. These records support incident review without storing prompt or response content.

When a member is removed from an organization, active API keys created by that member for that organization are revoked in the same transaction as the membership change.

🗓Free observation — no automatic cutoff

Free observation is designed to be low-risk: requests remain in passthrough mode until routing is explicitly activated. There is no automatic observation-window cutoff that blocks gateway traffic.

📡Streaming — same privacy guarantees

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

• Streaming content follows the same no-prompt-storage policy as standard requests.
• 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.