# 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](/docs/metering-api)) 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.