Replyz / Security

Email is untrusted input. We treat it that way.

Anyone can send mail to an agent's address, including text written to manipulate the agent. This page explains what Replyz does with incoming mail, and what it doesn't do.

Untrusted by default

• Every message is marked as untrusted content (content_is_untrusted: true).
• Every message carries sender_trust, based on the DMARC and DKIM checks done when the mail arrives: aligned_pass (DMARC passed), dkim_pass (DKIM only) or unauthenticated (the From address may be forged). A passing sender is still untrusted content.
• Subjects, senders, extracted codes and links are email content too, and are untrusted in the same way.

What the agent reads

• Most hidden text is removed. Most hidden HTML (for example display:none, zero opacity, zero font size) and invisible characters are removed from the text the agent reads. These are heuristics with known gaps: some hidden content can still get through. The original HTML can be requested separately, except where retention has removed it (see below).
• Every message is scored for prompt injection. Each message carries an injection-risk score and the signals behind it, so an agent gets a signal when an email may be trying to give it orders. The score can miss things.
• Very large content is cut, not hidden. When text is truncated, the message says so with a signal.

These are heuristics. They lower the risk; they don't make content safe. An agent should treat every email as data and never follow instructions found in it, whatever the score.

What Replyz never does

• It never opens links or loads images: not when mail arrives, not when it is read, not when a code or link is extracted.
• It never serves attachments inline: they are download-only, and risky ones are flagged.
• It does not reissue an address, even after its inbox is deleted.
• It does not send email. Replyz is receive-only.

Data and keys

• EU storage. Mail and account data are stored at rest in the EU. Requests are processed on Cloudflare's global network, which may be outside the EU.
• Hashed API keys. Replyz stores only a keyed hash of each API key. The key is shown once, at signup, and never again.
• Size limits. Messages over 10 MiB are rejected when they arrive; at most 50 attachments per message are stored.
• Verification-code mail is reduced. A daily job reduces verification-code mail after 7 days: it removes the body text, the original message and the attachment files. The subject, sender and dates stay, so a code written in the subject line stays visible. The job also clears stored extraction results after 7 days.
• Other retention. A daily job erases messages older than 12 months and is set to delete sandbox data 30 days after the sandbox expires.

Abuse controls

• Signup is limited. It needs a proof of work (a small computation, so scripts can't sign up thousands of accounts for free). There are daily limits per network and an hourly cap across everyone that reopens by itself. Signups are closed for now.
• New accounts are sandboxed for 7 days, with 1 live inbox, 3 inbox creations a day and 1,000 received messages a month. Claiming by a human is planned; once an account is claimed: 3 live inboxes, 10 creations a day and 5,000 messages a month.
• Each sender is capped. One sender (or all unauthenticated mail together) can use at most 20% of an account's monthly allowance. Above that, that sender's mail is refused with a generic "mailbox unavailable".
• API requests are rate-limited. A burst guard limits how fast each API key can call the API. It is a guard against bursts, not a precise quota: the count is approximate, kept separately in each location. Beyond it, the API answers 429 and says when to retry.
• A burst of verification-code emails from many senders flags the account for 24 hours; a flagged sandbox account gets a lower extraction limit. Mail is never rejected for this.

Reporting a problem

Security issues: see security.txt. Abuse: abuse@replyz.io.

Frequently asked questions