Privacy Policy

What this covers

This policy covers the hosted Relay service and this website. Relay is also open source under the MIT license. If your company runs its own deployment, that company operates the service and its own policy applies to it, not this one.

This website

The only thing this site collects is the email address you submit to join the waitlist. It is stored in a hosted Redis database and used to contact you about access. The site sets no analytics, advertising, or third-party tracking cookies.

Account data

Sign-in is email and password. There is no SSO or social sign-in today. Alongside your credentials, the product stores the display name and avatar you set, and a session that keeps you signed in.

What the agent handles

Using Relay means the agent works with your content. What gets stored:

• Conversations. Messages, attachments, the tools the agent ran, and the thinking trace for each turn.
• Files. Anything uploaded to the Knowledge Base, or created by the agent, or shared with you. Documents are split into chunks and embedded so they can be searched by meaning.
• Memory. Dated facts captured from conversation, so you do not repeat yourself.
• Scheduled tasks. The task itself, its delivery target, and a full log of every run, which you can open and read.
• Credentials for connected apps. OAuth tokens, encrypted at rest.
• Operational records. Runs, deliveries, grants, and approvals, which together form the audit trail.

Where memory goes

A captured fact lands where it was said, and nowhere else. This is the rule in full:

• Said in a private chat: captured nowhere.
• Said in a DM: your personal memory only.
• Said in a public channel: the channel, the org-wide brain, and a tagged copy in your personal memory.
• Said in a group: the group, and each participant, tagged with where it was said.

The memory page shows each fact with its source and date. Memory is read-only there: you can see what was learned and where it came from, but you cannot edit it in the product. Admins see an org-wide tab in addition to their own.

Who can see what

Every person and every room is a scope, and a scope owns its own memory, files, credentials, permissions, schedules, and sandbox. One person's workspace cannot be read by another. Access across scopes happens only through an explicit grant.

The org scope is mounted read-only into every turn, which is how company-wide knowledge stays in reach without one room writing into another. Document visibility is enforced when a search runs, so a file cannot surface in a room that should not have it.

Connected apps

Relay connects to Google, GitHub, Linear, Notion, Slack, Dropbox, and X. Each connection belongs to one person. Tokens are encrypted at rest and are injected only into that person's private conversations, never into a shared room. Disconnect any of them at any time from Settings, or revoke access at the provider.

Slack

When Relay is installed in a Slack workspace it can see the messages and files in the conversations it is part of. In a channel it replies when mentioned. Reading a channel without being mentioned is off by default and is turned on per channel.

External guests and Slack Connect members are detected. When one is present, the agent stays silent in-channel, replies only ephemerally, uploads no files, and does not read channel content.

Who else processes your content

Answering a turn means sending its content to a model provider. Which one depends on the models your company enables: Anthropic, OpenAI, OpenRouter, or any compatible endpoint your company points Relay at, including a self-hosted model. Where a deployment enables them, web search runs through Firecrawl and document embeddings through Voyage.

Sandboxes, the machines the agent runs commands on, are provided by the backend the deployment uses: local Docker, AWS microVMs, Sprites, or Smolmachines. Postgres holds sessions, memory, deliveries, grants, and the work queue.

Security

The agent acts as the person it is working for, with their credentials and their permissions, and what it does is recorded.

• Your company sets one security posture, and narrower scopes can only tighten it. On the default posture, external content such as tool results, webhook payloads, attachments, and overheard messages is screened for prompt injection before it reaches the model. If the screener is unavailable, the content is labelled unscreened rather than trusted.
• The command policy applies on every posture. Destructive commands need approval, and a few are denied outright.
• Approvals appear inline in the chat and in Slack, showing the exact command and the reason for it.
• Secrets stay out of the sandbox where they can. A broker makes the outbound call server-side, pinned to the credential's host, methods, and paths.

Keeping and deleting

Content is kept while the scope that owns it exists. You can delete a chat at any time. Deleting a project removes its files, memory, and schedules, and returns its chats to whoever started them. A scope's sandbox disk persists across turns and across days, which is what lets long-running work continue, until the scope is deleted. Run logs are kept as part of the audit trail.

To delete an account and the scopes it owns, or to ask what is held about you, contact your workspace admin or write to us.

Changes

If this policy changes, the date at the top changes with it.

Contact

Questions about this policy, or a request about your data: [email protected].