Data processing

When your app’s users talk to a copilot, you are the controller of that personal data and Neon Apps is your processor. This page states how we act in that role. A signed data processing agreement on these terms is available: write to support@neonapps.co and we will return it countersigned, or sign yours.

Subject matter and duration

We process personal data only to provide the copilot service, for as long as your account exists, and delete it on the retention schedule your app sets.

What we process

• Message text your users send, and the answers rendered back to them.
• Application state your app chooses to send with a message.
• A device identifier, and your own user identifier if you send one.
• Action parameters and results, stored in the same masked form the model saw.
• A rating, where one of your users marks an answer helpful or not, together with any reason they type. A typed reason is masked before storage exactly as a message is.

Our obligations

• We process personal data only on your documented instructions, which for most customers means the configuration you set in the console and the actions you register.
• Everyone with access is under a duty of confidentiality, and access to your conversation data is an explicit allowlist of named people rather than a property of anyone’s email address. Every time one of them opens one of your conversations, an entry is written to your own audit log, which you can read in the console. You do not have to ask us who has looked at what.
• Security measures: tenant isolation enforced twice over — by the query and again by row level security policies the database applies to the API’s own restricted role, with FORCE ROW LEVEL SECURITY so that even the table owner is subject to them. Both layers are exercised on every change by a test suite that runs the real schema and connects as that restricted role, so a table added with the wrong grants fails before it ships. Keys are stored only as hashes. Email addresses and phone numbers are masked before any model call and the values encrypted at rest with AES-256-GCM; card-like numbers are dropped outright and never stored. Transport is encrypted throughout.
• We will not engage a new subprocessor that handles conversation content without updating the list on the privacy page first, and you may object.
• You can answer a data subject’s request yourself, without waiting on us: the console erases one end user — their conversations, every message in them and the encrypted values behind any placeholders — and exports your whole app as a single file. Where a request needs more than that we will help, and we will tell you without undue delay if we become aware of a breach affecting your data.
• On the end of the agreement we delete your data, or return it, at your choice. The return is the console’s own export, so you do not have to take our word for when it happens.

Subprocessors

Anthropic (model inference), Supabase on AWS in Frankfurt (database and authentication), Vercel (hosting), Resend (email delivery, including the cap warnings we send you), and an embeddings provider for apps that enable the knowledge base. An error reporting service is listed there too, disclosed before it is switched on rather than after. The current list, with what each one touches and which of them can see conversation content, is on the privacy page.

Location and transfers

Conversation data is stored in Frankfurt. Model inference and hosting involve transfers outside the EEA, made under the European Commission’s standard contractual clauses with the providers concerned.

Audit

We will answer a security questionnaire and provide the documentation we have. We do not hold a SOC 2 report today, and we will say so plainly rather than imply otherwise.