Security

This page describes how humanhours stores customer data, what we don't store, and how to report issues.

Data we store

For every authenticated /v1/track call:

• Your agent_id, task_type, and outcome strings.
• Your metadata object (free-form JSON), agent_duration_seconds, agent_cost, and human_baseline_minutes if you sent them.
• The fingerprint we compute (agent + task type + model + key id) for deduplication.
• The audit_sample (input/output excerpts up to 2000 chars, model, token counts) only on Pro and above. Free orgs send the field; we silently drop it.

We never log the raw HTTP body, request headers, or your Bearer token.

API keys

Keys are formatted hh_(live|test)_<8-char-prefix>_<48-char-secret>. Only the prefix and an argon2id hash of the full key are stored. The hash uses a server-wide pepper (API_KEY_PEPPER) so a database leak alone is not enough to brute-force keys.

When you generate a key, the raw value is shown once. We cannot recover it. Lost a key → revoke it from /api-keys and create a new one.

Revoking is immediate (≤5 minutes for in-memory caches to drain). Future requests with that key return 401 key_revoked.

Encryption

• In transit: TLS 1.2+ on every endpoint. The API rejects HTTP requests.
• At rest: Postgres on Supabase (EU region, Frankfurt) with encrypted volumes.

Region pinning

Both the application and the database run in EU regions. Customer data does not leave the EU.

Webhook signing

We sign every outbound webhook with HMAC-SHA256. The X-Humanhours-Signature header includes a unix timestamp so you can reject replays older than 5 minutes. See /docs/api/webhooks for the verify-step recipe.

Reporting issues

Email support@triadagency.ai for vulnerability reports. We acknowledge within 1 business day. Please don't open public issues for security-relevant findings.

Subprocessors

DPA available on request: support@triadagency.ai.