Security and data handling

The security story is unusually short because the architecture refuses most of the data other tools hold.

Metadata only, by construction

The platform ingests model names, token counts, regions, and timestamps. It never proxies your AI traffic, never sits between you and your provider, and never receives prompt or completion content. Every inbound payload is deep-scanned before parsing: any key anywhere in the JSON with a content-shaped name (prompt, messages, text, response, and the rest of the list in the metering API reference) is rejected with HTTP 422 and nothing is stored. The usage-events table has no content columns, and a test asserts its exact column list, so the invariant cannot erode quietly.

Two practical consequences:

  • A breach of this platform cannot leak your prompts; they were never here.
  • An outage of this platform cannot interrupt your AI usage; it holds no position in your request path.

Credentials

Managed-connection credentials (provider admin keys, Google service account keys) are encrypted at rest with AES-256-GCM. The encryption key lives only in the application environment, never in the database, so the database alone cannot decrypt a credential. Credentials are write-only through the API: they are never returned, and removal deletes the ciphertext. Only read-only, usage-scoped credentials are requested in the first place (Anthropic and OpenAI admin usage keys; Google roles/monitoring.viewer).

Console keys are stored as SHA-256 hashes. The one-time signup reveal stores the key encrypted only until you view it, then clears it.

Payment data

Card details go directly to Stripe and never touch this platform; the database stores Stripe token references only. Subscriptions, card changes, and cancellation run through Stripe's hosted surfaces.

Data layer

Postgres (Supabase) with row-level security enabled on every table and policies scoped to a dedicated application role; the public PostgREST roles have no policies and no access. Certificates, estimates, and the double-entry ledger are append-oriented: every credit movement is recorded as balanced postings, and reconcile asserts the ledger balances on every run.

Subprocessors

  • Vercel: application hosting.
  • Supabase: Postgres database.
  • Stripe: payments, invoices, tax.
  • Certificate suppliers (Bonneville Environmental Foundation) receive purchase orders, not your usage data.

Retention

Usage metadata, estimates, ledger entries, and certificates are retained as the account's permanent record: they are the substantiation for published claims and stay reproducible under the methodology version that produced them. Connection credentials are deleted on removal. Account deletion requests: info@tahosasystems.com (billing-email verified).

Reporting a vulnerability

security@tahosasystems.com (or info@tahosasystems.com). Please include reproduction steps; we commit to acknowledging within two business days.

Machine-readable: this page as markdown, the whole product as llms-full.txt.

Next: what it costs

See pricing