Security
You're trusting us with keys to your AI accounts. Here's exactly how we protect them — no vague promises, just the technical facts.
What happens to your API key
You paste your key
The key travels from your browser to our server over HTTPS (TLS 1.3). It is never sent over unencrypted HTTP.
We encrypt it immediately
The first thing our server does is encrypt the key with AES-256-GCM — the same encryption used by banks and governments. A random 16-byte IV is generated for each encryption so the same key always produces a different ciphertext.
Only the encrypted blob enters the database
We store: iv:authTag:ciphertext (all hex-encoded). The plaintext key is never written anywhere. Even if you had full database access, you'd see meaningless hex.
The encryption key lives separately
The secret needed to decrypt your key (ENCRYPTION_KEY) is stored only in our Vercel server environment variables — never in the database. An attacker would need to compromise both our database AND our server environment to decrypt your key.
Decryption happens only at sync time
Every 6 hours, we decrypt your key in server memory, make one HTTPS call to your AI provider to fetch usage data, then let the key be garbage collected. The decrypted key exists in memory for approximately 100–300 milliseconds.
Keys are never returned or logged
We have audit controls in place: the API key value never appears in any HTTP response, any log file, any error message, or any monitoring tool. Check our source code — you'll find zero console.log(apiKey) calls.
Every access is audited
Every time your key is decrypted and used, we write a record to your personal audit log: provider, timestamp, success/failure. You can view this log in Dashboard → Settings → Security.
Honest threat model
If our database is compromised, attackers get encrypted blobs. They cannot decrypt them without the ENCRYPTION_KEY, which lives only in server environment variables. Your API keys remain safe.
If an attacker gained access to both our server environment (to get ENCRYPTION_KEY) AND our database, they could decrypt your API keys.
Our mitigations: Vercel MFA, minimal team access, ENCRYPTION_KEY rotation policy, audit log anomaly detection. If we detect a breach, we will notify all users immediately.
Your mitigation: Create dedicated, minimum-permission Admin API keys just for TryTokka. If those keys are ever compromised, revoking them doesn't affect your main OpenAI/Anthropic usage.
The decrypted key exists in Node.js process memory for ~200ms during sync. Exploiting this requires direct operating system access to our Vercel instance — not practically achievable by external attackers.
What we recommend you do
Use dedicated API keys
Create a separate Admin API key for TryTokka with only "Read Usage" permissions. Name it "TryTokka" so you can identify and revoke it independently.
Rotate keys periodically
Even if nothing seems wrong, rotating API keys every 3–6 months limits exposure. Update the key in TryTokka → Connections.
Check your audit log
Visit Dashboard → Settings → Security tab to see every time your keys were accessed. Anything unexpected? Revoke the key immediately.
Watch your AI provider billing
Set spend limits directly at OpenAI and Anthropic too. TryTokka monitors, but hard limits at the source prevent overspend entirely.
Technical specifications
| Encryption algorithm | AES-256-GCM (authenticated encryption) |
| Key derivation | SHA-256 of ENCRYPTION_KEY env var → 32-byte key |
| IV generation | 16 random bytes (crypto.randomBytes) per encryption |
| Authentication tag | 16 bytes GCM auth tag — detects any tampering |
| Transport | HTTPS/TLS 1.3 — enforced via HSTS header |
| Database | Supabase with Row-Level Security — users can only see their own data |
| Auth | Supabase Auth (JWT, bcrypt password hashing) |
| Headers | CSP, X-Frame-Options, HSTS, Referrer-Policy on every response |
| Rate limiting | Per-user and per-IP limits on all mutation endpoints |
| Audit log | Every key decryption event recorded with timestamp |
If a breach ever happens
We will notify all affected users by email within 72 hours of discovering a breach, in line with GDPR and DPDP Act requirements. The notification will include: what was compromised, what we're doing, and what you should do (likely: revoke and rotate your API keys at each provider). We will never try to hide a breach.
To report a security vulnerability: security@trytokka.com