Enterprise Security & Audit Architecture

Boots Proposals is built with enterprise-grade security controls: multi-tenant data isolation at the database layer, a 3-level AI kill switch hierarchy, comprehensive audit logging, and alignment with OWASP LLM Top 10 risk categories.

Multi-Tenant Data Isolation

Every table containing customer data includes an org_id column with PostgreSQL Row Level Security (RLS) policies that prevent cross-tenant reads, writes, updates, and deletes. RLS is enforced at the database layer — not in application code — which means tenant isolation cannot be bypassed by a bug in the API.

Key controls:

• 36 public tables with RLS policies scoped to organization
• Tenant context set via Supabase Auth JWT claims
• Automated isolation tests validate cross-tenant access is blocked on every deployment
• Service role access is restricted to background workers with explicit audit logging

3-Level AI Kill Switch Hierarchy

Boots Proposals implements a kill switch system that can halt AI generation at three levels:

Level	Scope	Use Case
Level 1: Global	Entire platform	Emergency stop for all AI generation
Level 2: Organization	Single tenant	Disable AI for a specific customer
Level 3: Job	Single generation	Cancel a specific running job

The worker process checks all three levels before processing each job. Every kill switch activation is recorded in the audit log with the actor, timestamp, scope, and reason.

Runtime Audit Logging

The audit log captures security-relevant events across the platform:

• Kill switch events — activation, deactivation, scope, reason
• AI generation events — requested, completed, failed, retried
• Authentication events — login success/failure, signup, invite redemption
• Billing events — subscription changes, payment success/failure

Each event includes actor scope, user identity, IP address, user agent, and contextual metadata. Audit logs are written via a fire-and-forget pattern using the Supabase service role to ensure they cannot be tampered with by end users.

Security Headers

All responses include defense-in-depth security headers:

• Strict-Transport-Security (HSTS) — enforces HTTPS
• X-Frame-Options: DENY — prevents clickjacking
• X-Content-Type-Options: nosniff — prevents MIME sniffing
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy — restricts browser feature access

Infrastructure

Component	Provider	Security Posture
Web Application	Vercel	SOC 2 Type 2, ISO 27001, edge network with DDoS protection
Database	Supabase (PostgreSQL)	SOC 2 Type 2, AES-256 encryption at rest, TLS in transit
Background Worker	Fly.io	SOC 2 Type 2, Firecracker VM isolation, private networking
AI Model Provider	Anthropic (Claude)	SOC 2 Type 2, ISO 27001, zero data retention for API
Error Monitoring	Sentry	SOC 2 Type 2, ISO 27001, HIPAA attestation
Edge Security	Cloudflare	WAF, rate limiting, bot protection, DDoS mitigation
Payments	Stripe	PCI DSS Level 1, SOC 2 Type 2

OWASP LLM Top 10 Alignment

OWASP Category	Mitigation
LLM01: Prompt Injection	System prompts isolated from user input; output sanitization via DOMPurify
LLM02: Insecure Output Handling	Server-side HTML sanitization; Content Security Policy headers
LLM04: Model DoS	Per-tenant rate limits; job queue with bounded concurrency; kill switches
LLM06: Sensitive Info Disclosure	RLS tenant isolation; no raw prompt logging; PII scrubbed from error reports

Compliance & Trust Links

• Supabase Security — SOC 2 Type 2, encryption, shared responsibility model
• Vercel Trust Center — SOC 2, ISO 27001, PCI compliance
• Fly.io Security — SOC 2 Type 2, BAA availability
• Anthropic Trust Portal — SOC 2, ISO 27001, HIPAA
• Sentry Trust Center — SOC 2, ISO 27001, regional hosting