Security at BoardBid
How we protect your pricing data, quote history, and customer relationships. This page is intentionally thorough — enterprise procurement and security teams should find everything they need here.
Overview
BoardBid handles quote requests, customer names, pricing information, and derivative business data. Our security posture treats this as business-critical: a leak of sheet-plant pricing logic or buyer RFQ history would cause real harm. We've designed accordingly, from the database layer up.
Short version: Bearer token auth, row-level security on every table, Supabase (SOC 2 Type II) infrastructure, TLS everywhere, audit logs on every request. No customer data in client-side code, no service-role keys in browsers.
Authentication & authorization
API keys
All API access uses Bearer tokens in the Authorization header. Keys are scoped to a single tenant (organization) and enforce permissions via row-level security at the database layer. This means even if an API key were compromised, the attacker could only ever access that tenant's data — never another tenant's.
- Keys are rotatable without downtime (multiple active keys per tenant)
- Separate keys recommended per environment (production / staging / CI)
- Every authenticated request is logged with request ID, timestamp, and client identifier
- Failed authentications are rate-limited and flagged for review
Two types of keys
| Key type | Use | Respects RLS? |
|---|---|---|
anon (standard) | Browser, mobile, client-side, partner integrations | Yes — full tenant isolation |
service role | Server-side automation only. Never expose to clients. | No — admin access |
Critical: Service role keys bypass row-level security and must only ever exist in server-side code. If you need server-side automation, use environment variables or a secret manager (Vault, AWS Secrets Manager, etc.) — never commit them to source control or ship them in a client binary.
Data isolation
Every table in the BoardBid database has row-level security (RLS) enabled. This means:
- Plant A cannot see Plant B's quote logs, even if they share the same database
- Buyer X cannot see Buyer Y's RFQ history
- Cross-tenant access requires an admin action logged to our audit trail
RLS is enforced at the Postgres level, not the application level. This means a bug in our application code cannot accidentally leak data across tenants — the database itself refuses the query.
Specifically, what's isolated
- Parse logs (
parse_logs) — inputs, outputs, confidence, trace - Corrections (
parse_corrections) — your training signal stays yours - Quote records (
quotes, when available) — priced offers and margin data - Customer data (
customers) — your customer list is not shared with other tenants or used to train models
Encryption
In transit
TLS 1.3 on every endpoint. HTTP requests to any BoardBid URL are redirected to HTTPS. Edge Function endpoints enforce TLS at the load balancer and reject plaintext.
At rest
Database storage is encrypted at rest using AES-256 (managed by Supabase, which sits on AWS). Backups are similarly encrypted and retained per the tenant's plan.
Secrets
API keys (Anthropic, etc.) and database credentials are stored in Supabase Edge Function secrets — encrypted at rest, decrypted only in function memory, never logged or exposed in responses.
Infrastructure
BoardBid runs entirely on Supabase, which provides:
- SOC 2 Type II certified infrastructure
- ISO 27001 certified
- GDPR-compliant data handling
- HIPAA eligibility (enterprise tier)
Edge Functions are deployed globally via Deno Deploy for low latency. Static assets are served through Netlify's global CDN.
Compliance — current and roadmap
| Framework | Status |
|---|---|
| SOC 2 Type II (via Supabase infrastructure) | Inherited |
| SOC 2 Type II (BoardBid company-level) | 2026 Q4 target |
| GDPR (data subject rights, DPAs available) | Live |
| CCPA (California residents) | Live |
| ISO 27001 | 2027 target |
Enterprise customers can request a Data Processing Agreement (DPA) and security questionnaire response by emailing security@boardbid.io.
Data handling
What we collect
- Account information: email, name, organization
- Quote data: inputs you submit, outputs we return, timestamps
- Operational telemetry: request latencies, model versions, error rates
- Billing information: handled by our payment processor, never stored on our servers
What we do not do
- We do not sell your data to third parties
- We do not use your quote data to train models for other tenants
- We do not share customer names or pricing across tenants, ever
- We do not allow advertising networks access to product analytics
Retention
Default retention:
- Quote logs and corrections: retained indefinitely (this is the observability signal our product depends on)
- Inactive accounts: prompted for data export at 12 months of inactivity; deleted at 24 months
- Billing records: retained per US tax regulation (7 years minimum)
Enterprise customers can request custom retention policies, including shorter retention windows and automated purge on quote resolution. Contact security@boardbid.io.
Incident response
If a security incident affects customer data, we will:
- Contain the incident immediately
- Notify affected customers within 72 hours with what we know
- Provide a post-incident report within 14 days including root cause and remediation
- Cooperate fully with regulators per applicable jurisdictions
Vulnerability disclosure
If you believe you've found a security vulnerability in BoardBid, please email security@boardbid.io. We ask that you:
- Give us reasonable time to investigate and remediate before public disclosure (standard 90-day window)
- Do not access customer data beyond what's minimally necessary to demonstrate the issue
- Do not perform denial-of-service testing against production infrastructure
We acknowledge all good-faith reports within 48 hours.
Security contact
General: security@boardbid.io
For enterprise security reviews, DPAs, questionnaires, and custom compliance requests, the same address works.
Page last updated 2026-04-16.