simailPrivate beta
中文
Sign inJoin the waitlist

Security

Safe by default

What simail does to protect your agents, your recipients and your reputation, and how to report a problem.

01

Inbound

Mail is accepted at the door, checked, and only then handed to your agent.

Holds on every channel
A held message returns metadata only on REST, MCP, webhooks, events and WebSocket until a person releases it. Subject, body and attachments are withheld.
Prompt-injection scan
Deterministic checks for instruction phrasing, hidden and zero-width text, fake system prompts and long encoded blobs, in English and Chinese. No language model runs on the receiving path.
Untrusted by design
Every message carries a trust envelope marked untrusted, and MCP wraps bodies in <untrusted_email> so agents can tell data from instructions.
HTML in a sandbox
HTML is shown only in a sandboxed frame on a separate, cookie-less domain, with scripts off and remote images blocked until you choose.
Attachments on an isolated domain
Downloads use single-use signed links that expire in 5 minutes.
What an agent gets for a held message
{
  "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
}

Sample data Subject, body and attachments are withheld on every channel.

02

Outbound

Every send passes deterministic checks before it can leave, and again right before it does.

Idempotency required
Send calls without an Idempotency-Key are rejected. Retrying with the same key returns the first result.
Duplicates and loops
The same body to the same recipient within 24 hours is refused. Replies to auto-responders and runaway threads are stopped.
Content checks
Empty bodies, unfilled placeholders like {{name}}, card numbers, suppressed addresses and header injection are caught before sending.
Approval bound to the content
When a policy asks for approval, approvers see every recipient, flagged spans and a content hash. If the content changes, the approval no longer applies.
One service can send
Agent-facing services hold no mail-sending credential. Only the release service sends, after the final check.

Pre-send checks on a reply

draft_…
  • sender_mismatchpass
  • empty_bodypass
  • placeholderpass
  • card_numberpass
  • suppressedpass
  • duplicatepass
  • first_contactflagged

Flags go to approval when the policy asks for it.

03

Human in the loop

People can always step in, and agents are told clearly when they have.

Takeover locks
Lock a thread. Agent sends get 423 thread_locked with a message to stop and tell their human.
Human-only actions
Releasing held mail, approving sends, creating keys and webhooks, and loosening block lists happen in the console. Agents get 403 human_required.
Fresh re-verification
Sensitive actions need a passkey or a new email code from the last 5 minutes.
What an agent gets during a takeover
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

Traceability

Every action that matters is written down, in order, and can be verified.

Hash-chained audit log
Each row includes the hash of the previous one, so a missing or edited row breaks the chain.
Opaque IDs only
Audit rows name accounts, keys and organizations by ID. They never contain email addresses, message content, codes or secrets.

Audit chain, latest rows

Chain intact
  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

Sample data Sample rows · chain verified

05

Platform

Controls that stop damage from spreading.

Breakers
If hard bounces reach 2% or complaints 0.1% over 7 days (after 50 messages), sending pauses for the organization and the console says why. A person resumes it.
Global send halt
One switch pauses all outbound mail. Inbound keeps working. Drilled monthly.
Keys only narrow
API keys are scoped to an organization, a group of inboxes or one inbox, with explicit permissions.
No platform credentials at runtime
Running services hold no infrastructure account credentials.

Platform controls

Breaker
2% hard bounces or 0.1% complaints / 7 days
Resuming
A person, after re-verification
Halt drill
Monthly
Key scopes
organization › inbox group › inbox

06

Security policy

Draft · pending attorney reviewsimail.ai · last updated 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