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.
The companies that process data for Amfion, what each receives and where, are listed on the Subprocessors page.
- Separation between businessesa restricted database role per request, since Sep 24, 2026
- Database-enforced
- AI modelsUS-company models or DeepSeek, per business
- Your choice
- Two-step sign-inauthenticator app; always on for law firms
- Available
- Staff access to a law firma stated reason, logged before anything is shown
- Logged
- Data hostingdatabase, servers and backups
- Germany
- Backupsencrypted, kept up to 12 weeks
- Hourly
- Card dataStripe-hosted checkout
- Never stored
- Subprocessorswhat each receives and where
- Listed
- SOC 2 · ISO 27001
- Not yet
- HIPAA BAA
- Not offered
01
Separation between businesses
Enforced by the database, for every business
Since September 24, 2026, the requests Amfion makes to its database on behalf of a business run as a restricted database role that cannot bypass row-level security. Each request carries a server-signed credential that names one business and expires within 15 minutes, and a policy on every business table admits only that business’s rows. A query that forgot its business filter still returns nothing from another business, and a write addressed to another business is refused. This is enforced in production for every part of the product and every business.
Proved on every change
Every change runs a two-business test suite against a real database, trying to reach one business from the other with every kind of credential: admin sign-in, customer links, the AI-agent gateway, partner API keys and the law firm screens. It runs three times: as written, under the restricted role, and with every business filter stripped out of the application’s database requests and every write first addressed to the other business. That last run fails if a single row from the other business comes back, if a write to it is accepted, or if the filters were not actually stripped. A static check also confirms every query against a business table carries a business filter or a recorded reason, and a schema check fails the build if a new table lacks the row policies.
Where the database does not decide
A short, reviewed list of platform functions keeps a privileged connection by design, each with a written reason: billing and usage metering, account setup, working out which business a request belongs to, cross-business discovery, and credential storage. Files people share in a conversation, greeting audio and logos sit under each business’s own path and are separated by application code, not by database policies. No independent penetration test has been done yet.
02
AI models
You choose which AI models see your conversations
Each business chooses which AI models may read and answer its chats, texts, emails and phone lookups, and read its website: US providers only (Anthropic and OpenAI), DeepSeek served through OpenRouter only by US-based zero-data-retention providers, or the platform default, where Amfion picks the model for each task. On US models nothing is sent to OpenRouter or DeepSeek: not chat, not phone lookups, not website reading, not our own test runs; a rehearsal run that would break that is refused before it runs. “US” describes the companies, not a guaranteed processing location. Law-firm accounts default to DeepSeek through OpenRouter on the listed US-based zero-retention hosts, with an explicit acknowledgement before go-live and the option to select US models. They cannot choose the platform default. When a preview is built from a business’s public website before it signs up, that website is read on the platform default; the preview’s conversations follow its model setting, with the law-firm policy applied when it has the legal profile. OpenAI handles live calls and Anthropic checks law-firm replies under either law-firm setting. The Subprocessors page shows which providers each setting uses.
Open-weight models run on zero-retention hosts
Every request Amfion sends through OpenRouter requires a zero-data-retention endpoint, refuses providers that train on or keep its contents, and never goes to DeepSeek’s own servers. This is enforced on each request, not by an account setting. The DeepSeek-on-US-hosts setting adds an exclusive list of US-based hosts. OpenRouter cannot pin a processing region on our plan, so no OpenRouter request, even on that setting, is guaranteed to be processed inside the United States. Whatever the setting, the speech on a phone call is processed by OpenAI; Amfion keeps a text transcript, never the audio.
03
Signing in
Two-step sign-in with an authenticator app
Owners, admins and staff can add an authenticator app to their Amfion sign-in. From then on, a password or a Google sign-in alone never opens their account: until the 6-digit code is entered, Amfion’s servers refuse every request from that session, not just the screens. An owner can require two-step sign-in for everyone in the workspace, and turning that on first requires the owner’s own code, so it cannot lock them out.
Always on for law firms
A law firm account always requires two-step sign-in, for the firm’s own people and for Amfion staff working in the firm’s workspace; it cannot be turned off. If Amfion cannot confirm a workspace’s sign-in rule, it refuses the request instead of guessing.
Losing an authenticator
There are no backup codes, so Amfion asks everyone to add a second authenticator. Someone who loses their only one contacts Amfion: a staff member who is signed in with two-step sign-in removes it after confirming who is asking, and the reset and its reason are written to that workspace’s access log.
04
Access by Amfion staff
Logged, with a reason, for law firms
On a law firm account, every request an Amfion staff member makes in the firm’s workspace through Amfion’s own tools needs a stated reason and is written to a log (who, when, which screen and record, and why) before anything is returned. If the log cannot be written, the request is refused. The firm reads that log in its own settings.
What the log does not cover
Access directly to the servers, the database or a provider’s dashboard does not pass through Amfion’s tools and is not in this log; those routes leave only the providers’ own records. Workspaces of businesses that are not law firms are not logged this way.
05
Data protection
Encryption in transit
All traffic to Amfion is HTTPS with HSTS, and so are Amfion’s requests to its providers; traffic between our own servers stays on a private network. Outbound calls to businesses’ own endpoints require HTTPS in production.
Encryption at rest
The database and file storage are encrypted at rest by Supabase. Credentials a business connects are kept in Supabase Vault (below), and database backups are encrypted before they leave our servers.
Where your data is hosted
The database and file storage (Supabase) and the servers that run Amfion (Hetzner) and the encrypted database backups are all in Germany. Our AI, telephony, email and payment providers are US companies, and some of them may process data outside the United States; the Subprocessors page lists what each one receives and where it processes it.
Hourly backups, restore tested
The database is backed up every hour, encrypted before upload to separate storage in Germany, and kept for up to 12 weeks. A full restore into a fresh database project was run on September 5, 2026. Two application servers run behind a load balancer, with a replicated cache that fails over automatically.
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 calendar credential in use may be held for up to an hour in our private server cache. 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; stored IPs are hashed
Application logs run through a redaction list covering auth headers, tokens, emails, phone numbers, and provider signatures. Where Amfion stores a visitor’s IP address in its database (chat sessions, agent-gateway analytics, preview builds), it keeps only a keyed one-way hash. Server access logs record full IP addresses and are overwritten on a rolling basis.
Delivery copies are emptied
The copies of webhook and notification payloads kept so they can be delivered are emptied 30 days after they are created, or 90 days for failed deliveries; the delivery record itself (status, times, event type) stays. Messages still waiting to be delivered are never touched.
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.
06
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.
07
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.
08
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 security@amfionhq.com. Please include reproduction steps and do not access data that is not yours.