Security and privacy

Where it runs

Engadin runs entirely on Cloudflare: the code that answers a visitor, the database holding your conversations and leads, the search index behind the answers, and the files a visitor attaches. There is no separate server rented somewhere, and no third-party analytics anywhere in the widget.

Answers themselves are generated by a large language model. Which one depends on how your agent is configured; the options are listed under sub-processors.

Where your data is processed

Your conversations, leads, messages and the files visitors attach are stored in the European Union. The database and the file store are both created under Cloudflare’s eu jurisdiction, which is a contractual restriction on where the data may be kept, not a preference or a routing hint. It is fixed when the store is created and cannot be loosened afterwards.
The search index holds no readable content from your conversations. It stores the numeric embedding of a message and nothing else beyond which agent the message belongs to. The readable text lives only in the EU database. This matters because the vector index is the one Cloudflare store with no jurisdiction setting available, so instead of promising a location for it, we keep personal data out of it.
The code runs on Cloudflare’s global network, close to whichever visitor is talking, which is what makes an answer arrive in a second instead of five. Processing a request is transient; storage is what is pinned. Embedding and ranking a message use Cloudflare’s own models, which likewise run wherever the request lands and carry no residency guarantee.
Answers are generated in the United States, by Anthropic or OpenAI depending on how your agent is set up. This is a transfer out of the EU, and it rests on the standard contractual clauses in those vendors’ data processing agreements together with their certification under the EU-US Data Privacy Framework. No setting moves it: it is the model vendor’s own infrastructure. An agent can instead be pointed at Cloudflare’s own models, which keeps generation on the same network as everything else.
Email goes out through a European region, for sign-in links, notifications and the email channel.

Cloudflare’s services are built to satisfy the GDPR and are verified under the EU Cloud Code of Conduct; its data processing agreement and its current sub-processor list are public on its GDPR trust hub.

What is stored about a visitor

Stored	Not stored
The messages they sent and received	Their IP address
Country and city, from the request	Any account or identity
Language and device class	Cookies for tracking
The page they were on	Behaviour elsewhere on your site
Files they attached, for that conversation

Visitor IP addresses are never written down. Where one is needed — for per-IP rate limits, and for counting unique visitors in the funnel — it is salted and hashed first, and only the hash is stored.

A conversation id is kept in the visitor’s browser (localStorage, not a cookie) so a returning visitor continues where they left off. Clearing site data starts a new conversation.

What the assistant can see

An agent answers only from its own index: its crawled pages and its snippets. It cannot reach another agent’s content, another workspace’s anything, or the open web at answer time.

Attachments a visitor uploads are read to answer that visitor’s question. They never enter the index and never influence anyone else’s answers.

Who can reach the data

Every admin API, the MCP server and the built-in assistant are scoped to the caller’s workspace. Roles inside a workspace decide the rest — see team and roles.

Sign-in is by magic link, signed with a server-side secret. There are no passwords. Removing a member takes effect immediately.

Origin enforcement

Off by default, and you can turn it on yourself for one agent: Chat widget → Embed → “Answer only on your own website”. It saves the moment you switch it, with no deploy. There is a second switch at platform level that turns enforcement on for every agent at once; when your operator has set that one, yours is already covered and cannot be opted out of.

With it on, a request is only answered if its Origin matches the agent’s own website (including www and any subdomain of it), any hostname the workspace owns, or the platform itself. It exists to stop a third party embedding your assistant on their site and spending your budget.

The check covers the whole widget, not only its messages: a voice call is refused at the moment its session is minted, before any connection to the speech provider is made, and speech synthesis is refused the same way. Voice is worth naming here, because a live call is billed by the minute rather than by the message, so it is the costly thing to leave open. A visitor on a blocked website reads “this assistant is not available on this website” in the widget, rather than watching it fail without explanation.

Requests with no Origin header at all are allowed through: non-browser clients legitimately have none, and they are governed by rate limits and bot checks instead. Embedding the widget in an iframe, and the hosted chat page we serve for you, both count as the platform and keep working.

Bot protection

Cloudflare Turnstile can be required before a new conversation starts. It is enabled platform-wide, and only takes effect once both the site key and the secret are configured — a half-configured Turnstile never silently blocks chat.

The widget sets no cookies and loads no third-party analytics. It keeps one value in localStorage: the id of the current conversation, so a visitor who reloads the page does not lose the thread.

The dashboard has no cookies either. Signing in leaves a signed session token in your browser’s local storage, and nothing else.

Storing anything on a visitor’s device falls under the ePrivacy rules whether or not it is a cookie, with an exception for what is strictly necessary to provide the service the visitor asked for. A conversation id that exists only to continue that conversation reads as exactly that, which is why the widget ships without a consent banner of its own. Your counsel decides for your site. Note that the analytics events described in embedding the widget are yours once they reach your page: if your tag manager forwards them somewhere that profiles visitors, that is your tag manager’s consent question, not the widget’s.

If you turn on business goals

Goal tracking is the one feature that watches the pages around the widget rather than the widget itself, so it is off for every agent until you turn it on, and it changes nothing above until you do.

With it on, still no cookie is set and no new identifier is created: it reuses the conversation id already described here and the same salted, hashed IP the visitor counts use. What it reports is the structure of what a visitor completed — which form, what its fields are called, which analytics event fired — and never the contents of any field, never a hidden or password field even by name, and never an email address, phone number or name from a form or from the page. That list is enforced in the widget and again on our side, where anything not on it is discarded before it can be stored. An order number is hashed in your page and only ever used to recognise a repeat of the same order.

It also obeys a consent tool if your site has one: Google consent mode (analytics_storage) and the IAB TCF API are both read, and nothing is reported while either says no.

Retention

Nothing about a conversation expires on its own. Conversations, messages and leads stay until someone deletes them, or deletes the agent, or the workspace. What does run automatically is housekeeping:

Data	Kept
Conversations and messages	Until deleted
Conversations where nobody ever spoke	1 day
Error diagnostics	90 days
Your own threads with the dashboard assistant	180 days
Sign-in links	15 minutes, single use, and stored only as a hash
Dashboard sessions	30 days
Visitor and abuse counters	Kept, but they hold nothing beyond a date, an agent, a metric and a hash
Raw goal signals, if goal tracking is on	30 days — which is also exactly how far back accepting a goal can count retroactively
Counted conversions and the goals themselves	Until deleted — they are the report

If your policy sets a fixed window, twelve months say, ask the operator to apply it to your workspace.

Deletion

A single conversation can be deleted from the dashboard. That removes its messages and everything derived from them, and it disappears from every statistic. A lead captured out of that conversation stays on purpose: leads are worked in your CRM, and deleting a transcript should not silently drop the entry your sales team is following up.

Deleting an agent removes everything it ever held: crawled pages, snippets, conversations, messages, leads, tickets, uploaded files and the search index built from them. Nothing outlives the agent. Deleting a workspace does the same for every agent in it.

To remove one lead on its own, ask the operator; the dashboard deletes leads together with their agent.

Deletions are recorded in the audit log.

Who is responsible for what

In the vocabulary the GDPR uses, and the Swiss law uses almost identically:

You are the controller for the visitors who talk to your agent. You put the assistant on your site and you decide what happens with the conversations and leads it produces.
The operator of this installation is a processor, acting on your instructions.
Cloudflare, the model provider and Mailgun are sub-processors. They are listed below.

That split is why the paperwork lands on you: the privacy notice on your site, the lawful basis, the answer to a visitor who asks what you hold. What the platform owes you is the ability to answer, which the export and delete functions provide.

Switzerland’s revised Federal Act on Data Protection (revFADP; nFADP in English usage, revDSG in German) has applied since 1 September 2023, and was written to keep Switzerland’s EU adequacy decision. For a chat assistant, the two regimes want the same things:

Both ask for	Where it lands here
Transparency about what you collect	Your privacy notice, plus an assistant that presents itself as one
Data minimisation	No IP addresses stored, no tracking cookies, no identity beyond what a visitor types
Purpose limitation	An agent answers only from its own index and never reaches another workspace’s data
A record of processing activities	The sub-processor table below, plus the audit log
Access, rectification, erasure	CSV export and delete, see below
Breach notification	GDPR: the lead authority within 72 hours. Switzerland: the FDPIC, as soon as possible
Care with transfers abroad	Adequacy and standard contractual clauses, see below

The differences are procedural rather than technical. Switzerland has no 72-hour clock, and no administrative fines of the GDPR kind: it fines responsible individuals instead, up to CHF 250,000. Its impact assessment is a DSFA rather than a DPIA. A controller domiciled outside Switzerland that processes Swiss residents’ data extensively and regularly may need a representative in Switzerland. None of that changes the software; all of it changes your file.

Other regimes worth knowing

UK GDPR. The same shape as the EU’s, with the ICO as the authority.
The EU AI Act (Regulation (EU) 2024/1689). Its Article 50 transparency duties apply from 2 August 2026. The one that touches a chat assistant is blunt: a person must be able to tell that they are dealing with an AI. The widget presents itself as an assistant and no reply carries a human byline, but your greeting and your agent’s persona are yours to write, so keep them honest. This duty falls on you as deployer; your model vendor’s compliance documents do not discharge it.
California (CCPA/CPRA). Nothing here sells or shares visitor data, which is the part that usually needs disclosing. California’s bot-disclosure law points the same way as Article 50.
Brazil (LGPD), Canada (PIPEDA), Japan (APPI), Australia. Same principles, local paperwork. Nothing in the product assumes a European visitor.

Sub-processors

Who	For what	Where	Their paperwork
Cloudflare	Hosting, storage, the search index, bot protection, and its own models when an agent uses them	European Union for the database and attachments (`eu` jurisdiction); its global network for request processing, the vector index and its models	GDPR trust hub, verified under the EU Cloud Code of Conduct (ID 2023LVL02SCOPE4316)
Anthropic	Generating answers, for agents set to Claude	United States, under SCCs and the EU-US Data Privacy Framework	Trust center
OpenAI	Generating answers, for agents set to GPT. Voice, for every agent that uses it	United States, under SCCs and the EU-US Data Privacy Framework	Data controls
Mailgun (Sinch)	Sign-in links, notifications, the email channel	European Union	Available on request

Which provider answers is a setting on each agent, so an agent that must avoid one of them can be pointed at another. Your operator holds that switch, and what your agent currently resolves to is shown read-only under Agent settings → AI → Where answers are generated, which is the line to copy into a privacy notice. Voice is the exception: it runs on OpenAI, and a workspace that cannot use a United States provider cannot use voice.

Whether your conversations train someone’s model

No, and each vendor says so in writing.

Cloudflare. Its data usage policy states that Cloudflare “does not use your Customer Content to train any AI models”, and that inputs and outputs are not kept unless you store them yourself.
Anthropic. Its commercial terms rule out training on customer inputs and outputs, and those are deleted within 30 days, with longer retention only where an abuse investigation or the law requires it.
OpenAI. API data is not used for training unless you opt in. Logs kept for abuse monitoring expire after 30 days.

Both model vendors also offer zero-retention arrangements, where nothing is written down on their side at all. Ask the operator whether your installation runs under one.

Answering a data subject request

Finding the person. There is no account and no stored IP address, so a visitor is identifiable only through what they typed. Start with the lead list, which holds the addresses and phone numbers visitors gave. To search the transcripts themselves, ask the built-in assistant to find messages containing the address; that works even when the conversation produced no lead.

If nothing matches, then you hold no data you can tie to that person, and saying so is a legitimate answer rather than an evasion.

Access and portability. Conversations and leads export as CSV, scoped to an agent or to the whole workspace. For one person, the transcript view is the readable form.

Erasure. Delete the conversation; see deletion above for what that covers and what it deliberately leaves behind.

Rectification. Nothing here is a system of record. Correct the data where you work it, in your CRM.

Automated decisions. The assistant answers questions and scores how well a conversation fits your audience. It decides nothing about a person with legal or similarly significant effect, so Article 22 has nothing to catch.

What to put in your privacy notice

A short paragraph covers it. The facts you need:

The assistant is an AI assistant, and its answers are generated.
What is stored: the conversation, the page it started on, country and city, device class, and anything the visitor volunteers.
What is not: no IP address, no tracking cookies, no profile.
Who processes it: you, the operator of your installation, and the sub-processors above, with answers generated in the United States for most model choices.
How to reach you to ask for access or deletion.

Documents you may need

A data processing agreement between you and the operator of your installation. You are the controller, the operator is your processor, and Article 28 wants that on paper.

On engadin.ai that agreement is in preparation and not yet published, so this page will not pretend otherwise. Ask through the contact form at sweetcode.com/support and you will get a straight answer about where it stands rather than a document that does not exist; the entity that signs it is named on who runs Engadin AI. If your compliance process needs the paper before you can go live, say so in that message. It is the clearest way to move it up the queue.

Two things you no longer have to ask anyone for. The sub-processor list is on this page, kept current, and can be cited by URL. Which provider answers for your agent, and therefore whether answers are generated in the United States or on Cloudflare’s EU models, is shown under Agent settings → AI; that is the line of your privacy notice you would otherwise have had to write blind.
Cloudflare’s DPA and current sub-processor list, from its GDPR trust hub.
The model vendor’s DPA, if your compliance file wants the chain documented all the way down.

Reporting something

If you find a security issue, report it to the operator of your installation rather than filing it publicly. On engadin.ai that is sweetcode.com/support; include what you did and what you saw, and no proof-of-concept against another tenant’s data.