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 three roles (owner, agent 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. None of our AI model providers (OpenAI, Anthropic, Google Gemini) may use API inputs or outputs to train their models. 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 masking automatically 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

The limits in the table are kept in our Supabase database. If the database is briefly unavailable, each server instance falls back to its own in-memory count instead of dropping the limit. MCP tool limits (replies and notes, knowledge changes, deletes, bulk actions and the knowledge agent) are kept in Upstash (managed Redis). Those calls are refused if Upstash cannot be reached. Supabase and Upstash are both on our sub-processor list.

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 keeps an audit log for compliance reviews and incident investigation. It records exactly the events below.

General Audit Log

Records today:

• Settings changes, with the old and new value and who made them
• Conversation assignments and resolutions
• Data exports
• Messages sent by your team
• Actions the AI assistant proposed, ran or failed

Sign-in and sign-out events are not recorded in this log yet.

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:

• 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: HTTPS-only, security headers, CSRF protection. Single sign-on (SAML) for agency teams is not self-serve yet: the agency adds its identity provider and domains in the console (Security), then Corebee support finishes the connection. Other workspaces cannot use single sign-on yet.
• 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.

Canadian customers (PIPEDA)

What we give you to meet your own PIPEDA duties:

• Our Data Processing Agreement sets out processing instructions, sub-processors, international transfers, data subject rights and breach notification. You can sign it as a PDF.
• Where your data is stored (Mumbai, India) and which sub-processors are outside Canada, so you can meet Principle 4.1.3
• We respond to access, correction and deletion requests you forward to us within 72 hours and complete them without undue delay, so you can answer within PIPEDA's 30-day limit
• We tell you about a breach without undue delay and within 72 hours of becoming aware of it, as our DPA states

SOC 2 readiness

SOC 2 readiness work is underway; Corebee is not SOC 2 certified and has no SOC 2 report yet.

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 support@corebee.ai.

Data Retention

• Active customer data: Kept while your account is active and deleted on the schedule below when it ends. Agency workspaces can also set a shorter retention window per company.
• Backups: Encrypted backups are retained for up to 90 days on a rolling rotation schedule. Data in backups is not actively processed.
• Audit logs: kept for 3 years.
• 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.
• After an account ends, you have 30 days to export your Customer Data. Corebee then deletes it from its live systems within a further 30 days, and encrypted backups roll off within 90 days.
• On request, we confirm the deletion in writing.

Data Minimization

• We collect only the data necessary to provide the Service.
• AI inference runs in real time. The AI data we keep (your knowledge base search index, conversation summaries and AI logs) stays in your workspace and is deleted with it.
• Sentry error monitoring operates at 50% sampling with PII scrubbing enabled.
• Session replay runs only with your consent, and form fields are masked. It never runs in the agency console, on your customers' chat pages, or for signed-in Corebee staff.

Consent Management

Corebee implements a consent management system that:

• Respects the Global Privacy Control (GPC) signal (Sec-GPC: 1 header).
• Turns on analytics, session replay and marketing by default only for visitors outside the EEA, the UK, Canada, Brazil and Israel (or whose country cannot be told) who do not send a GPC signal. Visitors from those places see the banner, and nothing optional is stored until they choose.
• 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.