Legal

Privacy Policy

This Privacy Policy explains what personal information ReplyLayer collects, how it is used, and the choices available to users.

Effective date: May 7, 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.

1. Scope and roles

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.

2. Information we collect

We collect information in a few categories.

  • Account and profile information: email address, password hash, Google or GitHub sign-in identifier if you choose third-party authentication, account status, tier, trust level, and related account metadata.
  • Mailbox and message data: mailbox names and addresses, message metadata, sender and recipient addresses, subjects, message bodies, sanitized message bodies for safe display, attachment metadata, raw MIME, delivery events, suppression data, and quarantine or safety review results.
  • Authentication and security data: session identifiers, API key metadata, MFA status, recovery-code metadata, login attempts, IP addresses, device and request logs, and audit records relating to content access or administrative actions.
  • Safety-check audit data: request identifiers, AI model and policy information, hashes of scanned inputs, limited content previews with personal information removed, locations of detected items, safety-check results, and related records used to troubleshoot, evaluate, and secure safety checks.
  • Usage and operational data: message counts, delivery and complaint rates, rate-limit events, trust-history events, safety-check outcomes, and similar telemetry needed to run and protect the Service.
  • Support and communications data: information you send to us in support emails, procurement requests, or other communications.
  • Billing and payment data: if paid plans are enabled, we and our payment processor may collect billing contact data, subscription status, invoices, and payment-related records. We do not intend to store full payment card numbers in ReplyLayer systems.

3. Sources of information

We collect information:

  • directly from you when you sign up, authenticate, create mailboxes, manage recipients, request support, or use the dashboard or API;
  • from your use of the Service, including message processing, authentication, security, and delivery events;
  • from third parties you choose to use with us, such as Google or GitHub sign-in; and
  • from infrastructure and delivery providers that process traffic for the Service, such as email delivery and hosting providers.

4. How we use personal information

We use personal information to:

  • provide, operate, maintain, and secure the Service;
  • create and manage accounts, mailboxes, sessions, API keys, and authentication flows;
  • receive, route, sanitize, store, display, and transmit email and related metadata;
  • screen inbound and outbound content for prompt-injection, policy, security, safety, deliverability, and abuse risks;
  • enforce quotas, sandbox limits, recipient verification, rate limits, circuit breakers, and other protective controls;
  • monitor usage, troubleshoot issues, investigate incidents, prevent fraud, and protect users, recipients, and infrastructure;
  • communicate with you about your account, support issues, product changes, or legal notices;
  • comply with law, enforce our agreements, and respond to legal process; and
  • improve the Service, including through internal analytics and de-identified or aggregated analysis.

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.

5. Safety scanning and automated processing

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 (Granite Guardian 4.1, Qwen 3.6 35B, and Gemma 4 31B, all self-hosted). Outbound messages flagged by our spam scanner are reviewed by our self-hosted models to generate operator-facing abuse-alert summaries. Cross-vendor fallback to xAI Grok engages only when one of our self-hosted models — including the spam-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 spam review, the subject and a brief body excerpt of the flagged outbound message) is processed by xAI Grok. No primary inference traffic is sent to third parties.

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.

6. How we share information

We may share personal information in the following circumstances:

  • Service providers and subprocessors: including hosting, database, object storage, DNS, email delivery, identity, and model providers that help us operate the Service.
  • At your direction: for example, when you choose Google or GitHub sign-in or configure your own domains and workflows.
  • Legal and safety reasons: when we believe disclosure is necessary to comply with law, enforce our agreements, respond to lawful requests, protect rights or safety, or investigate abuse.
  • Corporate transactions: in connection with a merger, financing, reorganization, asset sale, or similar transaction, subject to appropriate confidentiality protections.

We do not sell personal information for money. We do not currently share personal information for cross-context behavioral advertising.

7. Current subprocessors and providers

The Service currently relies on subprocessors and providers in categories such as:

  • Mailgun (Sinch) for email delivery, inbound receipt, and event handling. Mailgun handles customer email content and related metadata.
  • Cloudflare for DNS, edge protection, and Cloudflare object storage (R2). Cloudflare handles raw email storage and related operational data, including safety-check audit records.
  • xAI as a cross-vendor fallback for content scanning, appeal review, and spam-review/abuse-alert summarization — engaged only when the corresponding self-hosted model is unhealthy, unavailable, or at capacity. During such a fallback, xAI receives the content of the affected request.
  • Google if you choose Google-based sign-in. In that case, Google handles authentication data but does not receive your customer email content through ReplyLayer.
  • GitHub (Microsoft) if you choose GitHub-based sign-in. In that case, GitHub handles authentication data but does not receive your customer email content through ReplyLayer.
  • Railway for application and database hosting. Railway hosts account data and application data, but is not used as a separate email-content scanning provider.
  • attachmentAV (widdix GmbH) for inbound email attachment virus and malware scanning. Attachment file content is transmitted to the attachmentAV scanning API for analysis; scanning results are returned and stored by ReplyLayer. attachmentAV does not retain customer attachment content after scanning.
  • Google (Web Risk) for inbound URL reputation checks. Only SHA-256 hash prefixes of URLs from inbound messages are transmitted to Google Web Risk on local-hash collisions (roughly the first 4 bytes of the hash). Full URLs and full hashes are never sent in plaintext. See the dedicated URL-reputation section below for the complete data-flow and imperfection disclosure.
  • Stripe for payment processing, subscription billing, invoicing, and tax calculation. Stripe handles payment instrument data (card last-4, expiration, billing address, tax ID), subscription state, and invoice/receipt records. Stripe does not receive or process Customer email content; it only receives the billing email associated with your ReplyLayer account plus the data you submit during Checkout or in the Stripe billing portal.

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.

7a. URL reputation (Google Web Risk)

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. Google’s own Web Risk privacy practices govern any data they log on their side.

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 activated per account only after you have explicitly acknowledged this disclosure through signup, CLI acknowledgement, or admin backfill. Accounts that signed up before this section was added will not have URL reputation enabled until they re-accept or are backfilled.

8. Cookies and similar technologies

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.

9. Data retention

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.

  • Account and mailbox records: retained while your account is active and then according to our deletion and backup schedules.
  • Message content and raw MIME: retained according to the product retention settings and account tier. The business design currently targets default message retention windows such as 30 days for sandbox, 90 days for starter, 1 year for professional, and 2 years for enterprise, subject to change as the product matures or customer settings differ.
  • Account deletion flow: deleted accounts enter a 30-day grace period before permanent deletion, unless legal hold or another valid exception applies.
  • Backups and infrastructure logs: some deleted data may remain temporarily in encrypted backups or provider logs until the applicable retention window expires. Railway PostgreSQL backups currently have a 7-day retention window.
  • Safety-check audit records: records from safety checks and related quality-control reviews are retained for a limited period, currently targeted at no more than 90 days, unless legal hold, incident response, abuse investigation, litigation, or another valid preservation basis applies. Account-linked safety-check audit records are included in account-deletion workflows to the extent they can be linked to the account.
  • Administrative and content-access audit records: certain database audit and content-access records may be retained longer for abuse prevention, legal compliance, and security investigation, including where those records no longer identify a person directly after account purge.
  • Legal hold and preservation: we may suspend standard deletion timelines and retain personal information beyond normal retention periods when required by law, subpoena, regulatory demand, dispute resolution, law enforcement request, active litigation, or an internal legal hold placed by ReplyLayer or by you through the customer-facing Legal Hold feature where available on your plan. Data subject to a legal hold will be retained until the hold is released, even if you request deletion or close your account.

10. Security

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), logs all access through application and database controls, 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.

11. International transfers

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 that require a data processing agreement, those transfer terms are addressed in the applicable DPA and incorporated transfer provisions.

12. Your rights and choices

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.

You can currently exercise certain rights through the Service or by contacting us, including:

  • downloading an account export from the dashboard;
  • requesting self-service account deletion from the dashboard;
  • updating certain account information directly in your account; and
  • contacting us for additional privacy requests or questions.

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.

13. Children's privacy

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.

14. Changes to this Privacy Policy

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. Your continued use of the Service after the updated Privacy Policy becomes effective means the updated version applies to your use, to the extent permitted by law.

15. Contact us

Questions or requests about this Privacy Policy can be sent to [email protected].