BYOK Security Disclosure

Last updated: May 16, 2026

TL;DR

  • We store a SHA-256 hash of your provider API key. Never the plaintext.
  • On every request, the original key passes through the gateway unchanged to the upstream provider.
  • We cannot recover, replay, or expose your provider key outside the single request that carries it.
  • You can revoke and re-register keys at any time from the dashboard.

What BYOK Means in Practice

"Bring Your Own Keys" (BYOK) is a posture: your provider API credentials (OpenAI, Anthropic, Google AI, etc.) remain under your control. You generate them from each provider's console, register them with TensorCortex once, and then the gateway acts as a transparent forwarder for every subsequent request. We do not buy AI capacity in bulk and resell it to you; we do not sit on a pool of provider credit; we do not negotiate enterprise contracts with providers on your behalf. The provider's bill goes directly to your provider account.

This is operationally and legally meaningful: there is no "key escrow" in our database. Even an attacker with full read access to our infrastructure cannot exfiltrate plaintext provider keys, because plaintext keys are not stored anywhere we control — only hashes that cannot be reversed.

The Full Request Flow

Every authenticated request through TensorCortex follows this exact sequence:

  1. Customer sends request to the provider-matched subdomain (e.g., openai.tensor.cx) with Authorization: Bearer <your-provider-key>.
  2. Gateway hashes the key using SHA-256 (one-way). The plaintext key exists in memory only for the duration of this single request handler.
  3. Database lookup matches the hash to a registered API key record (Cloudflare D1). The record contains: hash, provider, cortex association, and the prefix used for display ("sk-...abc"). It does NOT contain the plaintext key.
  4. Pass-through to provider: the gateway forwards the request to the upstream provider's native endpoint (e.g. api.openai.com/v1/chat/completions), using the SAME Authorization header the customer sent. No transformation, no proxy account, no credit pool.
  5. Response forwarded back to the customer, with TensorCortex-added headers (X-Cache, X-Cost, X-Request-Id) but body unchanged.
  6. Asynchronous logging: request metadata (model, token count, cost, latency, cache status) is logged for analytics. Request and response bodies are logged only at the retention level your plan permits, and only for non-streaming requests.

What We Do Store

DataWhy
SHA-256 hash of your provider keyConstant-time lookup for authentication
Key prefix (e.g. "sk-proj-...ab12")Display in dashboard so you can identify keys
Cortex name + provider associationRouting + per-project organization
Request metadata (model, tokens, cost, latency)Analytics, billing, quota enforcement
Cached responses (semantic cache)Per-cortex isolated, response bodies only for non-streaming, deterministic requests
Request/response bodiesFor logs (subject to retention per plan); never used to train AI models

What We Do NOT Store

  • Plaintext provider API keys — only SHA-256 hashes
  • Encrypted provider keys for resale or proxy use — V1 is pure pass-through
  • Full credit card numbers — Stripe handles payment; we receive only token references
  • Cross-tenant cached data — every cache entry is keyed with the cortex ID, preventing cross-customer reads
  • Training data derived from your requests — we don't train models on your data

Threat Model

What we defend against, and what we don't:

We defend against

  • Database compromise leaking plaintext provider keys — impossible (only hashes stored)
  • Cross-tenant data exfiltration via cache — cache keys are cortex-scoped
  • SQL injection / XSS attempts in request payloads — sanitization + parameterized queries
  • Brute-force authentication — rate limiting per cortex + per IP
  • Request size attacks (DoS) — 10 MB upper bound enforced before body parse

We do NOT defend against

  • Compromise of your own provider account (OpenAI, Anthropic, etc.) — outside our surface; rotate from the provider console
  • Compromise of your TensorCortex login credentials — you control sign-in via Clerk; enable 2FA from your account settings
  • Cloudflare-level infrastructure compromise — we depend on Cloudflare's security posture; their Trust Hub describes their compliance and audit programs
  • Side-channel attacks on the AI provider itself (e.g., prompt injection that tricks the model into revealing secrets) — your responsibility to design application prompts safely

Key Rotation and Revocation

You can rotate or revoke any registered key from the TensorCortex dashboard at any time. Revocation is immediate: the next request using the old key will fail with a 401 Unauthorized response. There is no grace period or hidden retention; the hash record is removed from the database.

We recommend rotating provider keys from both sides if you ever suspect compromise: (1) generate a new key in the provider console, (2) register the new key in TensorCortex, (3) revoke the old key in TensorCortex, (4) revoke the old key in the provider console.

Compliance Posture (V1)

TensorCortex is in early V1 and does not yet hold formal certifications (SOC 2, ISO 27001, HIPAA BAA). We rely on Cloudflare's underlying compliance posture for infrastructure-level controls. If your use case requires formal attestations, please contact us at security@tensorcortex.com — formal certification paths are on the V2 roadmap.

Responsible Disclosure

If you discover a security vulnerability, please email security@tensorcortex.com with details. We will acknowledge within 48 hours and target a fix or mitigation within 14 days for critical issues. We do not currently run a paid bug bounty program but appreciate responsible disclosure.

Tensor Cortex LLC
Security: security@tensorcortex.com
Privacy: privacy@tensorcortex.com
Support: support@tensorcortex.com

Related