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. Passwords are hashed with bcrypt.
• ·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

1. A producer sends a payload (or a bundle of files) to kubbi.
2. kubbi encrypts the payload (per-file for packages) and returns a claim URL.
3. Only the claim URL moves through the workflow.
4. The consumer claims the payload using the URL.
5. The payload is wiped when it expires, is deleted, or reaches its retrieval limit.

This design reduces how often raw sensitive data is 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

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.