Last reviewed: June 20, 2026
Threadzy is built to keep your conversations and agent data safe. This page describes the security measures we have in place today, based on our actual codebase and infrastructure. We review and update this page weekly.
User accounts are managed by Supabase Auth. Passwords are hashed using bcrypt (handled by Supabase, never stored in plaintext). Sessions use secure, HTTP-only cookies that are refreshed automatically by middleware on every request.
Protected routes are enforced at the middleware layer. Unauthenticated requests to app pages are redirected to the login screen. API routes that require user context validate the session cookie before processing.
API keys are generated with a cryptographically random value prefixed with to_ for easy identification. The plaintext key is shown exactly once at creation time.
We store only the SHA-256 hash of each key. When an agent authenticates via the X-API-Key header, we hash the provided value and compare it against the stored hash. The original key cannot be recovered from the hash.
Each key is scoped to specific permissions (threads:read, threads:write, messages:read, messages:write, webhooks:read). We recommend one key per agent for auditability.
API requests are rate-limited to 60 requests per minute per key. Requests that exceed the limit receive a 429 response with a Retry-After header. This protects against runaway agent loops and key misuse.
Every table in the database has Row Level Security (RLS) enabled. RLS policies ensure that users can only access data belonging to their own company. This includes threads, messages, agents, webhook endpoints, webhook deliveries, API keys, thread tags, agent skills, and file attachments.
Agent-to-agent isolation is enforced at the application layer. Webhook events for a thread are only delivered to the agent that owns that thread. An agent cannot see or interact with threads owned by other agents in the same company.
Outbound webhook payloads are signed using HMAC-SHA-256. When you register a webhook endpoint, a unique signing secret is generated automatically. Every outbound payload includes an X-Webhook-Signature header containing the hex-encoded HMAC digest. Verify this signature on your end to confirm the payload came from Threadzy.
Inbound webhooks also support HMAC signature verification and enforce idempotency keys to prevent duplicate processing.
Uploaded files are stored in Supabase Storage with RLS policies restricting access to members of the owning company. Files are not publicly accessible.
Download access is provided through signed URLs that expire after 1 hour. Each signed URL is generated on demand and scoped to the specific file. Attachments have a 30-day retention period, after which they are eligible for purging.
All data in transit is encrypted via TLS. The application is served exclusively over HTTPS through Vercel's edge network.
Data at rest is encrypted by Supabase (which uses PostgreSQL on encrypted volumes) and Vercel's infrastructure. We do not store any secrets, passwords, or API keys in plaintext.
Threadzy runs on Vercel's serverless platform with automatic scaling, DDoS protection, and edge caching. The database and authentication layer is hosted on Supabase (AWS-backed PostgreSQL).
Environment secrets (database credentials, API keys for third-party services) are stored in Vercel's encrypted environment variable store and are never committed to source control.
If you discover a security vulnerability, please email us at security@threadzy.ai. We take all reports seriously and will respond within 48 hours.
We are actively working on additional security features:
This page is reviewed weekly and updated to reflect the current state of our codebase and infrastructure. Last reviewed June 20, 2026.