Security
Email is the most hostile input your agent will ever read
ReplyLayer scans every message before your agent sees it, holds anything it can't safely judge instead of delivering it, and is honest about exactly where the line is. Primary scanning runs on independent models we host on our own GPUs (not a third-party model API), your normal app traffic is isolated per-tenant at the database, and we decrypt content server-side to do the scanning that protects your agent — so we're not end-to-end encrypted, and we say so plainly. The questions below are the ones agent builders and their security reviewers actually ask; with links to our legal package for the contractual substance. ReplyLayer is a REST API, CLI, MCP server, and SDKs for AI agents to send and receive transactional and operational email — not bulk or marketing mail.
Protecting your agent
How do you stop a malicious email from hijacking my agent?
Every inbound message is scanned before it's marked safe for your agent, in two layers: fast deterministic rules plus a model guardrail across nine inbound criteria. Primary scanning runs on multiple independent open-weight models we host on our own GPUs, reached over a restricted, authenticated, IP-allowlisted channel that isn't publicly accessible. A third-party model is engaged in two narrow cases: as a cross-vendor fallback when our self-hosted models can't serve a scan, and as a second-opinion review of messages our own models have already flagged — a false-positive check before we hold your mail. Importantly, scanning reduces injection risk but doesn't neutralize it. A clean verdict is not a trust verdict.
What should my agent actually do with inbound email?
Treat the body of every inbound message as untrusted data, not as a command. Display it, summarize it, extract from it — but have your agent confirm before acting on any instruction a message contains, and route flagged or held messages to human review. Scanning is a strong filter in front of your agent; it is not a substitute for your agent being skeptical of what strangers send it.
Can I stop my agent from emailing the wrong people, or getting stuck in a reply loop?
Yes — several controls you can compose. Per-mailbox recipient allowlists constrain who an agent can send to; account-wide do-not-contact suppressions are enforced before send; reply-loop limits stop runaway agent-to-agent or autoresponder reply storms; and you can require review on a mailbox so every outbound message is held before it goes out — clean messages enter an approval queue that agent keys cannot approve. Scoped agent API keys fail to zero access — never to broad access — if the mailboxes they were bound to are removed. Every release of held mail is a deliberate, attributable decision: each one writes an append-only audit record of who released it and why, and approval-queue and held-draft releases require a dashboard session or admin key.
How are untrusted attachments handled?
PDF and Office files are parsed in a sandboxed, internal-only worker running under a least-privilege role that can't reach the rest of the platform. The parser runs with XML external-entity and entity-expansion attacks disabled — the classic XXE and billion-laughs class. Isolation is per-job with memory caps and wall-clock cancellation, so a malformed or malicious file degrades to a failed preview rather than affecting anything else. Inbound image-exfiltration risk is surfaced as a warning or holds the message for review; the hard block for that risk is outbound-only.
What happens if your scanner is down?
The core safety scan fails closed: if the semantic scan or the attachment malware check errors, times out, or can't reach a verdict, the message is held for review — not delivered or sent. If our self-hosted models are temporarily unavailable, an independent fallback model takes over. Some non-core advisory checks may degrade to warnings instead of holding mail. Nothing is delivered without the core scan.
What happens when a legitimate message gets held by mistake?
Held and flagged messages go to a review queue, not the void — you, or a human reviewer you designate, can inspect and release them. A release is never silent: every one writes an append-only audit record of who acted and why. A held outbound draft re-sent through the normal send path is re-scanned in full at send time; the explicit “send anyway” override requires a dashboard session or admin key and records the original safety-check finding alongside the override. Because scanning has false positives, we recommend routing flagged mail to human review rather than auto-discarding it.
Your data
Is my email end-to-end encrypted? Can ReplyLayer read my email?
No, it is not end-to-end encrypted — and yes, we decrypt content server-side. We have to: a guardrail that can't read a message can't scan it for the threats that are the whole point of the product. If you need a provider that genuinely cannot read your content, ReplyLayer is honestly not that provider, and we'd rather tell you here than let you find out later. What we do have: TLS in transit, provider-managed encryption at rest for stored email and attachments, plus application-layer field encryption (AES-256-GCM under managed, KMS-wrapped keys) on specific secrets and message subjects.
Can your staff read my email?
We decrypt content server-side to scan and operate the service, so it is technically accessible to the systems that run ReplyLayer — we're not a zero-access provider, as noted above. Access to customer content is restricted to the systems and personnel that operate the service, governed by an internal access policy that limits operator access to enumerated reasons, and access to our systems is recorded in append-only, tamper-resistant logs. We are not end-to-end encrypted, so if your requirement is that no one at the provider can ever read your content, ReplyLayer cannot meet that bar today. See our Privacy Policy.
Do you use my email to train AI models?
We do not use your content to train third-party foundational AI models. We may use de-identified or anonymized message samples to evaluate and improve our own safety-screening rules — for example, testing how well we catch prompt injection — but that is our internal detection tuning, not training of a third party's general-purpose model on your mail. The authoritative statement, including the legal basis, is in our Privacy Policy.
What exactly is encrypted?
We're precise about this, because “encrypted” can mean very different things:
| What | Protection |
|---|---|
| In transit | TLS |
| Stored email and attachments | Provider-managed encryption at rest |
| Specific secrets and message subjects | Application-layer AES-256-GCM, with managed keys rotated without downtime |
| Message content overall | Not end-to-end encrypted — we decrypt server-side to scan and operate the service |
| Audit and access logs | Append-only and tamper-resistant (this covers the logs, not raw email storage) |
Is my data isolated from other customers?
Yes for the application path. Tenant isolation is enforced at the database with row-level security, enforced again in application code, and verified by an automated test suite — one customer's normal requests can't reach another customer's data. One caveat: named background and worker roles (the workers that process inbound mail, run scans, and deliver webhooks) run outside row-level filtering by design, because they need to act across the system to do their jobs. So the accurate claim is that your normal app traffic is isolated per customer and that isolation is tested — not that no role can ever cross tenants. The role that parses untrusted attachment content is narrowed to a minimal, column-scoped database slice; the main pipeline role necessarily has broad access to do its job — it isn't reachable from any customer-facing surface, and even it cannot modify the append-only audit logs.
Where is my data processed? Do you offer EU or regional residency?
Processing is United States only today. We do not currently offer EU or other regional data residency, localization, or regional isolation for customer email, metadata, or account data. If your obligations require regional residency, this is a hard constraint today, not a roadmap footnote. See our Privacy Policy.
Does any of my data ever leave your systems?
For inbound URL-reputation checks, only short hashed prefixes of a link are sent to an external provider — never the full URLs and never your message content. The provider receives enough to answer a reputation query and nothing more. Beyond that, the third parties that handle your data are disclosed in our Privacy Policy sub-processor list.
Which sub-processors touch my email?
The full, maintained sub-processor list — covering hosting, database, object storage, DNS, email delivery, identity, payments, attachment malware scanning, URL reputation, and the scanning fallback — is published in our Privacy Policy and in the DPA annex. We link to it rather than restate it here. Note that a third-party model provider is listed because it's engaged as a cross-vendor fallback when our self-hosted models can't serve a scan, and as a second-opinion review of already-flagged messages — not as the primary scanner for your mail.
Your controls
Do you support MFA and scoped access for my team and agents?
Two auth paths. People sign in to the dashboard with optional TOTP multi-factor authentication. Agents, CLI, and MCP authenticate with API keys that come in two roles: account-wide admin keys, and agent keys bound to specific mailboxes with scoping enforced on every request — an agent key fails to zero access, never to broad access, if the mailboxes it was scoped to are removed. That's the safe default for a credential living inside an autonomous agent.
Can I suspend an account or key immediately if something goes wrong?
Yes — account suspension takes effect immediately on both paths. API-key requests are checked against the account's database status plus a fast in-memory kill-switch; dashboard sessions are enforced by the database check; both fail safe to the database check if the in-memory store is unavailable.
Are your webhooks safe to receive?
Each customer webhook is signed with a per-endpoint HMAC secret so you can verify it genuinely came from ReplyLayer (our SDKs include verification). Webhook delivery is hardened against being tricked into calling internal or private addresses — a common attack class known as SSRF — and we re-check the destination at send time so a destination swapped after validation is caught again. Personal information can be redacted before an event leaves our systems — a per-mailbox setting — and inbound provider events are signature-verified before we act on them.
Can I delete or export my data?
Yes to both. Account deletion is two-stage: a reversible soft-delete, then a permanent purge after a 30-day grace window — the grace exists so an accidental or hostile deletion can be recovered before data is gone. The purge permanently removes your stored email and the associated processing records across our systems and sub-processors, and removes your domain/DNS configuration at our providers. Self-service export gives you a structured snapshot of your account records — mailboxes, message metadata, recipients, and configuration — beforehand; message content itself remains retrievable through the API until the purge runs. A few caveats worth naming: an anonymized deletion record is retained where required by law, some data may persist briefly in encrypted backups, and an active legal hold can pause deletion timelines. See our Privacy Policy.
Operations & limits
What does ReplyLayer NOT do? What are the limits?
We treat this as a feature — a posture you can trust is one whose author will also tell you where it stops. Scanning is imperfect: it has both false positives (clean mail flagged) and false negatives (bad mail passed), so review flagged messages and don't assume an unflagged message is safe. A clean verdict is not a trust verdict — treat inbound email as untrusted data even on a clean scan. We are not end-to-end encrypted — we decrypt content server-side to scan it and operate the service. Processing is US-only today — no EU or regional data residency. Your normal app traffic is isolated per customer and that isolation is tested, but the named background workers that run scans and deliver mail operate across the system by design, so we don't claim no role can ever cross tenants. And we don't hold a SOC 2, ISO 27001, PCI DSS, or HIPAA certification yet — and we don't claim one.
What gets blocked, what gets warned, and what gets held?
How ReplyLayer responds depends on what the scan finds. The inbound/outbound asymmetry is deliberate: inbound mail is data you should be able to see and judge, so we lean toward holding for review; outbound mail is an action taken on your behalf, so that's where a hard stop is appropriate.
| Situation | What ReplyLayer does |
|---|---|
| The core safety scan can't reach a verdict (error or timeout) | Held for review (fails closed) |
| The guardrail flags an inbound attack signal (injection, jailbreak, risky function call) | Held for review |
| The guardrail flags an inbound content-safety signal | Delivered with a warning |
| A deterministic check fires (attachment integrity, URL reputation) | Authoritative — not softened by the model layer |
| Inbound image-exfiltration risk | Warned, or held for review — never silently delivered |
| Outbound image-exfiltration risk | Blocked before it leaves your mailbox |
| A non-core advisory check is unavailable | The message may proceed with a warning instead of being held |
Compliance & contact
Do you have SOC 2, ISO 27001, PCI, or HIPAA?
No — ReplyLayer does not currently hold SOC 2, ISO 27001, PCI DSS, or HIPAA certification, and we don't claim one. The controls described on this page are real and in code, but they have not been attested under a third-party audit framework yet. We'll publish an attestation if and when we complete one. If a certification is a hard adoption requirement for you, we don't have one today and won't imply otherwise.
What compliance documentation can I review?
Our contract-grade legal package is published and maintained: the Privacy Policy (with the full sub-processor list), the DPA, the Terms, and the Acceptable Use Policy. Together with this page, that's the evidence we can put in front of a reviewer today — our honest stand-in for a trust portal we haven't stood up.
How do I report a security issue, and can I test ReplyLayer myself?
Email [email protected] with a description, reproduction steps, and impact. Be aware of the boundary: we don't currently run a published vulnerability-disclosure program or offer safe-harbor terms, and our Acceptable Use Policy prohibits unsanctioned testing — so please don't access, modify, or exfiltrate other customers' data, or run anything that degrades the service. Reach out before probing anything. This is a deliberate current-state boundary for a small vendor, not an oversight.