Security at Corebee

Corebee runs on a modern, serverless infrastructure designed for reliability and security.

Application Layer

Hosted on Vercel, running on serverless functions with automatic scaling and zero-downtime deployments. Vercel's edge network provides DDoS protection and global CDN distribution. There are no persistent servers to patch or maintain — each function invocation runs in an isolated environment that is destroyed after execution.

Database Layer

All customer data is stored in Supabase (managed PostgreSQL) running on Amazon Web Services (AWS) infrastructure. Supabase provides managed database hosting with automatic failover, point-in-time recovery, and daily backups.

Caching Layer

We use Upstash (managed Redis) for ephemeral caching of rate-limit state and session data. Cached data is transient and does not serve as a primary data store.

Background Processing

Asynchronous workloads (knowledge base indexing, email delivery, billing reconciliation) are orchestrated by Inngest, which provides durable execution with automatic retries and observability.

Monitoring

Application errors are tracked via Sentry with a 50% sampling rate in production. PII scrubbing is enabled in the Sentry SDK configuration to minimize personal data in error reports.

Region

Customer data is stored and processed primarily in Mumbai, India: the database runs on Supabase (AWS ap-south-1) and the application on Vercel (bom1). Some sub-processors listed below (for example AI inference) process data in their own regions, including the United States. We disclose this to comply with PIPEDA Principle 4.1.3 cross-border transfer requirements.

We encrypt data at every layer — in transit, at rest, and at the application level for sensitive credentials.

In Transit

All connections to Corebee — browser to application, application to database, application to third-party APIs — are encrypted using TLS 1.2 or higher. HSTS (HTTP Strict Transport Security) is enforced to prevent protocol downgrade attacks.

At Rest

Database volumes are encrypted using AES-256 encryption managed by AWS. Database backups are similarly encrypted at rest.

Application-Layer Encryption

Integration OAuth tokens and third-party credentials stored in our database are encrypted using AES-256-GCM with a dedicated 256-bit encryption key. Each encrypted value uses a unique 96-bit initialization vector (IV) and a 128-bit authentication tag to ensure both confidentiality and integrity. The encryption key is stored as an environment variable and is never committed to source control.

User Authentication

Corebee uses Supabase Auth for user authentication, supporting email/password login. Session tokens are stored in cookies with secure attributes: HttpOnly, Secure, and SameSite=Lax.

Role-Based Access Control (RBAC)

Organizations support four roles — owner, admin, member, and viewer — with permissions enforced at both the application layer and the database layer via Row-Level Security policies.

Widget Authentication

The embeddable customer-facing widget uses a multi-layered authentication system:

• Website token uniquely identifies each widget installation.
• Optional HMAC-SHA256 identity verification with timestamp-based replay protection (60-second clock-skew window) allows customers to cryptographically verify end-user identity.
• JWT-based cross-device authentication enables conversation continuity across devices with org-scoped token validation.
• Domain allowlisting restricts widget loading to customer-specified domains.

CSRF Protection

All state-changing requests (POST, PUT, PATCH, DELETE) are validated against Origin and Referer headers. Widget mutation requests require an additional X-Widget-Token header match. API key and Authorization header presence is recognized for server-to-server calls.

API Key Security

API keys are hashed with SHA-256 before storage. Plaintext keys are displayed only once at creation time.

AI features are central to Corebee, and we apply dedicated security controls to protect against AI-specific threats.

No Training on Customer Data

We do not use your data to train, fine-tune, or improve any AI model. Both of our AI providers — OpenAI and Anthropic — operate under API terms that prohibit using API input/output data for model training. Your data is used solely for real-time inference.

Prompt Injection Protection

We implement a multi-layered defense against prompt injection attacks:

• 30+ regex patterns detecting known injection techniques (instruction override, role manipulation, delimiter exploitation, output manipulation).
• Unicode obfuscation detection identifies zero-width character insertion and Cyrillic/Greek homoglyph attacks used to bypass pattern matching.
• Entropy-based analysis detects high-entropy segments (Shannon entropy threshold of 4.5 bits/character) that may indicate base64-encoded or otherwise obfuscated payloads.
• Input sanitization removes null bytes and control characters, normalizes whitespace, and enforces a 10,000-character input limit.

Output Validation

AI-generated responses are validated before delivery:

• System prompt leak detection catches attempts to extract system instructions via 10+ detection patterns.
• PII maskingautomatically redacts social security numbers, credit card numbers, passport numbers, and driver's license numbers from AI outputs.
• URL domain allowlisting strips external URLs from AI responses, permitting only corebee.ai domains.
• Output length limits enforce an 8,000-character maximum on AI responses.

Content Moderation

Built-in moderation detects harmful content categories including violence, hate speech, and self-harm. Self-harm content and hate speech trigger automatic escalation to human agents.

Abuse Detection

Rapid-fire message detection (5 messages in under 10 seconds) and duplicate message detection (3+ identical messages) prevent automated abuse of AI endpoints. Conversation length is capped at 30 turns and 50,000 tokens.

Every customer's data is strictly isolated from all other customers. We enforce isolation at multiple layers to prevent cross-tenant data access.

Database-Level Isolation (RLS)

PostgreSQL Row-Level Security policies are enforced on all tenant data tables. Every table containing customer data includes an org_id column, and RLS policies ensure that authenticated queries can only return rows belonging to the user's organization. This is enforced by the database engine itself — it cannot be bypassed by application code using the standard client.

Application-Level Isolation

Organization membership is verified at the application layer before every data operation. The service client (which bypasses RLS for system operations like webhook processing and background jobs) always includes explicit org_id filtering.

Widget Isolation

Each widget instance is bound to a specific organization via its website token. Widget requests are authenticated and scoped to a single organization before any data is returned. HMAC identity verification and domain allowlisting provide additional isolation guarantees.

IDOR Prevention

All resource access patterns return HTTP 404 (not 403) for resources belonging to other organizations, preventing enumeration of resource existence across tenants.

We enforce rate limits across all API surfaces to prevent abuse, cost exhaustion, and denial-of-service attacks.

Architecture

Rate limiting uses a distributed system backed by Supabase for cross-instance state persistence, with an in-memory sliding-window primary path for zero-latency enforcement. A circuit breaker pattern ensures the system degrades gracefully if the database is temporarily unavailable — rate limiting falls back to per-instance in-memory enforcement rather than failing open without limits.

IP Resolution

Client IP addresses are resolved using trusted proxy headers (x-vercel-forwarded-for from the Vercel edge, which cannot be spoofed by clients) rather than the user-controllable x-forwarded-for header.

Response Headers

Rate-limited responses include standard headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After) so clients can implement appropriate backoff.

Corebee enforces strict security headers on all responses via edge middleware.

Request ID Tracing. Every request receives a unique x-request-id header for end-to-end tracing across application logs, error reports, and audit events.

Corebee maintains comprehensive audit logs for compliance, incident investigation, and operational transparency.

General Audit Log

Tracks 30+ event types across the platform:

• Authentication events: user login, logout, failed authentication attempts
• User management: user creation, updates, deletion, password changes
• Organization management: creation, updates, member additions/removals, role changes
• Conversation lifecycle: creation, assignment, transfer, merge, resolution, deletion
• Message operations: sent, edited, deleted
• Administrative actions: settings changes, webhook management, API key creation, data exports/imports, bulk actions

Settings Audit Log

A dedicated audit trail captures every settings change with field-level granularity — recording the specific field modified, old value, new value, the user who made the change, their IP address, and user agent. This supports diff-based change tracking for compliance reviews.

Security Monitoring

Automated checks run against audit data to surface:

• Authentication failure spikes (alerting thresholds at 20+ and 100+ failures in 24 hours)
• Unacknowledged high/critical security alerts
• Budget warning alerts for AI cost anomalies

MVSP (Minimum Viable Secure Product)

Corebee's security controls align with the MVSP checklist, the industry-standard baseline for enterprise-ready SaaS applications. Our implementation covers:

• Business controls: security contact, vulnerability disclosure, customer testing
• Application design controls: SSO support (via Supabase Auth), HTTPS-only, security headers, CSRF protection
• Application implementation controls: dependency management, logging, encryption
• Operational controls: incident response, data handling

CAIQ (Cloud Security Alliance)

We maintain alignment with the CSA Consensus Assessments Initiative Questionnaire (CAIQ) for cloud security. Key areas of coverage include identity and access management, data security and encryption, audit logging, and incident management.

PIPEDA Compliance

For Canadian customers, we provide:

• A PIPEDA-compliant Data Processing Agreement (DPA) with all 13 articles covering processing instructions, subprocessor management, cross-border transfers, data subject rights, and breach notification
• Transparency about where data is stored (Mumbai, India) and which sub-processors are outside Canada, per Principle 4.1.3
• 30-day response windows for access, correction, and deletion requests
• 24-hour breach notification to customers with cooperation with the Office of the Privacy Commissioner (OPC)

SOC 2 Roadmap

SOC 2 Type I certification is on our roadmap, with Type II to follow. We are building toward certification by implementing and documenting the controls described on this page.

Implemented: Encryption at rest and in transit, RBAC, audit logging, rate limiting, tenant isolation via RLS, incident response procedures, input validation and sanitization.

In progress: Formalizing security policies, onboarding a SOC 2 auditor, completing control documentation.

We will update this page when our SOC 2 audit timeline is confirmed.

We use the following third-party services to operate Corebee. Each subprocessor is bound by data processing agreements.

We notify customers at least 30 days before adding a new subprocessor. If you have concerns about a subprocessor, contact us at jonathan@corebee.ai.

Data Retention

• Active customer data: Retained for the duration of your subscription plus 30 days after termination for data export.
• Backups: Encrypted backups are retained for up to 90 days on a rolling rotation schedule. Data in backups is not actively processed.
• Audit logs:Retained per your organization's configuration.
• Error monitoring data: Sentry retains error data per their standard retention policy (90 days).

Data Deletion

• Upon account termination, you may request export of all your data in JSON or CSV format.
• Active production data is deleted within 30 days of a deletion request.
• Backup data is purged through the standard 90-day rotation cycle.
• We provide written confirmation of deletion upon completion.

Data Minimization

• We collect only the data necessary to provide the Service.
• AI inference is performed in real-time; we do not maintain separate copies of customer data for AI purposes.
• Sentry error monitoring operates at 50% sampling with PII scrubbing enabled.
• Session replay (PostHog) is limited to the public marketing site and does not operate within the authenticated application.

Consent Management

Corebee implements a consent management system that:

• Respects the Global Privacy Control (GPC) signal (Sec-GPC: 1 header).
• Auto-grants analytics and marketing consent only for visitors from jurisdictions that do not require prior opt-in.
• Allows users to manage their consent preferences at any time.
• Uses secure cookies (Secure, SameSite=Lax) for consent state storage.

We welcome responsible security research. If you discover a vulnerability in Corebee, please report it to us.