Security controls for agent email

Every inbound message is scanned before it's marked safe for your agent, in two layers: fast deterministic rules plus a model guardrail across seven 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.

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.

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.

Attachments are virus-scanned, and file types are checked from their contents where the format can be recognised, not just from the name the sender gave. A message carrying a virus is not delivered, and by default neither is one carrying a blocked file type such as an executable, script or archive. By default your agent sees an attachment's name, type and scan result, not the file; text previews and raw downloads are opt-in and depend on your plan. 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.

Yes, on inbound mail. Links in the subject and body are checked against lists of known malicious sites, and a message with a match is held for review; the model layer can't soften that result. Link checks are on by default for new accounts, older accounts can turn them on, and they can be turned off per mailbox. If the lists can't be checked, the message proceeds with a warning instead of being held; links beyond the first 64 in a message aren't checked, and the message carries a warning. Inbound HTML is also cleaned before your agent reads it: scripts and remote images such as tracking pixels are removed, and hidden text used to show filters one thing and readers another is flagged.

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.

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.

No. ReplyLayer decrypts message content server-side so it can scan and deliver email. Data uses TLS in transit and provider-managed encryption at rest; selected secrets and message subjects also use application-layer AES-256-GCM encryption under managed keys.

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.

No. We do not use your email (message content, attachments, or metadata, including anything that reaches us through the API, CLI, MCP server, or integrations such as our Cursor plugin) to train or fine-tune AI models, ours or anyone else's, and we do not build training or evaluation datasets from it. Our safety scanning runs AI models on each message to decide whether to hold it. That is inference: your messages are not used to change the models. We develop and test our screening with synthetic messages, public datasets, and our own test mail. Our AI model provider processes your email 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 connect an AI assistant such as Claude or ChatGPT to a mailbox, its provider receives the email the assistant asks for and handles it under your own agreement with that provider, which may allow training depending on your plan and settings (Privacy Policy Section 6). The authoritative statement is in our Privacy Policy.

We're precise about this, because “encrypted” can mean very different things:

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.

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.

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.

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.

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.

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.

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.

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.

Scanning can miss threats or flag legitimate content, so treat inbound email as untrusted data even after a clean scan and review held messages before acting. ReplyLayer decrypts content server-side to operate the service, processes customer data in the United States, and does not currently hold SOC 2, ISO 27001, PCI DSS, or HIPAA certification. The answers above describe each limit in context.

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, except when an attachment carries a virus or a blocked file type; outbound mail is an action taken on your behalf, so that's where a hard stop is appropriate.

No. ReplyLayer does not currently hold SOC 2, ISO 27001, PCI DSS, or HIPAA certification. If one of those attestations is an adoption requirement, the product does not meet it today.

Review the Privacy Policy, DPA, Terms, and Acceptable Use Policy. The Privacy Policy contains the maintained sub-processor list.

Email [email protected] before performing any testing. Include a description, reproduction steps, and impact. The Acceptable Use Policy prohibits unauthorized security testing.