Security and Responsible Disclosure

We welcome reports from security researchers and users. This page explains how to report a vulnerability, what is in scope, the rules we ask you to follow and what you can expect from us. It also summarizes how we protect Tokentide and your data.

Reporting a vulnerability#

Email security@tokentide.app, in English or Spanish. Our machine-readable contact details are published in security.txt, following RFC 9116. Please don't report vulnerabilities through public channels, such as social media or public issue trackers. If you need to send sensitive details, ask us for a secure channel in your first message.

What to include#

• A description of the vulnerability and its impact.
• The steps to reproduce it, with a minimal proof of concept.
• The affected URLs, hosts or API endpoints, and the request ids (X-Request-Id) and times (UTC) of your tests.
• Your account email and the prefix of the API key you used (never the full key).
• Whether you'd like to be credited, and under what name.

Never send us real customers' data, secrets or complete API keys. Redact them from screenshots and logs.

Scope#

In scope#

• tokentide.app, including the dashboard and the documentation.
• The API at api.tokentide.app.
• The status page at status.tokentide.app.
• Our SDKs: @tokentide/sdk (TypeScript) and the tokentide Python package.

Out of scope#

• Venice's own services: report those to Venice. The services of our other providers, such as Vercel and Stripe: report those through their own programs.
• Denial-of-service attacks and load or volumetric testing.
• Social engineering, such as phishing our staff or customers, and physical attacks.
• Reports from automated scanners without a demonstrated impact.
• Missing best-practice headers or settings without a demonstrated impact.

Rules for testing#

• Test only with your own account and API keys. Use tt_test_ keys and test environments where we make them available. Testing with tt_live_ keys is charged like any other use.
• Don't access, modify, delete or keep other people's data. If you come across personal data or secrets, stop, don't save or share them, and report it to us immediately.
• Don't degrade the Service for others: no denial of service, no spam and no automated testing beyond our rate limits.
• Do only what is necessary to demonstrate the issue: no pivoting to other systems and no persistence.
• Keep the details confidential until we have fixed the issue, and give us reasonable time before any disclosure. We propose 90 days from your report, or earlier once the fix is deployed if we agree on it.
• Follow the law.

What we commit to#

• We acknowledge your report within 3 business days.
• We send you a first assessment within 10 business days.
• We keep you informed until the issue is fixed, and tell you when it is.
• With your permission, we credit you in the acknowledgments on this page.
• We don't take legal action against good-faith research that follows this policy (see the safe harbor below).

Safe harbor#

If you make a good-faith effort to follow this policy, we consider your research authorized, we won't take or support legal action against you for it, and we waive the restrictions of our Acceptable Use Policy that would otherwise prevent it, to the extent needed for that research. If a third party takes legal action against you for research that followed this policy, we'll make it known that it was authorized. We can't authorize testing of third-party systems, and we can't bind public authorities. If in doubt, ask us first at security@tokentide.app.

Bug bounty#

We don't run a paid bug bounty program yet; we plan to launch one later. Until then, we thank researchers publicly, with their permission.

Acknowledgments#

With their permission, we list here the researchers who report valid vulnerabilities to us. No acknowledgments yet.

How we protect Tokentide#

Zero data retention architecture#

• Zero data retention, guaranteed on Private models. Request and response bodies stream through memory and are never logged or stored, on any endpoint.
• Every day, canary tests send a unique marker through the Service and search our logs and databases to check that it never appears.
• Venice receives a pseudonymous per-account identifier, never your identity, IP address, cookies or user agent.

Encryption and transport security#

• TLS everywhere, with HSTS preload on our domains.
• The most sensitive secrets, such as our keys with the upstream model provider, are sealed with AES-256-GCM authenticated encryption under keys held only in our hosting provider's encrypted environment variables, outside the database, and are never stored in plaintext.
• We support end-to-end encrypted models, for which we only relay ciphertext.

Web application protections#

• A nonce-based Content Security Policy with strict-dynamic.
• No third-party scripts on authenticated pages. Card payments use Stripe's hosted checkout page, so no payment script runs on our pages.
• HttpOnly, Secure and SameSite session cookies, origin checks against cross-site request forgery, rate limiting and a web application firewall.

Keys, accounts and administrator access#

• API keys are shown once and stored only as HMAC-SHA-256 hashes. Their prefixes include a checksum, so secret scanners can detect leaked keys.
• Each key can have spend caps, a maximum multiplier, an IP allowlist and an expiry date, and can be revoked instantly.
• Customers can sign in with passkeys (Face ID, Touch ID, Windows Hello, a phone or a security key), and we offer to create one after any sign-in that didn't use a passkey. Two-factor authentication is available too; we check new passwords against known data breaches and email you about sign-ins from new devices and about new sign-in methods.
• Administrators must use passkeys, with TOTP as a backup factor, and their sessions are short and separate.

Data and money integrity#

• Each application uses its own least-privilege database role.
• Balances change only through audited database functions. Money movements are idempotent, recorded in a double-entry ledger and checked every night.
• A hash-chained, append-only audit log records security-relevant actions and is verified every day.
• All the data we store is stored in the United States (AWS US East), encrypted at rest.

Testing and audits#

• An external penetration test before public launch.
• Regular dependency audits, and security updates applied within 24 hours for critical vulnerabilities and within 7 days for high ones.

Incidents and notifications#

We follow documented incident response procedures, and we report incidents that affect the Service on our status page. If a personal data breach occurs, we notify the Spanish Data Protection Agency (AEPD) within 72 hours where the law requires it, inform affected customers without undue delay, and notify customers who have signed our Data Processing Agreement within 48 hours.

Contact#

Security reports: security@tokentide.app. Other questions: support@tokentide.app.