ReckonBuilt to be the safest vendor you onboard.
Reckon carries one of the most sensitive responsibilities a vendor can — access to your AI provider keys. We treat that as the single largest trust risk we hold, and we designed the product around minimizing it.
Architecture
Read-only by design
We never sit in your request path to AI providers. We poll the admin/usage APIs they already expose and read what they report. There is no proxy, no TLS termination of your traffic, and no mechanism for us to see, route, modify, or throttle your AI calls.
We never see prompts or responses
Because we are a passive observer, we have no access to the content of your AI requests — no prompts, completions, embeddings, or files. We only ingest the aggregate usage numbers (tokens, model, cost) the provider publishes at the API-key level.
Separation of planes
The web application, background ingestion workers, and database run as separate concerns. Provider keys are only ever decrypted inside the ingestion worker — never in the web tier that serves your browser.
Encryption & key management
Envelope encryption for every provider key
Each API key is encrypted with AES-256-GCM using a unique per-key data key. That data key is itself encrypted by a master key (CMK) held in AWS KMS — the key material never leaves KMS. A leak of our database alone reveals nothing usable.
Encryption in transit
All connections use TLS 1.2+. Outbound calls to providers go through a single hardened HTTP client with strict timeouts.
Minimal exposure
Only the last four characters of a key are ever displayed in the app or written to logs. Plaintext keys never enter logs, error messages, or monitoring tools, and the plaintext data key is zeroed from memory immediately after use.
Key rotation
The KMS master key has automatic annual rotation enabled. Per-key data keys are single-use by construction.
Tenant isolation
Defense in depth
Every row of customer data carries an organization ID. Application queries are always scoped to the caller's organization, and Postgres row-level security policies enforce that scoping as a backstop.
Bugs fail closed
If a query is ever mis-scoped, row-level security returns zero rows rather than another organization's data — turning a would-be leak into an empty result.
Authentication & access
We don't roll our own auth
Authentication is handled by Clerk. We never store passwords. Sessions are JWT-based and validated server-side on every request. Social sign-in (Google, GitHub) uses our own OAuth credentials, scoped to email and profile only.
Roles
Organizations have admin and member roles. Sensitive actions — managing keys, billing, and integrations — are restricted to admins and enforced server-side.
Integrations & webhooks
Every inbound webhook is verified
Stripe webhooks are verified against the signing secret; Slack requests are verified with the signing secret and a timestamp window; Clerk webhooks are verified with Svix signatures. Unsigned or stale requests are rejected.
Scoped integration tokens
Slack and Linear tokens are stored with the same envelope encryption as provider keys and request only the scopes needed to post digests and file issues.
Operations & reliability
Idempotent, retryable ingestion
Usage ingestion is idempotent (safe to re-run) and isolated per key, so a single failing key never blocks others. Jobs run on managed infrastructure with retries and dead-letter handling.
Monitoring
Errors are captured in Sentry, tagged by organization, so we can detect and respond to issues quickly without exposing secrets.
Managed, backed-up infrastructure
We run on managed providers (Vercel, Supabase Postgres, AWS KMS, Inngest) with automated backups and point-in-time recovery on the database.
Data handling
Retention you control
Usage records are retained per plan (30 days Free, 365 days Pro) and pruned automatically. You can request deletion of your organization's data at any time.
No data resale, no model training
We never sell your data and never use it to train machine-learning models. Data is shared only with the sub-processors required to run the service, listed in our Privacy Policy.
Responsible disclosure
If you believe you've found a security vulnerability, please report it privately to brianmello96@gmail.com before disclosing it publicly. We'll acknowledge your report, investigate promptly, and keep you updated. We're grateful to researchers who help keep Reckon and its customers safe.