Security and trust

Specific about what protects your data,
and what we do not have yet.

Amfion holds businesses’ customer data and takes real bookings on their behalf, so this page is specific. Everything below describes protections that exist in the running product today, followed by an honest list of what we do not have.

At a glanceCurrent state

Tenant isolationCI-checked filters + a two-tenant probe suite: Enforced
Secretskeys, tokens, signing secrets: Supabase Vault
Card dataStripe-hosted checkout: Never stored
Outbound URLsprivate ranges, DNS rebinding: Screened
SOC 2 · ISO 27001: Not yet
HIPAA BAA: Not offered

Tenant isolation

How isolation works today — stated precisely

Tenant separation currently relies on explicit per-tenant filters in application queries, enforced by two CI gates: a static check that verifies every query against a tenant-scoped table carries a tenant filter (with the table inventory derived from the database schema itself, so it cannot silently drift), and a two-tenant integration suite that provisions two real businesses and attempts cross-tenant access across each authenticated product surface — admin sessions, customer tokens, the agent gateway, and partner API keys. These gates prove the surfaces and scenarios they test; they are not a mathematical guarantee about every possible query.

What we are candid about

Row-level-security policies exist on all tenant tables, but tenant operations currently run through a privileged database connection that bypasses them — so RLS is not yet a runtime backstop. Work is staged (and published in our engineering docs) to move tenant runtime queries behind an RLS-enforced database role, at which point the database itself will refuse cross-tenant access even if application code is wrong. Until then, the honest description is: disciplined application-level isolation, mechanically checked in CI, verified by integration probes — with a database-level backstop in progress.

Data protection

Encryption in transit everywhere

All traffic is HTTPS with HSTS. Outbound calls to businesses’ own endpoints require HTTPS in production.

How integration secrets are stored

Calendar API keys, OAuth refresh tokens, and the signing secrets for outbound webhooks and custom tools are stored in Supabase Vault and referenced from application tables by id only. A secret is shown once at creation and never returned again; rotation keeps the previous secret as a co-signer for a grace window.

Logs are scrubbed, IPs are hashed

Application logs run through a redaction list covering auth headers, tokens, emails, phone numbers, and provider signatures. Agent-gateway analytics store only a truncated one-way hash of the caller IP — the raw address is never persisted.

Card data never touches Amfion

Payments and deposits run on Stripe (Connect). Checkout happens on Stripe-hosted surfaces; Amfion stores payment status, never card numbers.

Outbound requests & webhooks

Signed webhooks

Every webhook Amfion sends is HMAC-signed with a per-endpoint secret, with timestamped signatures and a documented verification recipe. Secret rotation keeps a 24-hour co-signing grace window.

SSRF screening with connect-time address pinning

Any URL a customer or partner supplies (website imports, custom-tool callbacks, webhook endpoints) is screened against private, loopback, link-local, and cloud-metadata address space — and the screening re-runs against the address DNS actually resolves to at connection time, closing DNS-rebinding attacks. Every redirect hop is re-validated.

AI agents & booking integrity

Two-phase booking for third-party agents

External AI agents can never mutate a booking in one shot. They prepare a booking (which validates and holds the slot, minting a single-use capability token whose expiry is inside the signed material), and confirm it in a second step that executes only the server-stored arguments. A capability can produce at most one local Amfion booking row, enforced by a database uniqueness constraint. For bookings backed by an external calendar provider, the remote create carries the capability id for reconciliation and duplicate remote results are compensated best-effort — a strong guarantee, stated precisely.

Least-credential links

Booking-management links handed to anonymous agents are scoped to that single booking — never to the customer’s whole appointment history. Customer portal tokens are HMAC-signed and expire.

The model cannot upgrade trust

Answer trust is computed server-side from stored verification states of the facts actually cited. Nothing the model writes — however confident — changes what the platform reports as verified.

Operational discipline

Schema changes are a ledger

Database migrations apply through a runner with per-file checksums and an append-only ledger; applied migrations are immutable. The API refuses to report ready when its build expects a newer schema than the database has — deploying ahead of migrations fails at rollout, not at midnight.

Hardened containers

Production containers run read-only with dropped Linux capabilities, constrained temp filesystems, resource limits, and health checks. Images are rebuilt and republished through CI gates only.

The site is verified as rendered

CI crawls the built marketing site and fails on broken canonicals, accidental noindex, invalid structured data, or structured data that advertises content not actually on the page.

Candor

What we do not have (yet).

Reporting

Reporting a vulnerability.

If you believe you have found a security issue, we want to hear about it and will respond promptly. Report it to [email protected]. Please include reproduction steps and do not access data that is not yours.