Legal
This Privacy Policy explains what personal information ReplyLayer collects, how it is used, and the choices available to users.
Effective date: July 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 may use de-identified or anonymized message samples to evaluate and improve our security screening rules, such as testing prompt-injection and safety-detection performance. We do not use your Customer Content to train third-party foundational AI models.
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. No primary inference is performed by a third-party model provider.
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. We do not currently share personal information for cross-context behavioral advertising.
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.
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.computeDiffendpoint. 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.quarantinedwebhook, 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.
We do not currently describe any behavioral advertising cookie program because the Service is not built around third-party advertising.
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 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].