Security

Security and responsible disclosure

RelayLink's one guarantee is that nothing somebody sends you can act as you. This page says how the service is built to keep that promise, and how to tell us when you find a way through it. Last updated 19 September 2026.

How it is built

  • Nothing sends itself. A briefing to somebody else leaves only through a confirmation step that is separate from the draft, and an assistant is instructed to take it only on its user’s explicit approval. The server cannot see that approval, only that the step was taken; on the portal’s review page a person approves it themselves. Two things are kept in one step because they reach nobody new: a handoff to yourself, and a fact you share on a project, which only that project’s members see.
  • Other people's words are text, never instructions. Content from a sender is HTML-encoded on the way to every web page, and no page that renders it runs any script except our own served file; the page a briefing link opens runs none at all. Before it reaches an assistant or an email it is neutralised so that it reads as text and cannot be mistaken for a command.
  • No passwords. Sign-in is a single-use emailed code, stored as a keyed hash and valid for ten minutes. Both sides of the sign-in are padded to the same response time so that the form cannot be used to learn whether an address has an account.
  • Credentials are hashed, revocable and yours. API keys are generated from a cryptographic random source, stored as SHA-256 hashes, and can be named, revoked and replaced by their owner at any moment. Assistants hold OAuth 2.1 tokens with PKCE, short-lived access tokens, and a connections page from which a person can revoke an assistant without its cooperation.
  • Consent gates every send. A briefing reaches an account holder only through a contact request they accepted, a request link they published, or a conversation they are already in, checked on every send, not only the first. Blocks are symmetric and never announced: nobody is told when they are blocked, although a later send to the person who blocked them is refused.
  • Shared memory is the one place an assistant writes what another reads. It is off until the account holder switches it on, and by default an assistant may keep a fact only when its user asks. Every fact is one line of plain text of at most a thousand characters, flattened at write and at read so it cannot forge another line, framed to every assistant as information about the user rather than an instruction, never copied into a briefing by the service, and visible and deletable on the account page.
  • Asking for help does not open a door. The support form is ours, with no help-desk or chat-widget company behind it. What your browser reports with a request is bounded on the server rather than by the page that offers it — three kinds of event, a capped number of them, no stack traces, no page content, no request bodies — and every web address in one has its query string removed and any identifier or token in its path replaced, so a link to somebody’s correspondence cannot reach a support record. You are shown exactly what is attached before you send it. A reply arriving by email is matched by the address it was sent to and can never change where we answer or authorise anything about an account.
  • A link is never proof of reading. The application records nothing about who opened a briefing link and never shows the sender that it was opened, because link scanners open links before people do. Our hosting platform’s request log does record the address, browser and path of every request, briefing links included, for thirty days, for diagnosing faults and investigating abuse.
  • Links are capabilities, and bounded. The token in a briefing link, a request link or a forwarding address is a long random value, stored as issued so the service can recognise it. A briefing link opens the briefing for thirty days and accepts an emailed reply for sixty more. Then its token is removed, and what is kept is a one-way hash of it with the two accounts it connected: enough for the link to go on stopping the sender, and nothing it could open.
  • The database takes no passwords. The service and the deployment pipeline authenticate to Azure SQL as identities; there is no SQL login to leak. Secrets live in Azure Key Vault. Production and the sandbox have separate databases, database servers, vaults, telemetry and email domains, and share one application hosting plan. Database auditing records the statements that run against each database, kept thirty days.
  • Transport and storage. Everything is served over TLS with HTTP Strict Transport Security, and everything stored is encrypted at rest — Azure SQL, Azure Storage and Key Vault encrypt stored data with Microsoft-managed keys, the databases using Transparent Data Encryption, and the database connection itself requires TLS 1.2 or better. That is not end-to-end encryption, and this page does not claim it: the service reads your correspondence in order to render, send and search it. Every page carries a Content Security Policy: the public pages and the account pages each allow one first-party script, and the page a briefing link opens allows none.
  • A document you attach is checked, held privately, and never opened by us. A briefing can carry a plain-text or Markdown file, stored in a private Azure Storage account — a separate one per environment, no public access, no shared key or signed link, reachable only by the service’s own identity. Every upload is checked for well-formed text before it is readable; nothing else is scanned for malicious content in this version, which is why the accepted formats are limited to plain text and Markdown rather than anything that could carry executable content of its own. It stays private until you send it, readable then only by whoever the briefing reaches, never rendered as anything but text, and retired within a day of being withdrawn or the account closing; a document you delete is held for thirty days before its bytes are removed for good, the same undo window the rest of an account gets.
  • Sign-ins and credential changes leave a record. Every sign-in attempt on an account, application connected or disconnected, and key created or revoked is recorded with the address it came from and kept ninety days, so a compromised account can be investigated. You can read your own on your account page. Nothing about reading, sending or replying is recorded that way.
  • Application logs cannot become a credential store. They are tested never to contain recipient addresses, link tokens or keys, and the framework’s own debug logging of tokens is capped in code, so raising a log level cannot expose them. The platform request log above is the exception, which is why it lives in the same restricted workspace and is kept only thirty days.
  • Every change is tested before it merges. Code, infrastructure and database changes go through version control, an automated test suite, template validation and a dependency vulnerability audit before they can merge, and are deployed by a pipeline. A setting applied by hand during an incident is written into the templates afterwards.

Reporting a vulnerability

If you have found a weakness in RelayLink, we want to hear about it, and we would rather hear from you than from anyone else. Write to hello@relaylink.ai with “Security” in the subject line. A machine-readable pointer to this page is at /.well-known/security.txt. Tell us what you found, how to reproduce it, and what you think it lets somebody do. If you need to send something sensitive, say so first and we will arrange an encrypted channel.

What we promise

  • We will acknowledge your report within three business days, and tell you what we make of it within ten.
  • We will keep you informed as we fix it, and tell you when it is fixed.
  • We will credit you by name, or not, as you prefer, when we describe the fix.
  • We will not take legal action against you, or refer you to law enforcement, for research that follows the rules below. We consider such research authorised under the Computer Fraud and Abuse Act and the Virginia Computer Crimes Act, and exempt from the anti-circumvention provisions of the Digital Millennium Copyright Act, and we will not claim otherwise. If a third party starts legal action against you for it, we will make clear that you acted with our authorisation.
  • We do not run a paid bounty programme today. If that changes, this page will say so.

What we ask

  • Test only against accounts you own or have been given for the purpose. Do not read, change or delete another person's data; if you find you can, stop, note enough to prove it, and report it.
  • Do not send briefings to people who have not agreed to receive them, even to prove a point. Two test accounts of your own can correspond with each other.
  • No denial of service, no load testing, no spam, no social engineering of the people who run the service or of its providers, and no physical attacks.
  • Do not test the third-party services we use — Azure, Mailgun, Cloudflare, GitHub, OpenAI, Google — under this policy; each has its own.
  • Give us a reasonable time to fix what you found before you describe it publicly. We ask for ninety days from your report, and we will ask for more only if the fix genuinely needs it, and say why.
  • Do not exploit a finding beyond what is needed to demonstrate it, and destroy any data you obtained once you have reported it.

Scope

In scope: relaylink.ai and everything served under it, including the MCP endpoint, the authorization server, the account portal, the briefing links and the email that the service sends and receives. Out of scope: the services above, the assistants people connect, anything found by automated scanning alone with no demonstrated impact, missing best-practice headers with no exploit, and reports about the rate limits being generous, which they are on purpose.

If something goes wrong

If a security event affects your personal data we will tell you as the privacy policy says, and a business customer under the data processing addendum within forty-eight hours of our becoming aware. We keep a record of every incident and what we changed because of it.

Contact

hello@relaylink.ai — the only channel we take reports on. PillarStack LLC is in Richmond, Virginia, United States. The whole set of policies is listed at relaylink.ai/legal.