1. Executive Summary
Corebee is a multi-tenant AI customer support platform serving organizations that handle sensitive customer interactions, including background check and identity verification workflows. Security is integrated at every architectural layer, not bolted on after the fact.
Key security controls in production today:
- Row-Level Security on 95%+ of database tables, including all PII tables
- AES-256 encryption at rest (Supabase/AWS infrastructure), TLS 1.2+ for all data in transit, and AES-256-GCM with random IV and authentication tags for application-layer secret storage (OAuth tokens, integration credentials)
- 30+ prompt injection detection patterns including unicode obfuscation detection (zero-width characters, homoglyph substitution) and Shannon entropy analysis for encoded payload detection
- Comprehensive audit logging across 34+ discrete event types spanning three complementary logging systems
- OWASP Top 10 and API Security audit completed February 2026 — all 45 identified findings remediated
- Infrastructure hosted exclusively on SOC 2 Type II certified providers: Vercel (edge/compute), Supabase on AWS (database/auth), and OpenAI (LLM inference)
This document provides a technical overview of Corebee's security architecture, data protection controls, AI-specific safeguards, and compliance posture. All claims reflect what is implemented and running in production as of the date above.
2. Architecture Overview
Corebee uses a three-tier architecture. Each tier enforces independent security controls, so a compromise at one layer does not grant unrestricted access to the next.
2.1 Edge Layer — Vercel Edge Network
- DDoS mitigation provided by Vercel's infrastructure (Cloudflare-backed)
- CDN with automatic TLS termination — all traffic is HTTPS; HTTP requests are redirected
- Security headers injected at the edge:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload(2-year HSTS with preload)X-Frame-Options: DENYX-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-originContent-Security-Policy— context-specific policies for application pages, widget embed, and API routes
2.2 Application Layer — Next.js API Routes
- Authentication middleware validates sessions on every protected route before any business logic executes
- CSRF protection on all state-changing operations
- Rate limiting enforced at multiple levels: global abuse guard at 120 requests/minute per IP across all routes, AI-specific limit of 60 requests/minute per organization, and API key limit of 100 requests/minute per key
- SSRF protection on all outbound requests: private IP range blocking (
10.x,172.16-31.x,192.168.x,127.x,169.254.x), DNS rebinding defense, and protocol restriction tohttp/httpsonly - Input validation at all system boundaries using schema validation
2.3 Data Layer — Supabase PostgreSQL
- Row-Level Security (RLS) policies on 95%+ of database tables, including all PII tables. The remaining unprotected tables contain no PII (public configuration, enum lookups, migration metadata).
- 570+ explicit
org_idscope checks in application code provide defense-in-depth above the RLS layer - AES-256 encryption at rest via AWS infrastructure (Supabase runs on AWS with encrypted EBS volumes)
- Connection pooling via Supabase's PgBouncer — no direct database access from the public internet
2.4 Authentication Paths
Three authentication mechanisms serve different access patterns. All three converge on the same RLS-protected database layer:
| Path | Mechanism | Use Case |
|---|---|---|
| User session | Supabase Auth (bcrypt password hashing, JWT session tokens) | Dashboard, agent inbox |
| Widget | HMAC-SHA256 signature + JWT with anti-replay timestamps | End-user chat widget embedded on customer sites |
| API key | Scoped, revocable keys with per-key rate limits | Programmatic integrations |
3. Data Protection Controls
3.1 Encryption
| State | Method | Detail |
|---|---|---|
| At rest | AES-256 | AWS EBS encryption (Supabase infrastructure) |
| In transit | TLS 1.2+ | All connections; HSTS enforced with 2-year max-age |
| Application secrets | AES-256-GCM | OAuth tokens and integration credentials encrypted with random initialization vectors and authentication tags before database storage |
3.2 Tenant Isolation
Every database query for tenant data is scoped by org_id through two independent mechanisms:
- PostgreSQL RLS policies — enforced at the database engine level regardless of application behavior. The database rejects any query that attempts to access rows outside the authenticated organization's scope.
- Application-layer scope checks — 570+ explicit
org_idfilters in application code provide defense-in-depth.
There is no shared-table access pattern where one tenant can read or write another tenant's data.
3.3 Security Headers
All responses include the following headers:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadContent-Security-Policy(context-specific: restrictive for app, permissive for widget embed contexts)X-Frame-Options: DENYX-Content-Type-Options: nosniffReferrer-Policy: strict-origin-when-cross-origin
4. AI Security
Corebee uses OpenAI's API for LLM inference. The following controls govern AI behavior and data handling.
4.1 Prompt Injection Defense
- 30+ regex-based detection patterns scan all user input before it reaches the LLM
- Unicode obfuscation detection identifies zero-width characters, homoglyph substitution, and bidirectional text override characters used to disguise malicious instructions
- Shannon entropy analysis flags high-entropy input segments that may contain Base64-encoded or otherwise obfuscated payloads
- Input rejected when injection patterns are detected — the request does not reach the LLM
4.2 Input and Output Limits
| Control | Limit |
|---|---|
| User input length | 10,000 characters |
| LLM output length | 8,000 characters |
| Conversation turns | 30 per session |
| Session token budget | 50,000 tokens |
4.3 PII Handling
- Deterministic PII stripping before any data is written to knowledge base indexes. Customer identifiers are removed before learning occurs.
- Configurable per-organization redaction mode for live conversations — organizations can enable PII anonymization before LLM processing
- No model training on customer data. Corebee uses the OpenAI API, whose terms of service explicitly prohibit using API-submitted data for model training.
4.4 Data Handling for Background Check Support
For organizations processing background checks and identity verification:
- Customer names, emails, and case identifiers are processed solely for ticket resolution
- PII redaction mode is available and can be enabled per-organization to anonymize identifiers before LLM processing
- Conversation data is retained according to each organization's configured retention policy
- Data erasure requests are fulfilled within 30 days of receipt
5. Monitoring and Incident Response
5.1 Audit Trail
Three complementary logging systems capture security-relevant events:
| System | Purpose | Retention |
|---|---|---|
security_events |
Authentication failures, permission violations, injection attempts, suspicious activity | Persistent |
settings_audit_log |
All configuration changes with before/after snapshots and actor identification | Persistent |
api_request_logs |
API request metadata, response codes, latency, rate limit events | 90 days |
Combined, these systems track 34+ discrete event types.
5.2 Error Monitoring
- Sentry with PII masking enabled — stack traces and error context are captured without exposing customer data
- Alerts configured for error rate spikes and new error categories
5.3 Rate Limiting and Abuse Prevention
| Scope | Limit |
|---|---|
| Global abuse guard (per-IP) | 120 requests/minute across all routes |
| AI-specific (per-organization) | 60 requests/minute |
| Per-API-key | 100 requests/minute |
Requests exceeding limits receive 429 Too Many Requests responses.
5.4 SSRF Protection
All server-side outbound requests enforce:
- Private IP blocking — requests to
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,127.0.0.0/8,169.254.0.0/16, and IPv6 equivalents are rejected - DNS rebinding defense — resolved IPs are validated after DNS resolution
- Protocol restriction — only
httpandhttpsschemes are permitted
5.5 Incident Response
- Notification timeline: Affected customers notified within 24 hours of confirmed security incident
- Regulatory cooperation: Full cooperation with applicable regulatory reporting requirements
- Post-incident: Root cause analysis and remediation published to affected customers
6. Compliance Status
6.1 Current
| Standard | Status |
|---|---|
| MVSP (Minimum Viable Secure Product) | Baseline met |
| CAIQ (Consensus Assessments Initiative Questionnaire) | Self-assessment in progress |
| PIPEDA-compliant Data Processing Agreement | Available on request |
| OWASP Top 10 + API Security audit | Completed February 2026; all 45 findings remediated |
6.2 Roadmap
| Target | Milestone |
|---|---|
| Q3 2026 | Automated dependency scanning in CI/CD, MFA enforcement for all users, formal data retention policies |
| Q4 2026 | SOC 2 Type I readiness assessment (planned) |
| 2027 | SOC 2 Type I certification |
7. Subprocessors
All subprocessors maintain SOC 2 Type II certification or equivalent.
| Subprocessor | Function | Data Processed | Infrastructure |
|---|---|---|---|
| Supabase | Database, authentication | All application data | AWS (US regions) |
| Vercel | Edge hosting, compute | Request/response data | Global edge network |
| OpenAI | LLM inference | Conversation content (not used for training) | Azure/US |
| Sentry | Error monitoring | Stack traces (PII masked) | US |
| Inngest | Background job orchestration | Job metadata, task payloads | US |
| Twilio | SMS/voice channels | Phone numbers, message content | US |
| Polar (Polar Software AB) | Subscription billing | Billing identifiers | EU/US |
| Google (Google LLC) | AI response generation (Gemini) | Conversation content (not used for training) | US |
| Upstash | Distributed caching and rate limiting | Rate limit counters, cache keys | US |
| Meta | WhatsApp Business, advertising | Channel messages, ad events | US/EU |
8. Contact
For security inquiries, vulnerability reports, or to request the Data Processing Agreement:
Email: security@corebee.ai
This document reflects the production state of Corebee as of April 3, 2026. It is provided for security evaluation purposes and should be treated as confidential.