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 is submitted to the TryTokka server over HTTPS. The browser and hosting edge negotiate the supported TLS version.
We encrypt it immediately
Before database storage, the application encrypts the credential with AES-256-GCM. The implementation generates a random 16-byte IV for each encryption and stores the GCM authentication tag.
Only the encrypted blob enters the database
The credential column stores iv:authTag:ciphertext as hex-encoded values. The application does not intentionally persist the plaintext credential.
The encryption key lives separately
The secret used to derive the encryption key is supplied through the server deployment environment, separately from credential rows in Supabase.
Decryption happens only at sync time
Authorized verification and sync operations decrypt the credential in server process memory and call the provider’s usage or billing endpoints. The application does not persist that decrypted value.
API responses do not return the stored key
Public connection responses expose metadata such as provider and a short key hint, not the stored credential. Logging and error paths are reviewed to avoid intentionally recording plaintext credentials.
Key operations create audit records
Verification, synchronization, and deletion paths write key-access audit records with provider, timestamp, action, and success state. You can review the available history 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. The database rows alone do not contain the server-side secret needed to decrypt them. This reduces exposure, but it is not a guarantee against every breach path.
If an attacker gained access to both our server environment (to get ENCRYPTION_KEY) AND our database, they could decrypt your API keys.
Implemented mitigations: authenticated encryption, separation of the deployment secret from database rows, a documented key-rotation path, and access audit records. Incident notices depend on the facts and applicable legal obligations.
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.
A provider credential must exist in server process memory while a provider request is prepared. Accessing it would require compromising the relevant runtime or process; TryTokka does not describe that risk as impossible.
What we recommend you do
Use dedicated API keys
Where the provider supports scoped credentials, create a separate key with only the permissions TryTokka documents for that connection. Name it "TryTokka" so you can revoke it independently.
Rotate keys when needed
Follow your provider or organization’s rotation policy, and rotate immediately after suspected exposure. Update the replacement in TryTokka → Connections.
Check your audit log
Visit Dashboard → Settings → Security to review recorded verification, sync, and deletion actions. If an entry is unexpected, revoke the provider key and contact support.
Watch your AI provider billing
Enable provider spend alerts and rate limits where available. OpenAI budget alerts are notifications — not a guaranteed hard stop. TryTokka monitors multi-provider spend; use key rotation, prepaid controls, or your own gateway if you need enforcement.
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; HSTS is configured by the application |
| Database access | Supabase Row-Level Security plus server-side ownership checks |
| Authentication | Supabase Auth sessions; optional MFA gates for sensitive account actions |
| Response headers | Application configuration includes CSP, frame, HSTS, and referrer controls |
| Abuse controls | Rate limits on sensitive public and authenticated routes; signed payment webhooks are verified cryptographically |
| Audit log | Verification, sync, and deletion actions record provider, action, time, and outcome |
Man-in-the-middle and SSL pinning
Browser sessions to TryTokka use HTTPS. Production responses send HSTS ( (max-age=31536000; includeSubDomains; preload) and, when the public app URL is HTTPS, Content-Security-Policy upgrade-insecure-requests. That protects against casual downgrade and cleartext interception on the public web.
Classic SSL/certificate pinning (HTTP Public Key Pinning) is not available for ordinary websites: browsers deprecated HPKP because a bad pin brickwalled real users. TryTokka therefore relies on the browser and platform certificate trust stores, Certificate Transparency, and HSTS — the same model used by most SaaS products.
The Chrome extension only permits HTTPS requests to https://trytokka.com and refuses arbitrary origins for the widget endpoint. It stores a read-only widget token, not provider API keys. Native-app certificate pinning does not apply: TryTokka does not ship a native iOS/Android client.
A network MITM with a forged certificate still requires compromising a trusted CA, the user's device trust store, or the hosting edge. Application encryption cannot defeat a fully compromised user device or a compromised server environment that holds ENCRYPTION_KEY.
If a breach ever happens
We investigate suspected incidents, contain affected systems, and make regulator or user notifications when required by applicable law. Timing and recipients depend on the incident, jurisdiction, and assessed risk. A user notice would explain the known impact and recommended steps, such as revoking affected provider credentials.
To report a security vulnerability: security@trytokka.com
Sources and verification
Claims are checked against the linked primary sources. Provider prices and product features can change; verify the source before making a purchasing or production decision. Last checked 2026-07-18.
- Credential encryption implementation — TryTokka source; checked 2026-07-18Uses Node crypto aes-256-gcm, a random 16-byte IV, and an authentication tag.
- Vercel cron configuration — TryTokka source; checked 2026-07-18The deployed schedule is the source of truth; delivery time is not guaranteed.
- Manual sync route — TryTokka source; checked 2026-07-18Authenticated owners can request an on-demand sync.
Found an outdated statement? Email legal@trytokka.com.
Ready to monitor spend with keys you trust?
7-day free trial, no credit card. AES-256 encrypted keys from day one.
Start free trial