Security
Short version: keys are hashed and shown once, MCP needs a paid plan when
accounts are on, hexum_check does not send your repo to a
model, and the browser database role cannot read secrets.
Keys
A hexum_live_… value is displayed once at mint time. We store a
BLAKE3 hash and a prefix. The engine authorizes from an in-memory map of
those hashes. Revoke a key in the dashboard if it leaks — agents using it
fail on the next call.
Account and database
Sign-in is email and password via Supabase Auth. Password reset is emailed.
Row-level security is on and forced. The authenticated role
may only SELECT non-secret columns (no key_hash,
invite token_hash, or Stripe customer ids). Writes go through
the Hexum API with the service role. Teams isolation: member usage is
visible to org admins. Join is invite-link only.
MCP path
POST /mcp and /v1 require Authorization: Bearer hexum_live_…. With accounts enabled, the
key’s user must be on Usage or Teams. Payloads live in process memory and
expire after 15 minutes idle. Zero Data Retention applies to Usage and
Teams: payloads are not stored in the application database
(ZDR). Paths are jailed to the workspace the agent
sends. There is no shell-out of user strings. JSON bodies are typed
(unknown fields ignored). hexum_check does not follow natural-
language instructions in files as if they were operator commands.
Transport and headers
TLS on hexum.dev. Responses set nosniff, DENY framing, a content-security policy,
referrer-policy, permissions-policy, and HSTS. Card numbers never touch
Hexum’s database.
What we do not claim
We do not currently ship a customer-visible audit log, a bug-bounty program, or a third-party security monitor. Server logs may be kept briefly for abuse. There is no admin UI besides your own dashboard. Dependencies are the crates and npm packages in this repo; we do not execute unreviewed packages at runtime beyond that lockfile.
Report a problem
Use Contact. Do not send live keys in email. Revoke first, then describe what happened.