Skip to content

Security & privacy

Your code is yours.

A plain-language summary of how Tokens handles your data. It describes how the platform works today; the legal terms are in our Privacy Policy and Terms of Service.

What we log, and what we do not

  • We record usage metadata so we can bill you accurately: the model, token counts, cost, latency, timestamps, the API key used and a request identifier.
  • We do not store the content of your prompts, code or model responses. The gateway streams requests to the model provider and meters tokens as they pass; there is no prompt or response archive, and our application logs redact prompt and message fields.
  • Tokens does not train models on your data and does not sell it.

Model providers

  • To answer a request, your prompt is forwarded to the upstream provider that serves the model you chose. From that point the provider's own data-retention and training policies apply to that provider's service, and they differ by provider and by model.
  • If retention matters for your work, check the provider's terms for the model you use before sending sensitive code, or contact us and we will tell you which providers serve a given model.

Keys and credentials

  • Upstream provider credentials are encrypted at rest with AES-256-GCM. Customer API keys can be limited to specific models, given a monthly spend cap and an expiry date, and rotated or revoked from the dashboard at any time.
  • Keys you create are shown to you for use; treat them like passwords, keep them out of source control, and rotate a key immediately if you suspect it leaked.
  • Passwords are handled by our authentication service and are stored only as salted hashes.

Payments

  • Card, mobile-wallet and bank payments are processed by the payment provider you choose (for example Stripe, SSLCOMMERZ, bKash or Nagad). We never see or store your full card number or banking password.
  • Every payment is confirmed server-side with the provider before credit is added or a plan is activated, and each confirmation is applied exactly once, so retries and duplicate notifications cannot double-credit an account.

How our own staff access the platform

  • Administrative access requires multi-factor authentication, ends after a period of inactivity, and is restricted by role. Sensitive actions are written to an audit log.
  • Customer data is protected by row-level security in the database. Staff only see what their role requires.

Service providers we rely on

  • Infrastructure hosting and our database; payment providers for the methods you use; an email delivery provider for receipts and account emails; and the model providers described above.
  • Optional services such as analytics, live chat and the sign-up security check are used only when enabled, and non-essential ones load only after you consent through the cookie settings.

Report a vulnerability

If you believe you have found a security problem, please tell us privately before disclosing it publicly. Include what you found, how to reproduce it, and how to reach you. We will acknowledge your report and keep you informed. Please do not access other customers' data or disrupt the service while testing.

Use the contact options on our support page.