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 5 September 2026.

How it is built

  • Nothing sends itself. A briefing leaves only after a person approves it, and the approval is a separate step from the draft. The interface an assistant uses cannot skip it.
  • Other people's words are text, never instructions. Content from a sender is HTML-encoded on the way to every web page, and every page that renders it forbids scripts entirely. 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, checked on every send, not only the first. Blocks are symmetric and silent, and a blocked sender learns nothing.
  • Nothing about you is learned from a link. Opening a briefing link records no address, device or browser, and is never shown to the sender as proof of reading, because link scanners open links before people do.
  • 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 are separate resource groups, databases, vaults and email domains.
  • Transport. Everything is served over TLS with HTTP Strict Transport Security. Every page carries a Content Security Policy; the marketing pages allow one first-party script and the pages that show correspondence allow none.
  • Logs cannot become a credential store. Application logs 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.
  • Every change is reviewed and tested. Code, infrastructure and database changes go through version control, review, an automated test suite and a dependency vulnerability audit before they are deployed by a pipeline. Nobody deploys by hand.

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 — 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, or by post to PillarStack LLC, 406 Shafer St, Richmond, VA 23220, United States. The whole set of policies is listed at relaylink.ai/legal.