Legal
This Privacy Policy explains what personal information ReplyLayer collects, how it is used, and the choices available to users.
Effective date: September 27, 2026
This Privacy Policy explains how ReplyLayer LLC ("ReplyLayer," "we," "us," or "our") collects, uses, shares, and retains personal information when you use our websites, API, CLI, MCP integrations, dashboard, and related services.
ReplyLayer is a bring-your-own-agent email layer. That means we process both account-level information about our customers and operational email data that customers send through the Service for their own agents and workflows.
This Privacy Policy applies to personal information we process in connection with the Service, including our website, signup flow, authentication, dashboard, APIs, email routing, safety screening, support, billing, and security operations.
For account registration, billing, security, support, and product administration, ReplyLayer LLC acts as the business responsible for deciding how that information is used. For customer email content and related message data processed on behalf of an account owner, ReplyLayer generally acts as a service provider or processor, while the account owner controls the underlying mailbox workflow and recipient relationships.
We collect information in a few categories.
We collect information:
We use personal information to:
We do not use your data to train AI models. ReplyLayer does not use, or license others to use, Customer Content or your account information to train or fine-tune any artificial-intelligence or machine-learning model, whether ours or a third party's, except as you direct when you connect an AI assistant (Section 6). Section 8 describes the limited identifiers we share for advertising measurement; they are not Customer Content, and we do not use them to train models. Customer Content means the content, attachments, and metadata of the messages you send and receive through the Service, including anything that reaches us through the API, CLI, MCP server, or integrations such as our Cursor plugin. We also do not build training or evaluation datasets from that data, including from the safety-check audit records described in Section 5. We develop and test our safety screening with synthetic messages, publicly available datasets, and our own test mail. If you ask us to investigate how a specific message was handled, we use it only for that investigation. Scanning a message with an AI model, as described in Section 5, is inference: the model analyzes the message to return a result, and we do not use the message to change the model. Our AI model provider processes it under zero data retention and may not use it to train its models. Our email delivery providers receive message content under contract terms that limit their use of it to providing and securing their email service.
If you are in a jurisdiction that requires a legal basis for processing, we generally rely on contractual necessity, legitimate interests, legal obligations, and, where applicable, your consent. Your signup acknowledgement of this Privacy Policy records that this disclosure was presented to you; it is not consent to every processing activity described here. Where consent is the legal basis for a specific feature, we collect that consent separately, in a way you can refuse and withdraw.
ReplyLayer uses automated systems to help detect prompt injection, jailbreak attempts, confidentiality leakage, harassment, toxic content, secrets, delivery risk, reply loops, and other operational or security issues. These checks can result in warnings, quarantine, blocking, suppression, or other workflow outcomes.
To perform those checks, message content and related metadata may be processed by our own systems and by third-party AI model or infrastructure providers. Automated outputs assist platform operation, but they are not perfect and may be reviewed, appealed, or overridden in accordance with product controls and our internal policies.
Primary content scanning runs on our own infrastructure, using multiple independent open-weight AI models we host and operate ourselves. Outbound messages flagged by our abuse-prevention and sender-reputation controls may be reviewed by our self-hosted models to generate operator-facing abuse-alert summaries. Cross-vendor fallback to xAI engages only when one of our self-hosted models — including the flagged-message abuse-review model — is unhealthy, unavailable, or unable to accept a request due to capacity or backpressure; during such a fallback, the content of the affected request (for flagged outbound message review, the subject and a brief body excerpt of the affected outbound message) is processed by xAI.
Appeal review is different, and is not a fallback. When our own scanners flag a message, that message may undergo a second-opinion re-check — an "appeal" — to determine whether the flag was a false alarm. This appeal review is performed by xAI as the primary provider for that step, so whenever an appeal runs, the content of the flagged message is sent to xAI. A model we host ourselves serves as the fallback if xAI is unavailable. Appeals only ever examine messages our own scanners have already flagged; they are not run against ordinary message traffic.
For quality assurance, security review, appeals, and troubleshooting, certain safety checks may create audit records containing input hashes, limited text previews with personal information removed, locations of detected items, safety-check results, and related operational metadata. These records are not intended to store raw email bodies, but they may include limited Customer Content or model-generated text that quotes Customer Content. They are subject to the retention, deletion, access-control, and legal-hold rules described in this Policy and the DPA.
We also remove or mask sensitive personal information before sending text to certain model providers. If ReplyLayer offers redaction or tokenization modes for a mailbox or plan, message content may also be redacted or tokenized before it is delivered to your agent.
We may share personal information in the following circumstances:
We do not sell personal information for money. Our use of the OpenAI advertising measurement described in Section 8 may be considered “sharing” personal information for cross-context behavioral advertising under some U.S. state privacy laws. You can opt out of it with the “Opt out of website measurement” control described in Section 8.
The Service currently relies on subprocessors and providers in categories such as:
Our provider list may change over time as the Service evolves. Updated subprocessor information may appear in the dashboard, our legal materials, or by request.
Website analytics: where enabled, Plausible Analytics processes the limited website measurements described in Section 8 on our behalf. ReplyLayer determines this website-improvement purpose as controller, and Plausible acts as our website-analytics processor. This integration does not send account identities, signup form contents, or Customer email content to Plausible. It is separate from the customer-service subprocessors listed in DPA Annex 3.
Advertising measurement: OpenAI processes the limited browser and conversion measurements described in Section 8 so we can attribute registrations and purchases to ads shown in ChatGPT. This measurement is separate from the customer-service subprocessors listed in DPA Annex 3 and never includes Customer email content.
ReplyLayer scans URLs in inbound messages against Google Web Risk to flag known phishing, malware, and unwanted-software destinations before they reach your agent or dashboard.
What is sent to Google. ReplyLayer downloads Google’s Web Risk threat lists (hash-prefix databases) through Google’s threatLists.computeDiff endpoint. Customer URLs stay in ReplyLayer; they are never transmitted to Google in plaintext. On a local hash-prefix collision we call Google’s hashes.search endpoint with the hash prefix only (typically the first 4 bytes of the SHA-256) to confirm or rule out the match. The full URL and the full hash are never sent to Google. Hash prefixes we submit to the Web Risk API are Customer Data processed by Google as ReplyLayer’s processor or subprocessor, according to the roles described below, under Google Cloud’s data-processing terms and the transfer terms referenced in Section 11; service data that Google generates independently about the operation of its own service is governed by Google’s own terms.
Protection is imperfect. URL reputation is powered by Google Web Risk. Web Risk may miss some threats (false negatives) and may occasionally flag legitimate URLs (false positives). Reputation data also carries a Google-dictated lifetime: once a match expires, ReplyLayer stops showing the Google-attributed warning. You should always review flagged messages before acting on them, and treat unflagged links with normal caution.
Attribution. When ReplyLayer surfaces a URL-reputation warning on the dashboard or in a message.quarantined webhook, we link to Google’s Web Risk Advisory and to threat-class-specific learn-more pages (for example, anti-phishing.org for social-engineering flags). These attribution links are Web Risk’s and are kept distinct from any links in your message content.
Activation. URL reputation is active by default for new accounts. This section, together with the inline notice on signup surfaces that render one, is the disclosure that supports that default. Your signup acknowledgement of this Privacy Policy records that the disclosure was presented to you; URL-reputation scanning does not rely on your consent (see the legal-basis paragraph below). Accounts created before this section existed are not activated by default — they enable it from your dashboard Settings → Malicious link scanning (or rly account link-scanning enable), or by admin backfill, in each case after acknowledging a Privacy Policy version that includes this section. You can turn URL reputation off for any mailbox at any time from that mailbox’s scanner settings (Mailboxes → What content is checked). Turning it off is a change of your configuration instructions to us, not a withdrawal of consent.
Legal basis and roles. Where ReplyLayer scans URLs in messages processed on a customer’s behalf, ReplyLayer acts as that customer’s processor or subprocessor, and Google acts as a ReplyLayer subprocessor for these lookups (see Section 7 and DPA Annex 3); the customer remains responsible for its own lawful basis and instructions. Where ReplyLayer independently determines this security purpose, ReplyLayer relies on its legitimate interests (GDPR Article 6(1)(f) or the UK equivalent) in protecting the Service, our network, agents, customers, and recipients from phishing, malware, and related security threats; for that processing, ReplyLayer acts as the controller and Google acts as ReplyLayer’s processor. We treat transmitted hash prefixes as potentially personal or pseudonymized Customer Data — not guaranteed-anonymous data — and they are covered by the international-transfer terms in Section 11 and the DPA.
We use essential cookies and similar technologies needed to operate the dashboard and authentication flows. For example, the dashboard uses an HTTP-only session cookie to keep you signed in securely.
If you choose Google or GitHub sign-in, those providers may place or read their own cookies as part of the authentication flow, subject to their own privacy practices.
Where enabled, we use cookieless Plausible analytics on selected public pages of replylayer.ai and the signup page on app.replylayer.ai to understand which pages visitors read and whether they follow signup or GitHub links. Analytics do not run on login, dashboard, account, or message pages. We send the public page address, approved campaign tags, and only the hostname of an external referring site. Other query parameters and fragments are removed. We do not send form values, account identifiers, message content, or link contents, and do not join these measurements to your account or payments.
Your browser contacts Plausible directly, so Plausible receives its network IP address and User-Agent. Plausible states that it uses these to derive device and approximate location statistics and a daily identifier, discards the raw IP address and User-Agent, and rotates and deletes the identifier salt daily. It processes website analytics in the EU. See Plausible's data policy. We use these aggregate measurements to improve our website, relying on our legitimate interests in that purpose where applicable. Plausible does not use analytics cookies or persistent visitor identifiers, and we do not use session replay.
We also use the OpenAI Ads Measurement Pixel and Conversions API on our website and app to record completed registrations, paid subscriptions, and credit purchases that may be attributable to an ad shown in ChatGPT. OpenAI receives the page URL, event name and event identifier, event data, browser IP address and User-Agent, and OpenAI click or browser references stored in first-party cookies. Registration and paid-conversion server events may include SHA-256 hashes of the normalized account email address and internal account identifier to improve matching; we do not send those values in raw form. We do not pass phone numbers, message content, or raw payment details in our event calls. If automatic advanced matching is enabled for the Pixel, OpenAI may detect supported contact information in recognizable forms, normalize and SHA-256 hash it in the browser, and send only the hash with conversion events. We use these measurements to understand and improve advertising performance.
From September 22 to 23, 2026, we used the AppLovin Pixel on replylayer.ai and on the signup and account-verification pages of app.replylayer.ai (/signup, /signup/continue, /verify-email and /verify-phone) to measure advertising. It sent AppLovin page views, plan views and plan choices, and completed registrations, together with the page URL, browser IP address and User-Agent, AppLovin browser identifiers stored in first-party cookies, and device and browser characteristics such as graphics hardware, canvas rendering, and time zone. We no longer use the AppLovin Pixel, and we never sent AppLovin checkout or purchase events. Cookies AppLovin set in your browser may remain until they expire; we do not read them. For more information about AppLovin's collection and use of your information visit: https://legal.applovin.com/privacy/.
You can use the visible “Opt out of website measurement” control on measured public pages and on the signup page. It saves a preference in your browser's local storage and synchronizes an equivalent first-party cookie so server-side conversion measurement honors the same choice. The preference applies separately to each browser and origin: set it on both replylayer.ai and app.replylayer.ai if you visit both. Clearing site storage removes the saved preference. If your browser cannot save it, the control still stops future collection for the current page and tells you the preference is temporary. For a signed-in account, opting out also asks ReplyLayer to suppress outstanding paid-conversion records that have not been sent; an anonymous browser cannot update account-owned records, and opting back in does not resurrect a suppressed purchase. Events blocked while the preference is off are not replayed later. Browser measurement requires JavaScript; server conversion events can still be sent when you complete an account or purchase action unless the measurement opt-out cookie is set or the authenticated suppression request has completed. Opting out does not affect signup or use of the Service.
We retain personal information for as long as needed to provide the Service, meet legal obligations, resolve disputes, enforce our agreements, and protect the platform.
We use administrative, technical, and organizational safeguards designed to protect personal information, including access controls, encrypted transport for public endpoints, encrypted storage provided by our infrastructure vendors, authentication controls, append-only audit logging for certain events, and safe-view defaults for dashboard message access.
Internal access to customer content is governed by our internal access policy, which limits operator access to enumerated permitted reasons (customer support, abuse investigation, legal hold, security-incident response, or engineering troubleshooting with explicit customer consent), requires operator access to be recorded through application-level access logging, append-only audit records, or documented manual records for direct infrastructure access, and is reviewed monthly. A summary of the policy is available on request.
No system is perfectly secure. We do not guarantee absolute security, and you remain responsible for protecting your own credentials, devices, agents, and downstream systems.
ReplyLayer currently processes and stores customer data in the United States. We do not currently offer EU or other region-specific data residency, data localization, or regional isolation for customer email content, metadata, or account information.
If you access the Service from outside the United States or submit personal information that is subject to non-U.S. data protection laws, your information will be transferred to and processed in the United States. Those transfers may involve laws that differ from the laws of your jurisdiction.
Where required, we rely on appropriate transfer mechanisms, such as contractual protections and standard contractual clauses made available by us or our subprocessors. For customers on our standard Data Processing Agreement, restricted transfers follow the DPA's Annex 4 framework, which requires a party-specific completed and signed SCC record before a covered transfer begins; a separately negotiated agreement addresses transfers according to its own terms.
Depending on where you live, you may have rights to access, correct, delete, export, or restrict certain personal information, or to object to certain processing.
Where we process personal information as an independent controller on legitimate-interests grounds — for example the security scanning described in Section 7a — you may object by contacting us. We will stop that processing for you unless we have compelling legitimate grounds that override your interests, rights, and freedoms, and we will tell you our decision. This objection right is separate from the per-mailbox scanning controls a customer can configure.
You can currently exercise certain rights through the Service or by contacting us, including:
We may need to verify your identity before fulfilling a request. If you are an end recipient whose data was processed through a customer's mailbox workflow, you may need to contact the relevant account owner first because they control that relationship in most cases.
Certain rights, including the right to deletion or erasure, may be limited or suspended where we are required to retain information due to a legal obligation, active dispute, law enforcement request, litigation hold, regulatory demand, or other valid legal basis for continued retention. If a legal hold or preservation obligation applies to your data, we will retain the relevant information until the obligation is resolved, even if you request erasure. We will comply with your request to the extent we are legally able, and will inform you if a legal exception applies unless we are prohibited from doing so by law or legal process.
The Service is for adults 18 and over. The Service is not directed to children under 13, and we do not knowingly collect personal information from children under 13. If you believe a child has provided personal information to us, contact us and we will take appropriate steps to review and delete the information if required.
We may update this Privacy Policy from time to time. If we make a material change, we will provide notice by updating the effective date and, where appropriate, by email, in-product notice, or other reasonable means. An updated Privacy Policy describes our practices from its effective date, and continued use after that date means the updated description applies to your use. Continued use alone does not replace consent, a new customer instruction, or renewed contractual assent where one of those is legally required for a specific processing activity or feature.
Questions or requests about this Privacy Policy can be sent to [email protected].