Security and privacy
Last updated: July 2026
The agent holds two things you do not hand to just anyone: the key to your booking system, and conversations with your guests. Here is exactly how we look after both, and what we do not claim.
Where your data lives
Database and backend in the EU
The database runs on Supabase in Paris. The backend runs on our own server in Germany. Neither sits outside the EU.
The exception, said out loud
The language models that drive the conversation run at Anthropic and OpenAI in the US. That means the text of a guest conversation is sent there to be answered. The transfer runs on the European Commission's standard contractual clauses. We would rather write it here than let you discover it yourself.
The key to your booking system
Encrypted, and bound to your venue specifically
The API token and secret, the parts that grant access, are encrypted with AES-256-GCM before they touch the database. The encryption is bound to your tenant id, so a copied row cannot be unlocked against another venue. Your booking system's host name itself is stored in clear, because it is not a secret. Keys carry a version number so they can be rotated. We have not rotated one yet.
They do not exist in the browser
The website does not talk to the database, and no key or database login is ever shipped to the browser. Everything goes through the backend. The rule is architectural, and a tooling check catches it if someone accidentally imports the database into frontend code. That is a development guard, not a runtime one.
We never handle card data
Payment happens on your own booking system's payment page. The agent never asks for card details and cannot accept them. We process and store no card data, and we are not a payment processor. If a guest types something into the chat that does not belong there, it is handled like any other conversation text, which is why we never ask for it.
Your guests' data
We store a reference, not the contact
The decision log, which is what makes it possible to audit what the agent did and why, stores a hashed reference to the guest's email or phone number (HMAC-SHA256 under a secret pepper). Not the contact itself. It also means an erasure request does not break the audit trail.
The agent says what it is
Guests get a privacy notice in the chat and are told they are talking to an agent, not a person. There is always a visible route to you.
You are the controller, we are the processor
They are your guests and your data. We process it on your instruction, and you can have it exported or deleted.
Access and operations
Login without a password
You sign in with a magic link to your own inbox. There is no password to leak. Internal routes sit behind a separate check.
Weekly vulnerability scanning, and the findings get written down
An independent agent scans the code every week. Every finding gets an issue and a priority on our board, including the ones we choose to defer, and the deferred ones sit in our security note with the reasoning. We do not close them quietly. The board is not public, but ask for the list and you will get it.
What we do not claim
We are not ISO 27001 certified, and we are not SOC 2 audited. We have not had an external audit, so we do not put a badge on the site implying one.
We are a small company at an early stage. What is written above is built and can be checked. What is not written is not there. If your procurement process has a requirement we do not meet, say so and get an honest answer immediately rather than in three weeks.
Subprocessors
The full list of providers that may process data on our behalf, and where they sit. Your own booking system is listed last: it is not a provider we chose, but guest data flows into it, so it belongs in the picture.
| Provider | What it is used for | Location |
|---|---|---|
| Supabase | Database | EU (eu-west-3, Paris) |
| Hetzner | Backend server | EU (Germany) |
| Netlify | Website hosting | Global CDN, US company |
| Resend | Email to you (reports, alerts) | US |
| Anthropic | Language model for the conversation | US |
| OpenAI | Language model for the conversation | US |
| Firecrawl | Reads your public website at setup and in the weekly learning run | US |
| Checkfront | Your own booking system. Receives the guest’s name and contact so the booking can be created | Per your own account |
Firecrawl only ever reads your own public website, never guest data: at setup, and again when the weekly learning run is missing an answer. Checkfront is on the list because the agent sends the guest’s name and contact into it to create the booking, but that is your own system and your own agreement with them, not a provider we picked for you. If this list changes, we update it here and tell you.
Data processing agreement
You are the controller, we are the processor, and those roles are settled. The agreement text itself is going through legal review before the first paying venue, so we do not have a finished, signature-ready version today. Write to us and you get the draft as it currently stands, plus a date. We would rather say that than send you something no lawyer has read.
Ask about the DPAQuestions
If you or whoever handles your IT has a question this page does not answer, write to hello@waymarker.eu. You will get an answer from a person.