Security & Operations

kubbi is built for temporary, controlled data handoffs. This page covers the security model, encryption, access controls, and operational considerations.

Security at a glance

Encrypted at rest

Every payload is encrypted with AES-256-GCM before storage, each with a unique IV and auth tag. Multi-file packages encrypt each file individually. The database never holds plaintext payload data.

Temporary by design

Every kubbi expires automatically. TTL ranges from 1 minute up to a maximum that depends on your plan tier.

Burn after read

Set max_retrievals: 1 for one-time pickup, or allow a small number of retrievals for controlled fan-out.

Producer-controlled deletion

Producers can delete a kubbi early. Expired or exhausted kubbis are removed automatically.

Minimal consumer access

Consumers do not need an account or API key. Possession of the claim URL is sufficient to inspect metadata and claim the payload.

Token and key hashing

Claim tokens and API keys are SHA-256 hashed before storage. Raw tokens exist only in the claim URL; raw API keys are shown once at creation. Dashboard passwords are hashed with bcryptjs (passwords live in the dashboard; the public API does not handle them).

Payload wiping

When a kubbi is burned, deleted, or expired, encrypted payloads are overwritten (not just deleted) before the status is updated.

HTTPS enforced

In production, all HTTP traffic is redirected to HTTPS.

CORS locked down

Only explicitly allowed origins can make browser-based requests (configurable via CORS_ORIGINS).

Rate limiting

Per-key request limits enforced per plan tier to prevent abuse.

Structured logging

JSON-native logs via pino for production observability.

Health checks

/health verifies both application and database connectivity.

How kubbi handles a handoff

The end-to-end flow (create, share the claim URL, claim, wipe) is on the docs overview. For packages, each file is encrypted individually.

The security consequence is that raw sensitive data is rarely copied into logs, prompts, queue bodies, task records, or shared workflow state.

Access model

Producers

Producers authenticate with API keys and can create, inspect, and delete the kubbis they own.

Consumers

Consumers use an unguessable claim URL. The claim URL is a bearer credential: anyone who has it may inspect metadata and claim the payload. Treat claim URLs like secrets.

Lifecycle controls

Control	Description
TTL	Every kubbi is temporary and expires automatically based on its TTL.
Retrieval limits	`max_retrievals` controls how many times a payload can be claimed.
Burn after read	One-time handoffs are destroyed immediately after successful claim.
Early delete	Producers can revoke access by deleting the kubbi before it is claimed.
Inspect before claim	Consumers can confirm what they are about to claim without consuming the payload.

Shared responsibility

kubbi provides the handoff layer. You are responsible for how you use it. In particular:

Protect API keys and rotate or revoke them when needed.
Treat claim URLs as secrets and share them only through channels appropriate for the data.
Choose TTLs and retrieval limits that match the sensitivity of the payload.
Avoid using kubbi as long-term storage, archival storage, or a backup system.
Ensure you have the rights, notices, and consents needed for the data you send through kubbi.
Configure downstream systems so claimed data is handled securely after retrieval.

Privacy and retention

Payloads are temporary.
Payloads can be burned on claim, expiry, or early delete.
Account, billing, security, and operational metadata may be retained longer where reasonably needed to operate the service, prevent abuse, investigate incidents, comply with law, or support customers.

See the Privacy Policy for more detail.

Security contact

For security questions, vendor reviews, or to report a suspected issue, contact support@kubbi.ai.

If you need a security questionnaire, DPA, or enterprise review process, contact support@kubbi.ai.