Trust
Security
Last reviewed August 7, 2026
Excellent is a platform for managing restaurant groups. Every group’s data lives in one database, isolated from every other group’s at the row level and enforced by the database itself on every read and write. This page states our security commitments and, for each, names the concrete mechanism that backs it. It is deliberately honest about what is on our roadmap but not yet shipped — those items appear under What’s next, never implied above it. Excellent is operated by Excellent AI LLC, an Arizona limited liability company based in Glendale, Arizona.
1. Our security commitments
Each restaurant group's data is isolated at the database row level.
Every business runs in the same database, but no group can read or write another group's records. Isolation is enforced by the database itself on every query, not by application code that could forget a check.
How: Every tenant-scoped row carries an org_id, and Postgres Row-Level Security is enabled on every table. A single function resolves your organization from your signed-in session, and each table's policy scopes reads and writes to it. A check in our automated test suite fails the build if any new table ships without Row-Level Security enabled.
Cross-tenant access is prevented by construction, not by convention.
When one party legitimately needs access to another's record — a guest opening a shared document, for example — that access is a specific, reviewed relationship, never a loosened security rule.
How: Cross-organization access only ever flows through a narrow, tenant-checked database function; we never widen a Row-Level Security policy to let one group see another's rows. Deterministic guards run on every pull request to assert it: no cross-tenant policy exists, every privileged database function is scoped to the caller's organization, and every one pins its execution path against injection.
Connected credentials are encrypted with keys the database never holds.
Secrets you connect — such as a social-account access token — are sealed before they are stored, using a key kept outside the database. A stolen database copy yields ciphertext, not usable credentials.
How: Tenant credentials are sealed with AES-256-GCM using a key held only in the application environment, never in Postgres. Each value carries its own random initialization vector and an authentication tag, so tampered or wrong-key data fails closed instead of decrypting to something wrong.
Every change is recorded in an append-only, tamper-evident log.
Changes to records are written to an audit log that cannot itself be edited or deleted, so your operational history stays trustworthy.
How: A database trigger writes an entry for every mutation into a log table whose own trigger rejects updates and deletes. A coverage check in our test suite fails the build if a new tenant table is added without audit logging, so the trail can't quietly develop gaps.
You can take a complete copy of your data at any time, without asking us.
Your records are yours. An administrator can download the whole organization — every business record, row for row — as a single file from inside the product, with no request, no ticket, and no waiting on us.
How: The export runs under the requesting administrator’s own session, so the same row-level isolation described above scopes it to your organization and nothing else — there is no privileged database function anywhere in that path — and the download is restricted to organization administrators. What it contains is defined by one manifest file, and a check in our test suite fails the build if any table carrying an organization identifier is missing from it without a stated reason, so the export cannot quietly fall behind the schema. Secret values such as connected-account credentials are masked in place, and a table that fails to read is reported inside the file rather than silently omitted.
We never send real email or texts from test or unverified channels.
Non-production environments and unverified senders cannot send messages to real people. This is enforced in the sending code, not left to configuration discipline.
How: The outbound gate lives inside the send client: a message goes out only when the environment is production, the organization is real, and that specific channel has been verified — otherwise it is routed to a catcher and never reaches a recipient. Email-domain verification and phone verification are tracked as two independent facts, so one can never open the other. No tenant has a verified SMS channel today, so no text messages are sent.
Security is checked on every change and probed on a schedule.
Our security controls are tested continuously — automatically on every code change, and on a recurring schedule against the running application.
How: The full deterministic security suite runs on every pull request: secret scanning, static analysis for this stack's known footguns, and the tenant-isolation and Row-Level Security checks described above. On top of that, a read-only surface probe runs nightly against production; a cross-tenant and IDOR matrix (39 probes) runs on demand and last ran with no isolation breach found — it publishes its own coverage scorecard naming the parts of our database-function surface it has not yet reached, which we are still widening; and a weekly adversarial red-team agent threat-models the code for logic flaws the deterministic checks cannot see. Our third-party dependencies are held to the same gate: a bot opens grouped update pull requests on a schedule, and a separate check fails the build — at any severity, in both our shipped and our build-time dependencies — if a published advisory is open against anything we ship. That check runs nightly as well as on every change, so an advisory published against code we have already shipped is caught without waiting for the next one. Findings flow into a single reviewed queue.
Third-party analytics stops at our marketing pages.
We measure traffic on our public website. We do not measure your team inside the application, and we do not measure the no-login links you send your guests — so the pages your staff open and the links your guests click are never described to an analytics provider.
How: Google Analytics is gated on the route, not just on the hostname: it loads only on an explicit list of public marketing pages, and every other page — the signed-in workspace, the guest event, invoice, and document links, the sign-in and sign-up doors — is excluded by default, including pages that do not exist yet. A check in our test suite reads the application’s own route tree on every pull request and fails the build if any page behind sign-in, or any page whose link carries a guest access token, would be measured.
AI features run inside the same isolation and never silently change your data.
The platform uses AI to draft and assist, but AI operates within the same tenant boundaries as everything else and never acts on production data on its own.
How: AI reads go through the same row-level isolation as any other request. Our engine authors AI configuration at design time; a deterministic, versioned engine executes it at runtime — AI never mutates production data or schema by itself. Model outputs that reference your records are validated against the real set before they are used, and AI usage is cost-stamped and capped per organization.
2. Encryption and infrastructure
In transit. All traffic is served over TLS. The application sets HTTP Strict Transport Security (a two-year max-age, including subdomains) so browsers refuse to connect over plain HTTP, along with X-Frame-Options: DENY and a clickjacking-blocking Content-Security-Policy (frame-ancestors ’none’),X-Content-Type-Options: nosniff, a strict referrer policy, and a restrictive permissions policy that disables camera, microphone, geolocation, and topics by default. A full script/style Content-Security-Policy is on our roadmap; today’s policy covers framing only.
At rest. The database, its backups, and file storage are hosted on Supabase and Vercel, which encrypt data at rest as a managed-platform property. On top of that, connected tenant credentials are given the additional AES-256-GCM envelope described in commitment 3, with a key held outside the database.
Location. The platform and its data are hosted in the United States.
3. Subprocessors
Excellent uses the service providers below (“subprocessors”) to operate the platform. Each processes data only to provide its service to us, under agreements that limit its use. We verify this list against the platform’s actual configuration — a provider appears here only if it is wired into the running system.
| Provider | What we use it for | Data it can process | Region |
|---|---|---|---|
| Supabase | Database, authentication, and file storage | All platform data: account and staff details, guest contact information, business records, and uploaded files | United States |
| Vercel | Application hosting and content delivery | Request and response traffic in transit (may include any of the above); stores no application data at rest | United States |
| Stripe | Payment processing (Checkout) and connected-account payouts (Connect) | Card details and payout identity/bank information are entered into and held by Stripe — we store no card numbers or bank details, only a billing contact and connected-account identifiers | United States |
| Sentry | Error monitoring and alerting | Redacted error reports: the error message, stack frames, and the route where it occurred — recipient addresses are masked and bearer tokens and share links are stripped before a record leaves our servers (ADR-0215). No guest, staff, or business records are sent | United States |
| Resend | Transactional email delivery | Recipient email addresses and message contents | United States |
| Postmark | Transactional email delivery and inbound email parsing | Recipient email addresses, message contents, and inbound messages sent to the platform | United States |
| Mapbox | Address and business lookup during onboarding | Address/business search text and requester IP (business-location data, not guest records) | United States |
| Meta / Instagram | Publishing the social posts you approve — operated on our behalf by Ethical Digital LLC, an affiliate under common ownership | The connected Instagram account identifier and the content you publish | United States / global |
| Google Analytics (GA4) | Traffic analytics on our public marketing pages only — not loaded in the signed-in application, and not on the no-login links we send your guests; disabled entirely on staging and development | Visitor IP, device/browser, and page-view events from those marketing pages. No signed-in page paths and no guest link addresses ever reach it, and we send Google no names, email addresses, or business records — we run no advertising cookies | United States / global |
| Anthropic (Claude) | AI features (drafting and assistance) | Prompt content, which may include tenant business data | United States |
| OpenAI | AI features and semantic search | Prompt content and search-index embeddings, which may include tenant business data | United States |
| Moonshot (Kimi) | AI features — a fallback model in our model routing, active only when configured | Prompt content, which may include tenant business data | People's Republic of China |
Excellent routes AI requests across multiple model providers; which one handles a given request depends on our configuration. Anthropic and OpenAI are United States providers; Moonshot is based in the People’s Republic of China. We access these providers through their APIs, whose terms do not use API-submitted data to train their models, and we do not use their consumer products for tenant data. Organizations with data-residency requirements should contact us.
Two integrations are configured but not currently active, so they are not listed above: an SMS carrier (Twilio) — we verify inbound message signatures but send no text messages — and Google Business Profile, whose connector exists but is not enabled. Excellent uses no third-party error-tracking or advertising service.
4. Reporting a vulnerability
If you believe you have found a security vulnerability, please email support@beexcellent.ai with “Security” in the subject. Include enough detail to reproduce the issue. We aim to acknowledge reports within three business days and will keep you updated as we investigate.
We support good-faith security research: if you make a genuine effort to avoid privacy violations, data destruction, and service disruption, we will not pursue or support legal action against you. Please do not access, modify, or delete data that is not yours, do not run high-volume automated scans against production, and give us reasonable time to remediate before any public disclosure. Our machine-readable contact is published at /.well-known/security.txt.
5. What’s next
We publish a commitment only once the mechanism behind it ships. These protections are on the roadmap but not yet in place, so they are not claimed above:
- Multi-factor authentication and passkeys for sign-in (not available yet — password and Google sign-in are supported today).
- Single sign-on (SSO / SAML) for enterprise customers.
- A full script and style Content-Security-Policy with per-request nonces (today's policy covers clickjacking only).
- A self-serve permanent-deletion flow (today your records are archived under your control and permanent erasure is by request — the one-click data export this was once paired with already ships, above).
- An independent third-party penetration test, before we onboard the first paying customer (our written incident-response plan is adopted).
6. Changelog
We review this page as our controls change and keep the review date above current.
- August 7, 2026 — Google Analytics is now scoped to our public marketing pages. It previously loaded on every page our production hosts serve, the signed-in application included. Added the commitment above and corrected the subprocessor entry to describe what now runs.
- August 7, 2026 — Corrected three entries that understated what we operate: one-click organization data export ships today and is now stated as a commitment rather than listed as future work; dependency-advisory enforcement and scheduled update pull requests now run in our build gate and are folded into the testing commitment above; and our incident-response plan is adopted. Permanent deletion and the third-party penetration test remain on the roadmap.
- August 5, 2026 — Initial publication.