simail内测中
EN
登录加入等候名单

安全

默认安全

simail 怎样保护你的 agent、收件人和信誉,以及发现问题时怎么报告。

01

收信侧

信在门口收下,检查完,才交给 agent。

所有通道都扣留
被扣留的信在 REST、MCP、webhook、事件和 WebSocket 上都只返回元数据,直到有人放行。主题、正文和附件一律不给。
提示注入扫描
用确定性规则检查指令句式、隐藏文字和零宽字符、伪造的系统提示、超长编码块,中英文都覆盖。收信路径上不跑语言模型。
默认不可信
每封信都带标记为不可信的信任信封;MCP 把正文包在 <untrusted_email> 里,让 agent 分清数据和指令。
HTML 放进沙箱
HTML 只在另一个不设 cookie 的独立域名上的沙箱框架里显示,脚本关闭,远程图片默认拦截,由你决定是否加载。
附件走隔离域
下载用一次性签名链接,5 分钟内有效。
被扣留的信,agent 拿到什么
{
  "message_id": "msg_…4127",
  "thread_id": "thr_…",
  "from": "accounts@northwlnd-supply.example",
  "timestamp": "2026-10-18T09:19:00Z",
  "size": 18342,
  "labels": ["held"],
  "hold_reasons": ["injection_suspected"],
  "held": true
}

示例数据 所有通道都不给主题、正文和附件。

02

发信侧

每封信发出前都要过确定性检查,真正发出前再查一次。

必须带幂等键
不带 Idempotency-Key 的发信请求会被拒绝。用同一个键重试,返回第一次的结果。
防重复、防死循环
24 小时内给同一收件人发同样的正文会被拒绝。回复自动回信、失控的来回对话都会被拦下。
内容检查
空正文、没填的占位符(如 {{name}})、卡号、抑制名单里的地址、信头注入,都在发出前拦下。
审批绑定内容
策略要求审批时,审批人能看到全部收件人、标红片段和内容哈希。内容一改,原来的批准就失效。
只有一个服务能发信
面向 agent 的服务不持有任何发信凭据。只有放行服务能发信,而且要先过最终检查。

一封回信的发送前检查

draft_…
  • sender_mismatch通过
  • empty_body通过
  • placeholder通过
  • card_number通过
  • suppressed通过
  • duplicate通过
  • first_contact已标记

策略要求时,标记项会转入审批。

03

人在回路

人随时可以介入,agent 也会被明确告知。

接管锁
给线程上锁。agent 发信会收到 423 thread_locked,并被告知停下、通知它的主人。
只有人能做的事
放行扣留的信、批准发信、建密钥和 webhook、放宽黑名单,都在控制台里由人完成。agent 会收到 403 human_required。
重新验证
敏感操作需要 5 分钟内的 passkey 或新的邮箱验证码。
接管期间,agent 拿到什么
HTTP/1.1 423 Locked
Content-Type: application/problem+json

{
  "code": "thread_locked",
  "status": 423,
  "retryable": false,
  "fix": "A human has taken over this thread; wait until it is unlocked."
}

04

可追溯

每个重要动作都按顺序记下来,并且可以校验。

哈希链审计日志
每一行都包含上一行的哈希,缺一行或改一行,链就断了。
只写不透明 ID
审计行里账户、密钥、组织都只写 ID,从不写邮箱地址、邮件内容、验证码或密钥。

审计链,最近几行

链完整
  1. 09:58:55session.step_up546d…6399 → bb5e…11bc
  2. 09:51:31message.releasec2ef…d1bf → 546d…6399
  3. 09:39:01api_key.createdf60…3874 → c2ef…d1bf
  4. 09:27:27thread.lockb442…0a0c → df60…3874

示例数据 示例行 · 链已校验

05

平台

防止损害扩散的控制。

熔断
7 天内(至少 50 封)硬退信率达到 2% 或投诉率达到 0.1%,该组织的发信会暂停,控制台写明原因。由人来恢复。
全局停发
一个开关暂停所有外发邮件,收信照常。每月演练。
密钥只能收窄
API 密钥的作用域是组织、一组邮箱或单个邮箱,并带明确的权限。
运行时不持有平台凭据
运行中的服务不持有任何基础设施账号凭据。

平台控制

熔断
7 天内硬退信 2% 或投诉 0.1%
恢复
由人操作,需重新验证
停发演练
每月
密钥作用域
组织 › 邮箱组 › 邮箱

06

安全政策

草稿 · 待律师审阅simail.ai · 最后更新 2026-10-18

Draft, pending attorney review (草稿,待律师审阅). The disclosure terms below are not yet in effect.

以下法律文本目前只有英文草稿,以英文为准;中文版会在律师审阅后提供。

simail is in private beta. We do not hold security certifications yet; this page describes what we actually do.

How simail is built

  • Separated services. Agent access, the human console and outbound sending are separate services. Only the release service can send mail; agent-facing services hold no mail-sending credential. Agents cannot approve sends, release held mail, create keys or webhooks, or loosen block lists.
  • Pre-send checks run on every outbound message, and again right before it leaves: sender ownership, recipient limits, duplicate and loop protection, suppression of bounced addresses, header-injection rejection, and optional human approval bound to the exact content.
  • Inbound checks before storage. Messages are classified and screened (spam, auto-replies, prompt-injection heuristics) before an agent can read them; suspicious mail is held and shown as metadata only. Email content is labeled as untrusted for agents.
  • Isolated content. Message HTML, attachments and raw files are never served from simail.ai. They are served from a separate, cookie-less domain (view.siagentmail.com) through single-use links that expire in minutes, with a strict content security policy, and HTML is shown only in a sandboxed frame with scripts disabled.
  • Tenant isolation. Every stored object is bound to an organization; objects outside a key’s scope are reported as not found. Addresses are never reassigned to another organization.
  • Credentials. API keys, invite codes, sign-in codes and claim tokens are stored only as keyed hashes. Webhook secrets are encrypted. Console sign-in uses email codes or passkeys with secure, host-only cookies; sensitive actions require fresh re-verification.
  • No platform tokens at runtime. Running services hold no Cloudflare account credentials.
  • Audit log. Security-relevant actions are written to an append-only, hash-chained audit log that contains opaque IDs only.
  • Signed webhooks follow the Standard Webhooks specification.
  • Encryption in transit (TLS) and at rest (Cloudflare).
  • No training on customer content. Cloudflare, our infrastructure subprocessor, automatically scans email content for spam, malware and abuse; see Subprocessors.

Reporting a vulnerability

Email security@simail.ai with a description, steps to reproduce and the affected host. Our security.txt is at /.well-known/security.txt. We aim to acknowledge reports within [3 business days, to be confirmed].

In scope: simail.ai, api.simail.ai, app.simail.ai, docs.simail.ai, view.siagentmail.com, simailservice.com, and mail handling for simail mail domains.

Please:

  • Use only accounts and inboxes you own, and stop at the minimum needed to show the issue.
  • Do not access, change or delete other people’s data; if you reach it by accident, stop and tell us.
  • Do not send mail to people who did not agree to receive it, and do not run denial-of-service, spam or social-engineering tests.
  • Give us reasonable time to fix the issue before disclosing it.

Safe harbor. [Counsel to draft: authorization for good-faith research that follows these rules, and our commitment not to pursue legal action against it.]

There is no paid bug bounty during the beta.

Contact

security@simail.ai · abuse@simail.ai · privacy@simail.ai · simail.ai