Privacy

Privacy policy

RelayLink carries briefings between people through their AI assistants. This page says what we hold to do that, why, on what legal basis, for how long, who else touches it, and what you can do about it. Last updated 19 September 2026.

Who we are

RelayLink is operated by PillarStack LLC, a Virginia limited liability company with its principal place of business in Richmond, Virginia, United States (“we”, “us”). We are the controller of the personal data this policy describes. Questions about this policy or about your data go to hello@relaylink.ai, which is the only channel we take them on. We answer within thirty days. The terms of service sit beside this policy and say what we ask of you in return; the cookie policy, the subprocessor list and the data processing addendum go into more detail on the points here that name them.

Where a business customer has entered the data processing addendum, we process that customer's content on its instructions as its processor, and this policy describes what we do as a controller in our own right: account records, delivery, security and the correspondence of people who are not that customer's users.

What we collect

There are three kinds of people RelayLink holds data about, and they are not the same.

If you have an account

Your email address and the name you go by. The address is how you sign in and where notifications go; the name is what recipients see as the sender.
Sign-in codes, stored as a keyed hash and valid for ten minutes. There are no passwords.
API keys, if you issued any: a name you chose, a SHA-256 hash of the key, a twelve-character hint of a generated key, and when it was made, last used and revoked. We cannot show you a key again.
Connected assistants: which applications you have authorised and the tokens issued to them, which you can see and revoke on your connections page.
What your assistants remember about you, if you switch shared memory on — it is off unless you turn it on. Assistants you have connected keep lasting facts about you there, such as how you like to be worked with or what you are working on, so that your other assistants can read them and you repeat yourself less: up to a thousand facts, each up to a thousand characters. You choose whether an assistant keeps a fact only when you ask it to, which is the default, or also when it notices one as you work. Each fact records which assistant saved it and whether it was reporting your own words. You can read every one of them on your account page, delete any of them there or by asking an assistant, delete all of them there at once, and pause new ones at any time — pausing keeps what is already stored, and deleting is separate. RelayLink never adds one to a briefing, shows one to a contact or emails one; if an assistant quotes one in a draft, you see the draft before it is sent. All of it is deleted when you close your account. It is RelayLink's copy only: an assistant that also keeps its own memory has to be asked to forget it there as well.
Your notebook, if you use it: notes, tasks, journal entries, reports, projects, decisions and the other things you or your assistant keep there, with the history of each change. A deleted entry can be recovered for thirty days and is then removed for good. It is private to you. A fact you choose to share on a project is shown to the people on that project, and one you shared on somebody else’s project stays there if you close your account.
Documents you attach, if you attach any: a plain-text or Markdown file, up to five per briefing and five megabytes together, one megabyte each. It is checked to be well-formed text before it is stored, held privately until you send it, and readable then only by whoever the briefing reaches — never rendered as anything but text, and never opened by us for any other reason. One you delete privately can be recovered for thirty days and is then removed for good; withdrawing one from every briefing it was sent on removes its bytes within about a day.
Your contacts: requests you have sent or accepted, the nicknames you gave people, and anyone you have blocked. A nickname is visible only to you unless you choose to let that contact see it.
How you organise things and what you prefer: groups of contacts (in a shared group, every member sees the others’ names), private tags on conversations and contacts, items you track and reminders you set, your time zone, quiet hours, whether a briefing arriving is emailed to you, contacts you have muted, whether senders are told you read their briefing, and whether tips are shown.
A search index of your own material: the words in your correspondence and your notebook, so that you and your assistant can search them. It is yours alone and is deleted when you close your account.
Mail forwarded to you, if you set up a forwarding address: each forwarded message whole, including who it came from and its subject, written by whoever wrote it. It stays until you archive it; archived mail is removed after ninety days.
Request links and webhooks, if you create them. Somebody who writes to you through a request link becomes a provisional record (below), and what they write becomes an ordinary briefing to you. A webhook sends the sender’s name and address, the topic and the time of each briefing that arrives to the address you chose; we keep a record of each delivery for thirty days.
Your plan: which plan the account holds, and when you share one, the seats and the addresses you invite to them.
Three cookies, all strictly necessary: the sign-in cookie relaylink-signin, which ends after at most eight hours without use; an antiforgery cookie the sign-in, consent and account forms use to check that a submission came from the page we served; and relaylink-notice, which carries a one-line confirmation of what you just did in your account to the next page and lasts two minutes at most. Where the assistant built into your account pages is available, those pages also keep whether its panel is open and a message you have typed to it but not sent in your browser’s session storage, which the browser discards when the tab closes. The public pages set nothing. The cookie policy has the detail.

If somebody sends you a briefing and you have no account

Your email address, and a stand-in name made from the part before the @ until you give your own, so the briefing can reach you. This creates a provisional record that lets you read and reply without registering. You can sign in with that address at any time and it becomes your account. The same kind of record is made when somebody writes to a person through a request link, when an account holder invites you to a seat on their plan, when we invite you, and when an address is entered on the sign-in form and the code is never used.
The link in your email is a token that opens the briefing for thirty days. A reply by email is accepted for sixty days after that.
Three kinds of email somebody else can cause you to receive: a briefing notification, a contact request, and an invitation to a seat on their plan. The first two carry a one-click unsubscribe that blocks that person; we tell them nothing, you need no account, and using it does not create one. Neither unsubscribe expires: the link in an old email works as well as the one in today’s. A seat invitation carries none and lapses on its own.

The briefings themselves

The content of every briefing and reply, with its provenance labels: which words a person wrote, which an assistant drafted and a person approved, and which are inferred. The labels are the product, and they are stored with the text. Content may contain whatever the sender chose to include, including personal data about third parties; the sender is responsible for having the right to send it.
What happened to it: sent, the notification email accepted or refused, the link opened, read by an assistant, opened in your account, acknowledged, replied. These are timestamps, each with the way it happened — through a connected assistant, in your account, from the emailed link, or by email reply — and, for an assistant, which application it was and the name and version that software reports for itself. The application records no IP address, device or browser against any of them, although our hosting provider’s request log, described under operational data below, records each request for thirty days. Opening a link is never shown to the sender as evidence that you read it, and the sender is never told which assistant you use.
Replies sent by email are read once, turned into a reply on the thread, and the email's own headers are kept only as far as needed to recognise a duplicate delivery. Attachments on an emailed reply are discarded — a document attached through the service itself, described above, is a different thing and does travel.
A document attached to a briefing you receive is readable by you and by an assistant you ask to read it, for as long as the sender has not withdrawn it and the account that sent it stays open. Nothing about your reading or downloading it is shown to the sender.
Your assistant's session is never sent whole. RelayLink receives what you approve into a briefing, and what you or your assistant choose to keep here: a handoff, a notebook entry, a fact in shared memory, or a support request or feedback your assistant sends for you.
What you say to the assistant we host, where it is available and you use it: your messages, its answers, and what it looked up in your account to write them. A conversation is deleted ninety days after its last message, is included in your export, and is deleted outright when you close your account. A usage record holding no content is kept for ninety days, including after you close your account, so the service’s spending limit stays honest. It is private to you: nothing in it reaches a contact unless you approve a draft, which is an ordinary package after that and carries its own labels.

If you write to us for support

The support form at /support is ours; there is no help-desk or chat-widget company behind it, and nothing on that page is loaded from anybody else.

What you tell us: the email address you give us to answer, what the request is about from a fixed list, your one-line summary and your message. If you were signed in, the address is the one on your account rather than one you typed.
What our own server already knew: which deployment you were talking to and which build it was running, the name it answers to, whether it can send email and whether sign-up is open there, and — only if you were signed in — a few facts about your account: whether it is activated, when you last signed in, how many active API keys, contacts and briefings it has. Never a key, never the hash of one, never a sign-in code, and never anything from a briefing. A request sent from the public page carries none of the account facts, whatever address is typed into it.
What your browser reported, if you sent a request from a page in your account and left the diagnostics box ticked: up to ten recent script errors and blocked resources, each one a short message, the file it happened in and a line number. The page shows you exactly what those are before you send them. Web addresses in them have their query strings removed and any identifier or token in the path replaced before they are stored, so a link to somebody’s correspondence cannot end up in a support record. We do not collect the contents of the page you were on, the requests it made, or anything you typed anywhere but the form.
Everything either of us says afterwards, including replies you send by email. A reply is matched to your request by the address it was sent to, and we record the address it appeared to come from and what our email provider concluded about it. We always answer the address on the request itself, and nothing that arrives by email can change that address or authorise anything about your account.
Requests your assistant sends for you. A connected assistant can open a support request, reply to one or send feedback on your behalf; each is handled exactly as if you had used the form.

Operational data

Application logs for thirty days, in Microsoft Azure. They never contain recipient addresses or the tokens in links; tests hold that line.
A request log kept by our hosting provider for thirty days: the address of each page requested — for a briefing link, the link itself — with the requester’s IP address and the identifying string their browser sends. We use it to diagnose faults and to investigate abuse.
A database audit log for thirty days, recording the statements that run against the database, so that misuse of it can be detected.
Performance telemetry (which pages and endpoints were slow or failed, and counts of which tools assistants call), with any token in a path redacted before it leaves the app, kept for the same thirty days. The counts carry no account, no address and nothing you wrote — they say a tool was called, not who called it.
Your IP address is used to rate-limit public pages and sign-in attempts, where the application holds it in memory for the length of the limit; it also appears in the request log above. It is recorded, for ninety days, against security events on your account: a sign-in code requested, a sign-in succeeding, being refused or locked out, signing out or ending every session, an application connected, disconnected or refused, a key created or revoked, the account exported or closed, including events an administrator causes. That record exists so a compromised account can be investigated, and you can read your own on your account page. The application never records it against reading, sending or replying to a briefing.
Records the service keeps to run: a log of the emails we sent, for 180 days; background work and webhook deliveries, for thirty days; records of inbound email used to recognise a duplicate delivery, for thirty days; drafts that were never sent, for ninety days; the log of contact requests an account sent, for a week, to enforce the daily limit; sign-in codes, for a week after they expire; expired assistant tokens, for fourteen days; and confirmations an assistant asked you for, for a week after they lapse.
Database backups for fourteen days, so a fault can be undone.

What we do not collect

No precise location, no contacts from your device, no payment card details (when we take payment, a payment processor will hold them and we will name it first), no sensitive categories of data on purpose, and nothing from your assistant beyond what you approve or ask it to keep — and, if you let shared memory keep facts as you work, the facts it notes about you. No analytics and no tracking of any kind: the diagnostics described above are collected only when you send a support request, only from that one form, and only what is listed there. We make no decision about you by automated means that has a legal or similarly significant effect.

How we use it

To deliver briefings and replies to the people you address, to let you and your assistant read what you have received, to sign you in, to stop abuse of the service, to tell you about the service when you have asked us to, to answer you when you write to us, to comply with the law, and to keep the service running. We do not use the content of briefings to train models, to build profiles, or to advertise. There are no advertisements and no third-party analytics on this site.

Nobody at the company reads correspondence in the ordinary course of running the service. A person may look at a specific briefing or account to investigate a fault you report, a security event, a report of abuse, or a legal demand, and only as far as that needs; access to production data is limited to the people who operate the service. What an administrator does is recorded, with their own IP address.

Sign-in codes, contact requests and acceptances, and the welcome email are part of the service and cannot be turned off while the account exists. Notifications of briefings and replies can: switch them off, mute one contact, or set quiet hours to hold them until morning, and the briefing still reaches your inbox. What can always be stopped is a person: briefing notifications and contact requests carry a link that blocks whoever sent it and needs no account. We send no marketing email.

Our legal basis

Where the law asks us to name one (the GDPR and the UK GDPR do), this is the basis for each kind of processing.

Performance of a contract with you: everything needed to run your account and deliver what you send.
Our legitimate interests, balanced against yours: delivering a briefing somebody addressed to you before you have an account, keeping a sender's record when the recipient leaves and the reverse, preventing abuse, keeping logs for security, and improving the service from how it is used in aggregate. You may object to processing on this basis, and we will stop unless we have a compelling reason not to.
Consent: any marketing we ever send. Every such email will carry a link to a page where you can change what we send or stop all of it, without an account and without signing in, and that link will not expire. You can also withdraw by telling us. We send no marketing email today.
A legal obligation: where we must keep or disclose something because the law says so.

The person you address. That is the point. What they receive is exactly the briefing you approved, with its provenance labels, and nothing from your private session.
Their assistant, and yours. An assistant connected to RelayLink can read the briefings in its owner's inbox and draft replies. What an assistant's provider does with what it reads is governed by that provider's own terms, not by this policy, and you choose which assistant to connect.
OpenAI, but only where the assistant built into your account pages is available and you use it, and only what that conversation involves: what you type to it, and whatever it fetched from your account to answer you. We ask OpenAI not to store the exchange and it is not used to train models; OpenAI keeps its own abuse-monitoring logs for up to thirty days. Nothing else on RelayLink sends them anything — a briefing you send, a reply you receive and every page you read are untouched by it. Searching by meaning, which would send text to OpenAI, is built and switched off, and we will update this page before switching it on. This is the opposite of an assistant you connect yourself: this provider is one we chose, so it is ours.
Microsoft Azure hosts the service, the database, the logs, the secrets and the documents you attach, in the United States.
Mailgun sends every email and receives every emailed reply on our behalf. A notification carries what the recipient needs to decide whether to open it: the sender, the topic, the note, the question, the summary and the start of the message. An emailed reply is kept at Mailgun for three days while we collect it, and Mailgun keeps its own delivery logs under its own policy. Our emails load no images and we have not enabled Mailgun’s open or click tracking, so no link in a RelayLink email is rewritten through a tracker.
Cloudflare answers the DNS lookup for relaylink.ai. It sees the lookup your network makes and none of your traffic, which goes straight to Azure.
New Relic would receive performance telemetry and application logs, with link tokens removed and no briefing content in them, if we switched it on. It is not switched on today.
Google hosts the mailbox our contact address delivers to. Mail you send to hello@relaylink.ai, and the notices we send ourselves when a support request arrives, which carry the requester’s address and the start of their message, are read there.
GitHub holds our source code and runs the deployment that applies database changes. That deployment’s identity can read and write the database as well as change its structure, and is used for deployments only.
Stripe would take payment for a Pro subscription and hold your card details, if checkout were switched on here. It is not switched on today, and nothing bills.
A webhook receiver you register receives the envelope of each briefing that arrives for you — the sender’s name and address, the topic and the time — and never its content.
Nobody else. We do not sell personal data, share it for targeted advertising, or hand it to a partner. We would disclose data if the law required it, in response to a valid legal process, or to protect somebody's safety, and we would tell you unless the law forbade that too. If the company or the service is sold or merges, your data goes with it under this policy, and we would tell you first.

The full list of companies that process data on our behalf, with what each does and where, is the subprocessor list. We will update that page before switching on one not already named there. This site links to other sites, such as the assistants' own documentation; their policies are their own.

Where your data goes

We are in the United States and the service runs there, so if you are elsewhere your data is transferred to the United States when you use it. For people in the European Economic Area, the United Kingdom and Switzerland: the transfer to us is necessary to perform the contract you asked for, or to deliver a briefing somebody addressed to you; and our providers each process under contracts that include the European Commission's standard contractual clauses and the UK addendum to them. We have not appointed a representative in the EU or the UK. Write to us if you want a copy of the clauses that apply.

How long we keep it

Briefings, replies and their delivery record are kept indefinitely. Correspondence belongs to both people in it, so one person leaving does not erase the other's copy, and closing an account removes what identifies you rather than the correspondence.
When you close your account, we delete your address, your name, your sign-in codes, your unsent drafts, your notebook, your shared memory, your conversations with the assistant we host, mail forwarded to you, your contacts, your private labels and your search index, and we revoke every key, token, connection, request link and forwarding address; the records of those remain, without your address. Your past briefings stay attributed to a closed account, so the people you wrote to keep their record. Blocks you placed on others stay; blocks others placed on you stay too.
A provisional record — an address and a stand-in name — is kept indefinitely, including one made by entering an address on the sign-in form and never using the code. Ask us and we will remove one.
Sign-in codes live ten minutes. Assistant access tokens live one hour and are refreshed while the connection is in use. Briefing links live thirty days, with a sixty-day grace for email replies, and are removed after that. What we keep of a removed link is a one-way hash of it and the two accounts it connected, for as long as the correspondence, so that its unsubscribe keeps working; the hash cannot open anything.
Logs, the request log, the database audit log and telemetry, thirty days. Backups, fourteen days; a deletion reaches the last backup within that time.
Deleted notebook entries, thirty days. Archived forwarded mail, ninety days. Conversations with the assistant we host, ninety days after the last message.
A document you delete privately, thirty days, the same undo window as a notebook entry. One withdrawn from every briefing it was sent on, or belonging to a closed account, its bytes within about a day. The storage platform itself keeps a soft-deleted copy recoverable against accidental loss for a further seven to fourteen days beyond that, depending on the environment.
Support requests and everything said on them, until one year after the last message on a request we have closed; a request still open is kept until it is closed, so that a problem which comes back can be read against what happened last time. The diagnostics your browser reported go with the request and are deleted with it. Ask us and we will delete a request sooner.
Correspondence with us about a request or a complaint, for as long as we might need to show what was asked and answered, and in any case no longer than the law requires us to keep it.

What you can do

Take a copy: your account page exports your account, all of your correspondence including briefings other people sent you, your contacts, your notebook, your shared memory, mail forwarded to you, your conversations with the assistant we host and your security record, as a file you keep. Ask us for anything it leaves out, such as your support requests.
Correct your name on your account page. Your address is your identity here and changes by writing to us.
Disconnect an assistant from your connections page, at any moment, without the assistant's cooperation.
Stop a sender with the unsubscribe link in a briefing notification or a contact request — whether or not you have an account — or with the block on any thread. Blocking is silent. Neither link expires.
Close your account from your account page. It asks you to type your address, because it cannot be undone. Take your export first: once the account is closed, we can no longer tell which records were yours.
Ask us anything at the address above: to confirm what we hold about you, to correct it, to delete it, to receive a copy in a portable form, to restrict or object to how we use it, or to withdraw consent you gave. These rights are available to everyone, wherever you live.

How a request works

Write to hello@relaylink.ai from the address on your account, or sign in and use the export and closure controls, which act at once. For a request by email we will confirm it by sending a code to the account address, because the address is the only identity we hold; we will not ask for anything more. We answer within thirty days, and within forty-five where a law allows it and the request is complex, in which case we will say so. There is no charge unless a request is plainly excessive, and we will never treat you differently for making one. Somebody you authorise may ask on your behalf if they can show that you authorised them.

If we refuse

If we decline a request in whole or in part we will say why, in writing. You can appeal by replying to that answer within sixty days; a different person will look at it and reply within forty-five days. If you are still not satisfied you can complain to the authority where you live. For a Virginia resident that is the Office of the Attorney General of Virginia; for other US states, that state's attorney general; in the EEA, your national data protection authority; in the UK, the Information Commissioner's Office.

Residents of Virginia and other US states

Several US states, Virginia among them, give residents rights over personal data once a business handles enough of it. We are below those thresholds today and we honour the rights anyway, for everyone: the rights listed above, and the right to opt out of the sale of personal data, of targeted advertising and of profiling. We do none of those three, so there is nothing to opt out of, and a “Do Not Track” or Global Privacy Control signal from your browser changes nothing because nothing tracks. We have not sold or shared personal data in the twelve months before the date at the top of this page. If you are a California resident, the rights and the appeal route above are the ones California law gives, under the names it uses.

If you are in the EEA, the UK or Switzerland

The rights above are the ones the GDPR and the UK GDPR give, and the legal bases are set out in their own section. You also have the right to lodge a complaint with your supervisory authority; writing to us first usually resolves it faster.

How we protect it

Everything travels over HTTPS. Sign-in is by emailed code, so there is no password to steal. Keys and sign-in codes are stored as hashes; the links in emails are long random tokens, and once a briefing link is removed only a hash of it is kept, for its unsubscribe. Assistant access is by OAuth tokens that you can revoke. Content from other people is rendered so it cannot run as code: the pages that show it run no script except our own served file, and the page a briefing link opens runs none. The database accepts no passwords at all: the service and its deployment pipeline authenticate as identities, and the only firewall rule admits nothing without one. The security page says more, and says how to report a weakness.

If something goes wrong

If a breach of security affects your personal data, we will tell you without unreasonable delay once we have confirmed it and know enough to say what happened, by email to your account address, and we will notify the authorities the law requires, including under Virginia's breach notification law and, where it applies, within the seventy-two hours the GDPR sets.

Children

RelayLink is not directed at children under 16 and we do not knowingly hold their data. A briefing addressed to a child's email is the sender's act, not ours; if you believe we hold a child's data, write to us and we will delete it.

Changes to this policy

When this page changes materially we will email account holders at least thirty days before the change takes effect, and the date at the top always says when it was last revised. The current version is the one at this address, and every policy that applies to the service is listed at relaylink.ai/legal.