Data processing addendum

Draft of 14 August 2026 · forms part of the terms of use

This describes how we handle personal data on a customer’s behalf. It is written in plain language on purpose; where a term of art matters — controller, processor, sub-processor — it is used and then explained. It forms part of the terms of use, and where the two conflict on data protection, this one wins.

1. Who is the controller, and where that splits

There are three different answers, and conflating them would be the central dishonesty of this document.

• The list you build and the messages you send: you are the controller, we are the processor. You choose who is researched, who is contacted and what is said. We act on that.
• Your account: we are the controller. Your email address, your password hash, your session. Covered by the privacy notice rather than by this addendum.
• The shared corpus: we are the controller, not your processor. What the engine works out about the world — a company’s address convention, a confirmed address, the people found at a domain, a creator’s public counters — is kept in one store that crosses accounts, because a convention learned once is true for everybody. It is not held on your instruction. You therefore cannot instruct us to delete from it, and nothing in this addendum should be read as promising that we would. A person in the corpus deals with us directly, at privacy@skygen.ai, and gets the row deleted.

If your own compliance position requires that everything about a data subject be under your control, this product is not a fit, and that is better discovered here than in an audit.

2. What we process for you

Subject matter and duration. Researching businesses and the people who work at them, and sending email to them, for as long as you have an account.

Nature and purpose. Collecting business contact data from public sources, checking whether an address exists, storing it, drafting messages, sending them, and recording what came back.

Types of personal data. Name; employer and its domain; a business email address; a job title or role where it was published; the URL or source each of those came from; how the address was established (published, confirmed by a mail server, or inferred); a business phone number where a directory published one; the content of messages sent and replies received, including a preview of up to five hundred characters; and whether the person has asked not to be contacted.

Categories of data subject. Employees, directors, owners and published contacts of businesses matching what you searched for; and creators with public accounts, where that lane is used.

Special categories. None. Nothing in the system looks for health, beliefs, politics, union membership or sexuality, and none of it is stored or inferred.

3. Your instructions, and what counts as one

Your instruction is what you ask the engine to do, plus the settings you configure — the audience, the offer, the tone, the domains you exclude, the autonomy level. We process for no other purpose, with two exceptions stated openly: operating and securing the service, and the corpus in section 1.

Sending always requires a human. Sending email, buying a domain, provisioning a mailbox, warming a domain, reading a reply mailbox and taking somebody off the do-not-contact list are all refused at execution unless a person approves them. That set is derived from the tool registry rather than written out in one place, so a capability added later is inside the gate on the day it is added. No agent in the system can decide by itself to contact somebody, and no agent can raise its own permission level.

We do not train models on your data. We do not train models at all. Text is sent to a model provider for extraction and drafting — see the sub-processor table — and what that provider does with a prompt is governed by their terms. Not yet: we have no zero-retention agreement with them, so if that matters to you, do not configure a model provider; the pipeline runs without one and reports which steps it skipped.

If we think an instruction breaks data protection law, we will say so and not carry it out.

4. Who can reach the data

The people who operate the service, and only for operating it. Everyone with access is under a confidentiality obligation. There is no support team browsing lists, and no third party is given access for analytics, sales or anything else.

5. Security measures that exist

• In transit: HTTPS throughout, terminated by Cloudflare. The engine’s own outbound calls use HTTPS wherever the source offers it.
• Passwords: PBKDF2-HMAC-SHA256, a fresh random salt per record, the iteration count stored with the hash so it can be raised without locking anyone out, and a constant-time comparison so a wrong password does not leak how nearly right it was.
• Sessions: a 256-bit random identifier, HttpOnly, SameSite=Lax, Secure outside localhost, thirty days. A signed-in session has a record on our side, so signing out revokes it; that record is cached for thirty seconds, which means a revocation can take up to thirty seconds to be effective on another instance. A session that never signed in has no record — it is a tenancy key and nothing more, its thirty days are the cookie’s own expiry, and there is nothing on our side to revoke.
• Tenancy: every read and write is keyed to a principal — the account when signed in, the session when not — and each stored record carries that key inside it as well as in the column that indexes it, so a row cannot be served to the wrong account by an index alone.
• Outbound request safety: a caller-supplied domain cannot make the server open a connection to loopback, a private range, or the cloud metadata address that hands out credentials.
• Mail safety: carriage returns and line feeds are rejected in addresses, so nothing can inject extra SMTP commands; and the verification conversation stops before DATA, so a probe cannot become a delivery.
• Rate limits per session, and per-domain probe budgets, which bound both what an attacker can extract and what we can inflict on somebody else’s server.
• Unsubscribe links are signed with an HMAC when the deployment sets a secret. Where it does not, the link is unsigned: somebody who guesses an address could suppress it, and the worst that a forged link can do is stop mail.
• Damaged data is quarantined rather than overwritten, so a parse failure cannot silently present itself as an empty account.
• An opt-out cannot be undone by a customer. The removal that exists for a mis-read reply works only on entries an account put on its own list. An unsubscribe that came from a link or a reply is held at service scope, which no account’s removal reaches — so a do-not-contact record cannot be shortened by the party with a reason to shorten it.

6. Security measures that do not exist

Stated because a control list with no gaps in it is a control list nobody checked.

• No encryption at rest beyond what Cloudflare provides for D1 and their object storage. We add no application-level encryption and there are no customer-managed keys.
• No certification. No SOC 2, no ISO 27001, no independent penetration test, no bug bounty. There is no report to send you.
• No multi-factor authentication on customer accounts, and no single sign-on.
• No separate backup, and no tested restore. We rely on the durability of Cloudflare’s stores. We have not rehearsed recovering from a bad write.
• No log redaction. Some log lines contain an email address, and retention is whatever the hosting platform defaults to.
• No data residency guarantee. Data sits wherever Cloudflare places it.
• No TLS on the verification probe. It is a plain TCP connection to port 25 and does not negotiate STARTTLS, so the address being asked about crosses the network in clear text. Nothing else about the person travels with it, and nothing is delivered.
• No scheduled jobs. The edge runtime this deploys to has no cron trigger configured, and the two periodic tasks that exist — deleting worlds nobody has touched for thirty days, and reading the sending mailboxes so a reply that says stop is honoured — run on a timer inside a long-running server process that the edge does not keep. Both have a door a scheduler can knock on; nothing knocks yet. This is a retention and a data-subject-rights gap before it is a security one, and it is the first thing on the list at the bottom of this page.

7. Sub-processors

Cloudflare is always involved: it is where the service runs. Everything else is optional and inert unless the deployment configures it, which means a customer who wants a shorter list can have one at the cost of the capability behind it.

Two machines are the deployment’s own rather than a vendor’s: the box that runs address verification, and the box that runs the session lane. Whoever hosts them is a sub-processor for what passes through them — the addresses being probed, or a social handle being read.

Changes. This table is the list. We will update it here and tell customers before a new sub-processor starts receiving data. If you object to one, say so: except for Cloudflare, every entry can be switched off, and the affected capability then reports that it is unavailable rather than quietly degrading.

The account’s document shelf. A customer can save free text on their account — a brief, a list, notes — and the engine can write to it. We do not read it except to answer that account’s own request, and a document’s text is sent to the model provider when a request needs it. It is deleted with the account. If a customer puts a third party’s personal data in a document, that is processing on their instruction like anything else here, and it is theirs to have a basis for.

8. Where data goes

Cloudflare runs a global network and several sub-processors above are US companies, so personal data leaves the EEA and the UK. Those transfers rest on each vendor’s own terms and the standard contractual clauses they publish. We have not negotiated separate clauses with any of them, and there is no transfer impact assessment. If your transfer position needs more than that, the honest answer is to leave the optional vendors unconfigured — everything except Cloudflare is optional by design.

9. Helping you answer a data subject

If somebody on your list asks you for access, correction, deletion or a stop, tell us and we will do our part: find the rows, tell you where each came from, delete what you ask us to delete, and suppress the address so nothing further goes out. The stop is the part that needs least of us: an opt-out taken through the link in a message, or by a reply, is written at service scope and refuses everywhere from that moment. Access and deletion are the manual ones.

The honest limit on our records. Work done through the chat agent is not written to the command log today — the one path that does real DNS, HTTP and SMTP work leaves no per-record audit trail. What we can reconstruct for that path is the request log and the stored result, not a step-by-step account of which row was touched when. It is a known defect, it is on the list to fix, and you should know it before you promise somebody a full history.

10. If there is a breach

We will tell you without undue delay, and in any case within 72 hours of becoming aware of a personal data breach affecting data we process for you. We will say what happened, when, which categories of data and roughly how many people are affected, what we have done, and what we do not yet know — with the limits in section 9 applying to how precisely we can describe which rows were involved.

Report a vulnerability to security@skygen.ai. We do not pay bounties and we will not threaten you for telling us.

11. Deletion when it ends

When your account ends, we delete it, its worlds and its memory, on request. Worlds are meant to be deleted automatically after thirty days without activity, whether or not the account is open — but per section 6 nothing schedules that at the edge today, so the automatic half is an intention and the request is the part that works. Stated here rather than in the sentence above it, because a deletion commitment in a processor agreement is exactly the kind that gets relied on.

What survives, and why:

• The suppression list. A person asked not to be written to. That record must outlive your account or the request stops working, so it is retained after deletion of everything else and it goes on refusing. It is held at your scope, which is what lets it refuse every campaign and mailbox you have; entries we must apply to nobody at all are held at service scope. Removing one is possible and is itself recorded — who removed it, when, and the reason given — because a list that can be quietly shortened is not a record of anything.
• Rows in the shared corpus, per section 1. They are not yours to withdraw, and the people in them can have them deleted by asking us.
• Log lines already written, for as long as the hosting platform keeps them.

12. Audit

We will answer questions about any of this in writing, and this page is the answer to most of them. There is no certification report to send, no questionnaire portal, and no on-site audit. If you need an auditable processor, we are not one yet, and the sentence before this one is the whole of our position on it.

What is still open in this draft

• A scheduler. Until there is one, the thirty-day deletion in section 11 and the mailbox read that honours a stop are both manual, and sections 6 and 11 have to keep saying so.
• A service-wide opt-out written by the product itself, so section 11 does not depend on us copying an entry across by hand.
• The legal entity that is the processor, its address, and how notice is given.
• Whether standard contractual clauses are executed with customers who need them.
• A per-record audit trail for the agent path, so section 9 can stop containing a defect.
• A retention period for logs, and redaction of addresses in them.
• An automated deletion path, so a request is not carried out by hand.