If you send proprietary code through an AI gateway, you should know exactly what that gateway keeps. This page sets out what Tokens stores, what it doesn't, where your prompts go, and how to lock down your account. The public summary is on the security page.
What Tokens stores about your requests#
Tokens stores usage metadata for each request, because billing needs it:
- the model you called
- input, output and cache-read token counts
- the cost
- latency and timestamps
- which API key was used
- the request id (
x-tokens-request-id)
That is what you see in the usage dashboard and the CSV export, and nothing more.
What Tokens doesn't store#
- Prompt and response content is not stored. The gateway streams your request to the model provider and meters tokens as they pass. There is no archive of prompts, code or model responses.
- Application logs redact prompt and message fields, so content doesn't end up in logs by accident.
- Tokens doesn't train models on your data and doesn't sell it.
Where your prompts go: upstream providers#
To answer a request, Tokens forwards your prompt to an upstream provider that serves the model you chose. From that point, that provider's own data-retention and training policies apply to its service. Those policies differ by provider and sometimes by model, and Tokens can't change them.
Practical consequences:
- Choosing a model is also choosing whose policy applies. Check the provider's terms for the model you use before sending sensitive code or personal data.
- With automatic failover, a request can be served by another upstream source for the same model if the first one fails. If it matters for your work, contact support and ask which providers serve a given model.
- Don't send secrets (passwords, private keys, production credentials) in prompts at all. Most coding agents read files from your working directory, so keep
.envfiles and credentials out of what the agent can see, or use the agent's ignore settings.
How Tokens protects the platform#
- Upstream provider credentials are encrypted at rest with AES-256-GCM.
- Your API keys are stored as hashes. The full secret is shown once, at creation, and can't be shown again.
- Passwords are handled by the authentication service and stored only as salted hashes.
- Customer data is protected by row-level security in the database. Staff see only what their role requires.
- Admin access requires multi-factor authentication, times out after inactivity, and is restricted by role. Sensitive admin actions are written to an audit log.
- Payments are confirmed with the payment provider on the server before credit is added, and each confirmation is applied exactly once. Tokens never sees or stores your full card number or banking password.
Secure your account: MFA and sessions#
Open account security in the dashboard (/account/security):
Turn on two-factor authentication#
Add an authenticator app (TOTP), such as any app that scans a QR code and shows 6-digit codes. After that, signing in needs your password and a current code. If someone gets your password, they still can't reach your keys or billing.
Review active sessions#
The Active Sessions list shows where your account is signed in. Revoke any session you don't recognise, or use sign out everywhere if you think your account was accessed by someone else. Then change your password and check /dashboard/keys for keys you didn't create.
If you sign in with Google, your Google account's own security (including its two-step verification) protects that sign-in route as well.
API key hygiene#
Your key is the thing most likely to leak, usually through a commit, a screenshot or a shared terminal log.
- One key per tool or machine, so you can revoke one without breaking the rest.
- Set a monthly spend cap on every key that runs unattended, and an allowed-models list where a tool only needs one or two models. Both are set at creation; see API keys.
- Keep keys in environment variables or a secrets manager, never in committed files. Add
.envto.gitignore. - Never put a key in browser or mobile code. Tokens doesn't support browser calls; call it from a server.
- Don't paste keys into support tickets, chats or issues. Support never needs your key; the request id is enough.
- If a key leaks, rotate or revoke it right away. Rotation takes effect immediately; the old secret stops working at once.
Watch the usage dashboard for unfamiliar models or traffic at odd hours. It's often the first sign a key is being used by someone else.
Delete your account#
Account deletion is handled by support. Open a ticket in /dashboard/support from the account you want deleted. Revoke your API keys first so nothing keeps running in the meantime.
Report a vulnerability#
If you think you've found a security problem in Tokens, report it privately before disclosing it. The security page has the contact details. Include what you found, how to reproduce it and how to reach you. Please don't access other customers' data or disrupt the service while testing.