Skip to content

Privacy Policy

Last updated October 28, 2026

Ray works inside your team’s chat. That means it handles real team conversations, so this page is specific about what it reads, what it keeps, who processes it, and how you delete it. Ray is operated by Mark Skrypka, trading as Creako Labs (“we”, “us”). Questions: support@heyray.io.

What Ray reads

Ray sees messages in the channels and threads it has been invited to, and direct messages sent to it. It cannot see channels it isn’t a member of. It also sees the reactions people add there and acts on two kinds. A check mark on its own follow-up message, or on the message a follow-up is about, ends the follow-ups of the person who added it. A thumbs up or down on one of Ray’s own messages raises or lowers how far Ray trusts the remembered facts that answer drew on, and the fact’s history keeps who reacted. Ray stores no other reactions. When you message Ray in its own conversation, Slack tells it what you have open beside it, such as a channel, a message or a canvas, so “this” means what you are looking at. Ray uses that for the message you send and nothing else, reads it only the way it reads anything, in the channels it is in, and keeps only the latest, for at most 15 minutes. In the channels it is in, it also indexes what people say, so it can find an earlier discussion when you ask (see Workspace search below). When someone asks about a file shared in those conversations, Ray opens that one file to answer. It never browses files on its own, and the file itself is not stored: what Ray took from it stays with the conversation as a lookup, under the 30-day clock below. Links work the same way. When someone asks about a link pasted in those conversations, Ray opens that one link to answer, from the site’s own public address. A file in a drive such as Google Drive or Dropbox, or a private Google Doc, opens through the asking teammate’s own connection, with their access. Ray never opens links on its own. The short preview Slack shows under a link stays with the message it belongs to. Most integrations are connected per person: each teammate links their own account (an issue tracker, email, a calendar), and Ray acts on that tool as the person asking, with their access. A few tools offer no per-person login, and those connect once with a single workspace key that covers the whole team. A change Ray can put back, like creating a ticket, runs at once from the connected account of the teammate who asked, and Ray’s reply carries an Undo button that anyone on your team can press until the end of the next working day. A small team-only change, like an internal comment or a label, runs at once with no Undo, and a teammate removes it in the tool. Anything Ray cannot put back, like sending an email, happens only after someone on your team approves it, and then runs from the approver’s connected account.

When someone installs Ray, it reads that person’s own email address once, so the legal and security notices below reach them. Slack’s install screen words the permission as viewing the email addresses of people in your workspace, the only form Slack offers. Ray uses it at the install alone, as the person installing, and gives it back straight away. Ray reads no one else’s address.

What Ray stores

  • Conversation context. Ray keeps the threads it actually participated in (the messages it engaged with and its own replies, plus rolling summaries of long threads) so follow-ups make sense. It keeps no lasting copy of the rest of your workspace: the text of a message Ray stayed out of is stored only when Ray reads it to answer a question, and then as a lookup under the 30-day clock below. Beyond that it passes through a short-lived context window, minutes-scale, covered below.
  • Team memory. Durable facts your team tells Ray or that it learns from conversations it engaged in (preferences, constraints, who owns what), stored with embeddings so it can recall them later. Memory can be switched off by an admin at any time. Corrections supersede rather than silently overwrite.
  • Lookups and actions. Every tool call Ray completes for a conversation leaves a record: a web search, a page it opened, channel history it read, a tracker, email or calendar read through a connected tool, its notes on a file it looked at, and every action it performed. The full result is kept with that conversation for 30 days after the conversation’s last activity, so a follow-up can reuse it instead of fetching it again, and is then deleted. What remains is a one-line, content-free note (the tool, a title, when, and whose connection it ran through) and, for actions, a pointer to what was created, so Ray can answer “what did you look up?” and “what did you do?” honestly. A result above 1 MB is never kept, only its note.
  • Who sees a kept result. A result read through a teammate’s own connection is shown again only to that teammate. Everyone else in the thread sees the note and what Ray posted. A result from one conversation serves a question in another only where workspace search may answer from that conversation (see Who sees what search finds below). A result read in a direct message stays with that person.
  • Workspace search. So Ray can find what your team said, it keeps an entry for each message people post in the channels it is in: public and private channels and group DMs. An entry holds where and when the message was posted, who posted it, a numeric summary of its meaning (an embedding), and one-way codes made from its words with a key only Ray holds, so an exact word, a ticket number, or a link can find it. Ray does not store the words themselves. It reads a message from Slack only when a search needs it, so an edit or a deletion shows. Ray indexes no direct messages between people (it cannot see them), no posts by bots or apps, and nothing in a channel shared with another organization. When Ray joins a channel, it reads that channel’s last 30 days once, a little at a time, to index them. Before Ray indexes a message, the message waits in a short queue for at most a day, with anything shaped like a secret or an email address already removed and each link cut down to its site and path.
  • Who sees what search finds. Ray answers from different places depending on where it posts the answer, as Slack’s own search does. In a public channel, it answers from public channels. In a private channel or a group DM, it answers from public channels and that conversation. In a direct message with you, it answers from the public channels it is in and from the private channels and group DMs you share with it. Guests find only the conversations they are in, and Ray brings nothing from elsewhere into a channel shared with another organization. After Ray brings words from a private conversation into another one, a post it sends from there into a different channel waits for the person who asked to approve the exact text. A schedule set up there waits too. Its approval shows the instruction, the timing and the destination, because Ray writes a schedule’s text at each run. A post or a schedule sent from another conversation into a channel shared with another organization waits for the same approval, which names the organization when Slack says which. Ray replies inside a shared channel, to the people who ask there, without that approval.
  • Follow-ups. Who owes what, by when, and where it was asked, never the words of a message, deleted 30 days after it ends.
  • Schedules and settings. Digest schedules, reminders, timezone, admin list, the memory and workspace search switches, and the channels members asked Ray to skip or to keep again.
  • Governance records. A content-free audit trail of sensitive events (installs, approvals, admin changes, purges), never message text.
  • The installer’s address. Where the named list of subprocessors, notice of its changes and any security notice go, and nothing else. It is replaced when someone installs Ray again.
  • Billing state. Your plan and monthly task counts. Card details never touch our systems. Payment runs entirely through Stripe.

How long it’s kept

Stored conversation context and team memory have no automatic expiry: they persist until your team deletes them (below) or uninstalls Ray. We’re explicit about this because it’s what makes Ray useful: an assistant that forgets your conventions every week isn’t a teammate. Around that durable core, the operational stores are short-lived:

  • The full results of lookups and actions are deleted 30 days after their conversation’s last activity, and the content-free note of each stays with the conversation.
  • Ray keeps a workspace search entry for 90 days from its message, and deletes it sooner when the message is deleted, when Ray is removed from the channel, when the channel is deleted, or when the channel is shared with another organization. Slack sends no notice when a retention policy deletes a message, so Ray deletes that entry when a search next reads the message and finds it gone, and at 90 days at the latest.
  • A long document Ray is reading, such as a big Google Doc, is kept in Redis for 15 minutes so Ray can read on page by page, and is then deleted. One read through a teammate’s own connection is kept for that teammate alone. A document’s pictures are never stored.
  • A file Ray makes for you, such as a spreadsheet or a PDF, is posted to Slack and not kept by Ray. One that has to wait first, an export on its way to your thread or an answer waiting on its approval, is kept in private file storage until it is posted or declined, and is deleted after four days at the latest. What an export will read waits in Redis until the export starts, a day at most.
  • When Ray makes a change it can undo, what the Undo needs is kept in Redis: the values Ray changed, as they were before, and a pointer to anything it created. It is deleted an hour after the Undo button expires at the end of the next working day.
  • In-flight coordination state (message buffers, recent-context windows, pending approvals) and platform caches (channel names, member display names and avatars) live in Redis with TTLs from seconds to a few days and clean themselves up.
  • Run records on the platform that runs Ray’s background work, including debugging snapshots of what Ray was shown for a turn, expire with its retention window, at most 30 days.
  • Product analytics are metadata only: token counts, latency, cost, feature and model names. Message content is never sent to analytics.

Who processes it

Ray is built on infrastructure and AI providers, our subprocessors. The list is short and deliberate, and each receives only what its job requires. Here they are by kind, with where each processes your data:

  • AI model providers: run Ray's reasoning, decide whether Ray should respond to a message, extract memory, summarize long threads, read the files and media you ask Ray to look at, and make the embeddings behind memory and workspace search. On each provider's own infrastructure, in regions it chooses.
  • Hosting and background work: receive workspace events and run Ray's work, and their run records expire within 30 days. In US East.
  • Database: stores conversation context, memory, the workspace search index, lookup results and actions, schedules, and settings. In US East.
  • Short-lived state: holds coordination state, caches and short queues, a long document for 15 minutes while Ray reads it, what an Undo needs, and the encrypted Slack workspace token. In US East, with copies in London and Frankfurt.
  • File storage: holds a file Ray made while it waits to be posted, until it is posted or declined and for four days at most. In Western Europe.
  • Integration platform: runs integration actions, opens the drive files you ask Ray to look at through your own connection, and holds the tokens of the tools you connect. On its own infrastructure.
  • Web search: receives search queries, only when Ray searches the web. On its own infrastructure.
  • Email delivery: sends the person who installed Ray the named list of subprocessors and notice of any change to it. In US East.
  • Chat platform (Slack): the platform Ray lives in. On its own infrastructure.
  • Analytics (PostHog): product analytics (metadata only, never message content) and website analytics on heyray.io: page visits counted for everyone without cookies, and session recording and the rest only for visitors who accept. In the EU.
  • Payments (Stripe): billing only, and we never see card details. On its own infrastructure.

The person who installs Ray gets the named list by email at the install, and anyone can ask us for it at support@heyray.io. Before a new subprocessor touches a workspace’s data, we email its installer at least 30 days ahead. They can object by replying, and if we can’t resolve it, the workspace can cancel and get back the unused part of any paid period.

Our AI providers process conversation content to generate Ray’s responses under API terms that do not permit using your content to train their models. We don’t sell your data, show ads, or train models of our own on it.

Where it’s stored

Everything durable (conversation context, team memory, the workspace search index, lookup results and action history, schedules, settings) is stored in our database in US East. Product analytics run on PostHog’s EU cloud. The list above says where the short-lived state and a file waiting to be posted sit. Our AI providers process requests on their own infrastructure, and we don’t control which region they use. We don’t offer a choice of data region today, so if your team needs one, ask us before you install rather than after.

Deleting data

  • One fact: tell Ray to forget it (“Ray, forget that”). Retired memories stop being used immediately.
  • One channel: any member of a channel can tell Ray to stop keeping it for search (“Ray, don’t remember this channel”). Nothing said there is kept from then on, what was kept is hidden from search and ages out within 90 days, and any member can undo it. Undoing it never brings in what was said while the channel was skipped.
  • Everything: a workspace admin can ask Ray to purge all stored memory, conversation context, the workspace search index, and every kept lookup result and action record. Nothing posted before the purge is indexed again. Because it’s irreversible, the purge asks for an in-channel approval first, visible to the team. It keeps your settings, the governance trail, the installer’s address, the channels members asked Ray to skip, and a marker on each conversation Ray brought private words into, so posts from it still ask first.
  • Memory off: an admin can switch durable memory off. Ray keeps working in the moment but stops remembering across conversations, and existing memory stays paused, not consulted. The switch governs team memory, and while it is off Ray stops searching the workspace too. Kept lookup results follow their own 30-day clock above.
  • Workspace search off: an admin can switch workspace search off. Ray stops indexing and searching. It keeps what it indexed before and goes on deleting each entry at 90 days, and those entries are searchable again once the switch is back on. It deletes the entry of any message edited or deleted while the switch is off, and nothing said in that time is indexed later. The purge above is the way to erase the index.
  • Uninstall: removing Ray from your workspace stops all processing immediately, revokes integration connections at the tools themselves, and deactivates schedules. Stored workspace data, the search index and kept lookup results included, is deleted after a 14-day grace window, and reinstalling within that window cancels the deletion. The content-free governance trail survives.

Integration credentials

When a teammate connects a tool, the credential is held by our integration platform. For most tools that is an OAuth token scoped to that individual person within your workspace, and they can disconnect it at any time by asking Ray. A few tools offer no per-person login and take one workspace key instead. An admin or the person who connected it can disconnect that, and because it belongs to the workspace rather than to them, it stays in place if they leave, with a prompt to your admins to rotate it. When a teammate is deactivated in Slack, their own connections are revoked at the tool itself. Your Slack workspace token is stored encrypted (AES-256-GCM) and deleted when you uninstall. Credentials are never placed in model context.

Google user data (Google Ads)

Teams can connect Google Ads to Ray through Google sign-in, and Google holds that connection to a specific disclosure bar, so this section states exactly how Ray accesses, uses, stores, shares, and protects Google user data.

  • What Ray accesses. When a teammate connects their Google Ads account, Ray can read campaign data (campaigns, budgets, ad groups, ads, keywords, and account metadata such as the account name, currency, and timezone) and can create campaign structures in that account.
  • How Ray uses it. Only to fulfill what your team asks for in chat: answering questions about your campaigns and drafting the campaign structures you request. Every write is shown on an approval card first and runs only after a teammate approves it, and new campaigns are always created paused: nothing spends until someone enables it in Google Ads itself. Google user data is never used to develop, train, or improve AI models, ours or our providers’.
  • What Ray stores. What Ray reads from Google Ads to answer a conversation is kept with that conversation for 30 days after its last activity, under the same rules as every other lookup above, and is then deleted. What persists beyond that is the conversation itself (what Ray said in your channel) and the content-free record described above: a pointer to what was created (a campaign id and its name), not campaign contents or performance data. Account details like currency are fetched live when a card needs them and are not stored.
  • Who Ray shares it with. Data read from Google Ads is processed by our AI providers to generate the response you asked for, under the same no-training API terms as everything else on this page, and by the subprocessors described above in their stated roles, and no one else. It is never sold, never used for advertising or profiling, and never transferred to any third party for any purpose beyond answering your team.
  • Tokens and revocation. The OAuth token is held by our integration platform, scoped to the individual teammate who connected (see Integration credentials). Disconnect by asking Ray, or revoke Ray’s access directly at myaccount.google.com/permissions. Either way the grant is revoked at Google, not just forgotten on our side.

Ray’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

How sensitive data is protected

The mechanisms below apply to everything Ray handles: workspace conversations, integration data, and Google user data alike.

  • Encryption in transit. Every connection, between your chat platform and Ray, between Ray and the tools it acts on (Google Ads included), and between Ray and every subprocessor, uses TLS. Nothing travels in the clear.
  • Encryption at rest. Stored workspace data (conversation context, memory, the workspace search index, lookup results and action history, schedules, settings) lives in a database whose storage is encrypted at rest. Your Slack workspace token is additionally encrypted at the application layer (AES-256-GCM) before it is stored.
  • Credential handling. Integration OAuth tokens (Google Ads included) are held in our integration platform’s credential store, scoped to the individual teammate who connected. They are never written to our own database, never logged, and never placed in model context.
  • Workspace isolation. Every stored table is partitioned by workspace and enforced with database row-level security that the application’s runtime role cannot bypass. One workspace can never read another’s data, even in the presence of an application bug.
  • Access control. Sensitive actions inside your workspace, meaning anything Ray cannot put back (sending email, payments, deletions, campaign changes), require a teammate’s explicit approval before they run. No irreversible action without your yes. A change Ray can put back in a connected tool runs at once with an Undo, except in a schedule, a watch or a scheduled follow-up that has read outside content with nobody present, where it waits for approval too.
  • Retention and deletion. The retention windows and deletion levers above apply to sensitive data with no exceptions: per-person disconnect at any time with revocation at the tool itself, a 30-day clock on every kept lookup result, a result read through a teammate’s own connection shown again only to that teammate, and full workspace deletion after uninstall’s 14-day grace window.
  • Incident response. If we learn of a security incident affecting your data, we notify affected workspaces without undue delay, at their installer’s address or the contact we have for them, with what happened and what we did about it.

Cookies on this website

Everything above is about Ray inside your chat, where nothing is stored on your device at all. This section is about heyray.io, the website.

  • One cookie we set regardless. Starting an install puts a short-lived random value in a cookie named ray_install_state and checks it when Slack sends you back. It is what stops someone else from starting an install in your name. It lasts ten minutes, cannot be read by scripts, and identifies nothing about you, so we do not ask permission for it.
  • Page visits, counted for everyone. We count visits to each page with PostHog for every visitor, without cookies and without keeping anything on your device, using a hash PostHog computes on its own servers. This rests on our legitimate interest in knowing how the site is used (GDPR Art. 6(1)(f)). Requests go to heyray.io/ingest, which forwards them to PostHog’s EU servers. We route them through our own address because ad blockers drop requests sent to analytics domains by name, not to disguise who receives them.
  • Everything else, only if you accept. If you accept, PostHog also records browsing sessions, so we can see which parts of the site lose people, and runs the rest of our website analytics. It stores an identifier for your browser for up to a year, in a cookie beginning ph_ and in local storage. Anything you type is masked before a recording leaves your browser, so form fields are never readable in a replay. Any campaign tags on the link that brought you (the utm kind, or a ref or via code), the page you landed on and the domain of the site that linked you here are kept for 30 days in a cookie named ray_attrib, so that an install can be credited to the channel that brought you. Never anything about you.
  • Your answer itself. Whichever you choose is remembered in your browser’s local storage under ray_consent, so we stop asking. It never reaches our servers.

Decline, or leave the question unanswered, and replay and the rest of our analytics stay off: no recording, no identifier and no campaign cookie. Only the page count above runs, and it stores nothing on your device. You can change your mind either way through Cookie choices at the bottom of any page, which also deletes what PostHog stored while you allowed it. We use no advertising or cross-site tracking cookies anywhere.

Your rights

Depending on where you are, you may have legal rights to access, correct, export, or erase personal data. The controls above cover the common cases instantly. For anything else, email support@heyray.io and we’ll handle it directly.

Changes

If we make material changes, such as a new subprocessor or a new data store, we’ll update this page and the date above. A new subprocessor also gets the notice described under Who processes it: an email to each workspace’s installer at least 30 days before it touches that workspace’s data.