Legal
Sub-processors
Everyone who processes customer data on our behalf, what they do, and where. This table is rendered from one register that lives in our source code, so it is the register rather than a copy of it. That register is maintained by hand: nothing in our code checks that every service we call has an entry here.
| Who | What they do for us | What they receive | Message content? | Where | Status |
|---|---|---|---|---|---|
| Anthropic | model provider | The assembled drafting context: recent messages in the thread, selected facts, and the persona description. Also the FILE ITSELF for an attachment we read — a PDF or an image is uploaded to the provider as a content block, because the draft is written by the same provider that reads the document rather than by a parser of ours. A PDF the customer uploads, adds as knowledge or has read whole is first read for its own words on SlyOS’s servers, and only the pages whose words cannot be read that way, such as scanned pages, are sent, ten to a request; one whose words cannot be read on the server at all, such as an encrypted file, is sent as it is. Also the customer’s conversations with the SlyOS assistant, and the words on each web page SlyOS’s browser opens for them, from which the model decides the next step; on a checkout page those include the basket, the total, the delivery address and the last digits of a card. Also the page the customer sends from the SlyOS browser extension with a question: its address, its title, its words up to 24,000 characters and what they selected on it, from which the model writes the answer. And, when the customer asks SlyOS to look at their Mac, the names of the apps open on it, their window titles and the on-screen text SlyOS reads through macOS Accessibility, from which the model decides what to look at next and writes the answer; a screenshot is shown to the customer and is not sent. Sent for inference only. What the provider may do with it afterwards is governed by the published API terms of that provider; SlyOS has not signed a separate agreement that overrides them. | Yes | United States | In use |
| OpenAI | model provider | Every message and draft we embed for retrieval, and the assembled drafting context when Anthropic is unavailable and drafting fails over. On the same failover, the customer’s conversation with the SlyOS assistant, with the words of the web pages SlyOS’s browser opened for them, and the names of the apps, window titles and on-screen text SlyOS read on the customer’s Mac when asked to look at it. Also the AUDIO of a voice note sent to the customer: the file is uploaded to the provider to be transcribed, so the spoken words of the person who recorded it reach the provider as sound and come back as text. And, on the Even G2 smart glasses, the AUDIO OF AN INSTRUCTION THE CUSTOMER SPEAKS: the glasses capture it only while the customer has chosen to speak one, the plugin keeps only the frames the host attributes to the wearer, and those are uploaded to the provider to be transcribed into the words that steer a rewrite. Sent for inference only. What the provider may do with it afterwards is governed by the published API terms of that provider; SlyOS has not signed a separate agreement that overrides them. | Yes | United States | In use |
| Google (Gmail and Calendar APIs) | message delivery | The customer's own Gmail mailbox and Google Calendar, at their direction. Reading: whole messages — bodies, subjects, sender and recipient addresses, and attachments. Sending: a reply the account holder approved, delivered from their own address, with any attachment inside it. Calendar: we read events in the window shown, and when the account holder approves one we CREATE an event carrying its title, description, location, times and the email address of every attendee they name. Sign-in and account identification also pass through Google: the OAuth code exchange and, for the calendar, a userinfo call that returns the address of the account being connected. | Yes | The customer's own Google account; we call one global endpoint and select no region. | In use |
| Google Cloud (Pub/Sub) | cache and queue | Gmail change notifications for mailboxes the customer connected: the mailbox address and a history marker, delivered to a topic in our project. No message bodies, subjects or drafts — the notification says a mailbox changed, and the mail itself is then fetched from the Gmail API directly. | No | us-central1 | In use |
| Fly.io | hosting | Runs the brain container, and a second container running the ClamAV virus scanner that every inbound attachment is held behind — so attachment bytes cross Fly’s private network between the two. Message content passes through memory in transit; neither container declares a Fly volume, so nothing is written to their disks. | Yes | Ashburn, Virginia (region `iad`) in the checked-in configuration. The production deployment region is not recorded in this repository. | In use |
| Vercel | hosting | Serves slyos.world and runs the web app's server functions. Every panel request and every attachment download passes through a Vercel function in transit — message bodies, drafts, contacts, search results and file bytes. No customer data is written to Vercel storage: the app uses none of Vercel's storage products. Request paths do reach Vercel's runtime logs, and those paths carry our own thread, card and attachment identifiers. | Yes | Global edge | In use |
| Neon | database | The primary Postgres store: messages, drafts, contacts, facts, embeddings, encrypted channel credentials, events and the audit log. Attachment bytes sit in object storage, but the text around them sits here: every filename, the words read out of a PDF or an image, and the transcript of every voice note are ordinary columns of this database. Neon also holds the point-in-time-recovery history those rows are restored from, and that window is set to seven days. Deleting a row takes it out of the live database immediately, but a restorable copy of it stays in Neon’s history until the window has passed it — for those seven days the row is gone from the live database and still sitting in a copy the provider could restore. After seven days Neon has nothing left to restore it from: no snapshot of the production database is kept beside that history, and no snapshot schedule is set. We do not lift one account out of that history, we do not edit it, and we do not restore selectively from it. | Yes | us-east-1 | In use |
| Amazon Web Services | object storage | Attachments, uploaded context-library files, and generated export archives. Where an audit bucket is configured, also the usage-event stream copied out of the database as newline-delimited JSON — account id, device id, session id, app version, platform and the event’s own properties, spanning every account. That copy carries no message content (`assertNoContent` refuses it at emit time) and is deliberately outside the per-user key layout, because an audit trail a single account can erase is not an audit trail. | Yes | us-east-1 | In use |
| Upstash | cache and queue | Drafting jobs and short-lived counters. A job carries our own account and card identifiers plus, when the account holder has steered a draft, the instruction they typed for it — never a message body, a draft or an attachment. Rate-limit counters are keyed on the caller’s IP address or account id and expire after two minutes. Also a cached copy of the public aggregate figures shown on the website. | No | us-east-1 | In use |
| Postmark | email delivery | Our own mail, in the six kinds the transport can send — five transactional and one marketing. Transactional: a sign-in link (one send that also carries an address-change confirmation and a seat invitation, which carries the invited colleague’s email address), a welcome sent once at a person’s first sign-in, a billing notice, a receipt to someone who used the contact form or joined the waitlist (their name and address, never the message they wrote), and our own nightly operations digest of aggregate figures addressed to us. Marketing: a campaign written in our admin console and sent on a separate Postmark broadcast stream, with an unsubscribe link appended to the body of every copy. Whoever sends a campaign picks its audience — everyone on the waitlist, everyone with an account, or both — and the only address the send drops is one that has already unsubscribed, so Postmark is handed the addresses of people who hold no account here. Never a customer message, a draft, or anything derived from either. | No | United States | In use |
| Sentry | error tracking | Nothing today. No error-tracking client is installed in any service and no DSN is read anywhere in the codebase, so no data of any kind reaches this provider. Kept on the register because the account is intended: if it is switched on, the intent is that stack traces and request metadata go and message bodies, draft text and credentials do not. | No | United States | Not in use yet |
| Stripe | payments | Billing email, card details entered directly into their form, and the plan. Card numbers never reach us. | No | United States | In use |
| Apple Push Notification service | push notifications | A device token, our own thread and card ids, a count of waiting cards, and the notification text. That text names the person in full: the contact display name we hold for them, or the conversation title or the email subject line when no contact matches. Never draft text, never a message body. | Yes | Global | In use |
| Apple Maps | maps | When an answer is about places, SlyOS sends Apple the place names and street addresses (never message text) to find them on a map. Your browser or phone then loads the map picture from Apple, which sees the pins' locations and your IP address, as with any map. | Yes | Global | In use |
| Firebase Cloud Messaging | push notifications | Nothing today. When Android push is built, Firebase will receive a device token, our own thread and card ids, a count of waiting cards, and the notification text — which names the person in full: the contact display name we hold for them, or the conversation title or the email subject line when no contact matches. Never draft text, never a message body. | No | Global | Not in use yet |
| Google Fonts | content delivery | Nothing from us. The marketing page at slyos.world links its web font to Google’s font CDN, so a visitor’s own browser requests the stylesheet and the font files from Google — and in doing so gives Google that visitor’s IP address, their user agent, and the address of the page they are on. No account data and no message content. It happens on the first paint, before the cookie banner is answered. | No | Google’s global content delivery network; the visitor’s browser chooses the edge and we select no region. | In use |
| Slack | message delivery | Replies the account holder approves, posted into their workspace as them: the reply text and the channel or direct message it belongs to. Attachments are uploaded to Slack first and posted as the same message. | Yes | The customer's own Slack workspace; we call one global endpoint and select no region. | In use |
| Meta (WhatsApp Business Platform) | message delivery | Replies the account holder approves, sent from their WhatsApp Business number: the reply text and the recipient's phone number. An attachment is uploaded to Meta's media endpoint before the message that carries it. | Yes | Meta's own infrastructure; we call one global endpoint and select no region. | In use |
| Telegram (Bot API) | message delivery | Replies the account holder approves, sent by their bot: the reply text, the chat it goes to and the message it answers. Attachments are uploaded with it, and their filenames go with them. | Yes | Telegram's own infrastructure; we call one global endpoint and select no region. | In use |
| Lovable | message delivery | The build instruction the account holder approved, in their own words, sent to the Lovable project they named — over an OAuth connection to THEIR OWN Lovable account, which SlyOS never sees the password for. Lovable then reads and MODIFIES the source of that project, so the customer's own code and anything inside it is material Lovable already holds and now changes at our request. What comes back and is stored by SlyOS is Lovable's summary of what it changed, the commit it made, the credits it spent and the preview URL. No conversation, message, draft or attachment is sent: a build carries the instruction and nothing else, and SlyOS refuses one that names no project. | Yes | Their own published policy says Personal Data is processed "in a number of countries, including the United States"; we call one global endpoint and select no region. | In use |
| Microsoft (Graph) | message delivery | Replies the account holder approves, sent from their own mailbox or Teams account: the reply text, and any attachment carried inside the reply request. We also read the mail, Teams messages and calendar the customer connected, through the same API and at their direction — and, when the account holder approves one, we CREATE a calendar event carrying its subject, description, location, times and the email address of every attendee they name. | Yes | The customer's own Microsoft tenant; we call one global endpoint and select no region. | In use |