Built tenant-safe from day one
Anchor holds real business and customer data for many businesses in one system. Here is specifically how we keep it separated and how we keep AI from becoming a way around that separation.
Tenant isolation, checked on every request
Every business-owned table carries a business_id. Before any query touching it runs, the API checks the caller's authenticated membership in that business — that check, not the database, is what stops one business from reading another's data. The tables also have row-level security policies defined, but Anchor's own backend connects with a role those policies do not restrict, so RLS is not what is protecting you day to day; the API check is. This is tested with automated cross-business attack scenarios.
AI that can't grant itself access
The AI never chooses which business's data to read, and never generates its own database queries. Every tool the owner AI can call — sales summaries, low-stock lists, customer lookups — takes the caller's already-authenticated business_id as a plain argument, supplied by our backend, never by the model. Customer-facing answers are generated only from product facts retrieved by code beforehand; if the catalog has no answer, the AI says so and offers a human handoff instead of guessing.
Real authentication, verified server-side
Every request identifies its caller through Supabase-issued, cryptographically verified tokens. Business membership and role (owner/admin/staff) are checked on every write; role escalation is blocked at the API layer — no member can grant themselves or anyone else ownership.
Upload validation that checks the actual bytes
Product photos, business logos, and voice messages are validated on file size, declared MIME type, and the file's real magic bytes — not just its filename or claimed content type — before being stored under a tenant-scoped, unguessable path.
Verified webhooks, automation under your rules
Inbound Messenger and billing-provider webhooks are only processed after their cryptographic signature is verified; anything else is rejected before it touches your data. AI-proposed actions are written as pending actions and, by default, wait for an owner or admin. Only an owner can allow low-risk follow-up messages to run automatically, within a daily limit and quiet hours; restock suggestions and alerts always wait for a person. Every change to these rules is recorded.
No secrets in the frontend, ever
Service credentials, database connections, and provider API keys live only in backend environment configuration and are never bundled into frontend code or exposed through any API response.
Where we are today
Anchor is an early-stage product. We do not currently hold SOC 2 or ISO 27001 certification, and we won't claim otherwise. What we can say honestly: tenant isolation, authorization, and AI-tool scoping described above are exercised by an automated test suite that runs on every code change, including tests that specifically attempt cross-tenant access and confirm it fails.
Found a security issue? We want to know before anyone else does — email security@pinevon.com.