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.
Read the source: acsavenhq/trytokka-security
The three modules that encrypt, decrypt and mask your provider keys, mirrored verbatim from the application. Public so you can check the algorithm rather than trust this page. It does not prove the same code is deployed here — only a build you perform can do that, and the section below says so plainly.
The short version
Every question a credential-security review asks, answered here rather than spread across five pages. Two of them have uncomfortable answers; they are included for that reason, not in spite of it.
What credentials does TryTokka store?
One read-only billing or usage credential per connected provider, and nothing else. TryTokka never receives your prompts, completions, or model traffic — it reads spend totals from provider billing endpoints.
Are they encrypted at rest?
Yes. AES-256-GCM with a random 16-byte IV per row and a stored authentication tag, written as iv:authTag:ciphertext. Tampered ciphertext fails authentication and throws rather than decrypting.
Can the application recover the plaintext, and when?
Yes, and it has to — reading your spend means calling the provider with your credential. It is decrypted in server memory during a verification or sync, used for that request, and never written back in plaintext.
Can the operator read your keys?
No admin or operator screen in the application can display one. But whoever holds the deployment ENCRYPTION_KEY together with database access could decrypt outside the app, so the honest answer is that the capability exists. Every in-app decryption is audited and you can read that log yourself. We keep 90 days of it; download the CSV if you want a longer record, because that copy is yours and does not depend on us.
Is provider OAuth used where it exists?
Where a provider offers a scoped cloud identity, yes — Google Cloud and Azure connect through service principals that mint short-lived OAuth 2.0 tokens, and AWS uses a scoped IAM user. The other providers publish no OAuth path for billing reads, so TryTokka asks for the narrowest read-only key each one offers.
What permissions are requested?
Read-only billing or usage scope, never completion access. TryTokka rejects chat/completion keys by shape where it can detect them, because a key that can read spend should not also be able to spend.
Where are the credentials hosted?
Encrypted rows live in Supabase Postgres behind Row-Level Security. Current production compute runs on Vercel in iad1 (Washington, D.C. area, United States). The ENCRYPTION_KEY is supplied through the Vercel environment and is never stored in the database. Region is not customer-selectable; there is no EU-only option today.
How is the encryption key rotated?
At least every 90 days, and sooner after any suspected environment exposure, using a dual-key window (ENCRYPTION_KEY plus ENCRYPTION_KEY_PREVIOUS) so existing rows still decrypt. That rotation does not rotate your provider keys — you revoke the dedicated TryTokka key in each provider console yourself.
How long do keys survive account deletion?
They go with the account. Connection rows are foreign-keyed to the auth user with ON DELETE CASCADE, so deleting your account removes the encrypted credential in the same transaction. You can also delete a single connection at any time without closing the account. A hash of your email is kept only to block repeating the free trial. Disaster-recovery snapshots can retain encrypted blobs for up to 90 days.
Has there been an external security audit?
No third-party penetration test or external audit has been commissioned. TryTokka is a solo-operated product and does not claim otherwise.
Is there SOC 2 or ISO 27001 certification?
No. Neither certification has been obtained. If your procurement process requires one, TryTokka does not currently meet it.
What happens if there is an incident?
Suspected incidents are investigated and affected systems contained, with regulator or user notification where applicable law requires it. A user notice would state known impact and recommend revoking affected provider credentials. The procedure is published at /incident-response.
Can we read your keys?
This is the question we were asked most often and answered least clearly, so here it is without hedging. You do not have to take any of it on trust either — the code that does this is published at github.com/acsavenhq/trytokka-security, mirrored verbatim from the application. That lets you check the algorithm, what is logged and what is masked. It does not prove the same code is running here; only a build you perform or an audit with deployment access can establish that, and we would rather say so than let a published snapshot imply more than it shows. To be explicit about what that repository is: TryTokka is a closed-source commercial product and its application repository is private. These three modules are public because they are the security-critical ones and you should not have to take our word for them — the product itself is not open source, and we would rather say that than let one public repository imply otherwise.
In the application, no. There is no admin screen, support tool, or internal page that displays a stored provider credential. The only code paths that decrypt one are the provider adapters — which send it straight to that provider's billing endpoint — and a key-hint route that is scoped to the row's owner, rate limited, and returns a mask like sk-admin-...a91f rather than the key. The admin panel's own unlock token is encrypted with the same function, which is why you may see it near this code; it decrypts a session payload, never a customer row.
Outside the application, yes — and we will not pretend otherwise. Anyone holding the deployment ENCRYPTION_KEY together with database access can decrypt stored credentials. That is the same combined-compromise scenario described in the threat model below, and an operator is inside it by definition. Removing that capability entirely would require a hardware security module or a managed KMS holding decrypt authority separately from the application. TryTokka does not have that today.
What you get instead is a receipt. Every decryption writes a key-access audit record — provider, action, timestamp, outcome — and it is your log, not just ours. Read it at Dashboard → Settings → Security. We keep 90 days of it, pruned weekly, so if you want a longer record download the CSV and keep it yourself — that copy does not depend on us and cannot be pruned by us. If a sync you did not expect appears there, revoke the provider key and email us. A control you can verify is worth more than a promise you cannot.
The practical mitigation is the one under your control: connect a dedicated read-only billing key, never a completion key. Then the worst case is that someone learns what you spent, not that they can spend it.
Why API keys and not OAuth
OAuth would be better where it exists, because you could revoke TryTokka's access from your own account page without rotating a key. It exists for three of the eight connectors, and TryTokka uses it there. For the rest, no provider publishes an OAuth flow that grants billing or usage reads, so the narrowest available read-only key is the least-privilege option on offer.
| Provider | What TryTokka asks for | Mechanism |
|---|---|---|
| OpenAI | Read-only Admin API key | No OAuth flow published for organisation usage reads |
| Anthropic | Read-only Admin API key | No OAuth flow published for organisation usage reads |
| Google Cloud / Gemini | Service account, Billing Account Viewer | OAuth 2.0 — the service account signs a JWT for a short-lived token |
| Azure | App registration, Cost Management Reader | OAuth 2.0 client credentials against Entra ID |
| AWS Bedrock | IAM user limited to ce:GetCostAndUsage | AWS SigV4 request signing, not OAuth |
| OpenRouter | Management key | No OAuth flow published for usage reads |
| xAI | Management key | No OAuth flow published for billing analytics |
| Cursor | Teams Admin API key | No OAuth flow published for team spend reads |
If a provider ships an OAuth flow for billing reads, moving to it is a straight upgrade and we will take it.
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. See the kill-switch guide for Hobby Scout cadence vs a real traffic cut.
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 |
| Encryption-key rotation | At least every 90 days; dual-key window via ENCRYPTION_KEY_PREVIOUS |
| Compute region | Vercel iad1 (United States); not customer-selectable |
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.
Hosting and data region
Reviewed 2026-08-18
- Application code runs on Vercel. Current production serverless functions execute in iad1 (Washington, D.C. area, United States).
- Encrypted rows, Auth, and Row-Level Security live in Supabase Postgres. The project region is fixed at creation and is not selectable per customer.
- ENCRYPTION_KEY is supplied only through the Vercel deployment environment. It is never stored in the database.
- There is no customer-selectable region and no EU-only deployment today. Choosing TryTokka means US application compute plus Supabase-hosted data.
- Off-site disaster-recovery snapshots go to Cloudflare Workers KV (90-day TTL) and, when the GitHub workflow runs, to GitHub Actions artifacts (90-day expiry).
Vendors: subprocessors.
Encryption-key rotation
The deployment ENCRYPTION_KEY is rotated at least every 90 days, and sooner after any suspected environment exposure. During rotation both ENCRYPTION_KEY and ENCRYPTION_KEY_PREVIOUS are set so existing rows still decrypt; after re-encryption the previous secret is removed. That rotation does not rotate your provider keys — revoke or replace the dedicated TryTokka key in each provider console yourself.
Account deletion
Export a CSV of spend and of the key-access log first if you want a copy we will not keep. Then revoke the dedicated TryTokka key at each provider — deleting the account here does not revoke it there.
Removed with the account
- The auth user and sessions
- Encrypted provider credentials and connection rows (ON DELETE CASCADE)
- Usage snapshots, alerts, workspace membership, and in-app API/widget tokens
- Key-access audit rows for that user (they cascade with the auth user)
Kept after deletion
- A hash of the email used only to block repeating the free trial after delete-and-re-signup
- Payment, tax, fraud, refund, and dispute records the payment provider or applicable law require
- Disaster-recovery database snapshots (Cloudflare KV and, when enabled, GitHub artifacts) for up to 90 days — those copies still hold encrypted blobs until they expire
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.
Full procedure: /incident-response. Report: security@trytokka.com
Reporting a vulnerability — and our promise to you
TryTokka does not run a paid bug bounty. It is a solo product and cannot responsibly promise payouts it might not be able to honour. What it can offer is the part that actually matters to a researcher deciding whether to look: a commitment not to come after you.
Safe harbour
If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you for your research, and we will treat your report as authorised conduct under applicable computer-misuse law. If a third party brings action against you for work that followed this policy, we will make that authorisation clear.
What we ask
- Use only your own account and your own data. Do not access, modify or retain another user's data — and never a stored provider credential.
- No denial of service, no spam, no social engineering of us, our users, or our providers, and no physical attacks.
- Stop as soon as you have demonstrated the issue. Proving you can read one record is a finding; downloading the table is not research.
- Give us a reasonable window to fix it before publishing. We will not ask you to stay quiet indefinitely.
What you get back
- An acknowledgement within 3 working days.
- An assessment and intended fix timeline within 10 working days.
- Credit on this page when the fix ships, if you want it. Anonymous is fine too.
Report to security@trytokka.com. Machine-readable routing lives at /.well-known/security.txt (RFC 9116).
Please do not include live credentials, access tokens or another person's personal data in a report. If a proof of concept needs one, say so and we will arrange a test account.
Security incident history
No security incident affecting customer data or stored provider credentials has occurred to date. Last reviewed 18 August 2026.
An empty list is easy to write and worth very little on its own, so here is the commitment attached to it: if an incident happens, it gets an entry here with the date, what was affected, what we did, and what changed afterwards — and this section keeps a dated review line either way, so "nothing here" can be told apart from "nobody updated the page".
TryTokka has been handling provider credentials since June 2026. That is a short history, and a short clean history is weaker evidence than a long one. We would rather state the start date than let the absence of bad news imply more than it should.
Sources and verification
Claims are checked against the sources below. Provider prices and product features can change; verify the source before making a purchasing or production decision. Last checked 2026-08-20.
Entries shown as a file path point into TryTokka's application repository, which is not public — you cannot open those to check them yourself, and we would rather say so than link you to a page you cannot read. They are listed so the claim names the exact code it rests on. Everything else links to a primary source you can verify directly.
- Dual-key decrypt window — TryTokka source (published for inspection); checked 2026-08-20Decrypt tries ENCRYPTION_KEY then ENCRYPTION_KEY_PREVIOUS.
- Vercel cron configuration —
vercel.json; reviewed 2026-07-18The deployed schedule is the source of truth; delivery time is not guaranteed. - Manual sync route —
app/api/connections/sync/route.ts; reviewed 2026-07-18Authenticated owners can request an on-demand sync. - Only provider adapters and the owner-scoped hint route decrypt —
app/api/connections/hint/route.ts; reviewed 2026-07-18Ownership is checked before decrypting and only maskKey output crosses the response boundary; the admin surfaces never read encrypted_key. - Admin unlock decrypts its own session token, not credentials —
lib/admin-unlock.ts; reviewed 2026-07-18decrypt() there parses an UnlockPayload of { uid, exp } — it never touches connection rows. - Key-access audit trail — TryTokka source (published for inspection); checked 2026-08-20Records provider, action, timestamp and outcome for every decryption path; surfaced to the owner in Dashboard → Settings → Security.
- Per-provider least-privilege credential guidance — TryTokka source (published for inspection); checked 2026-08-20Names the exact credential and permission for each provider — read-only admin keys, Billing Account Viewer, Cost Management Reader, ce:GetCostAndUsage.
- Published hosting facts —
lib/trust/hosting.ts; reviewed 2026-07-18Reviewed against the Vercel production deployment region (iad1) on 2026-08-18. - Rotation script —
scripts/rotate-encryption-key.mjs; reviewed 2026-07-18Re-encrypts stored credential rows under the new key. - Canonical subprocessor list —
lib/trust/subprocessors.ts; reviewed 2026-07-18Privacy §4 and /subprocessors render this array; adding a vendor without a row is a disclosure miss.
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