Skip to content
multi.ai.inbox™
Menu

Security

Built for untrusted input

Email is the easiest way to reach an agent, which makes it the easiest way to attack one. This page describes the controls that exist in the product today.

Gatekeeper: prompt injection screening

  • Every inbound message is screened before an agent should act on it. The result is stored on the message as a verdict, clear or review, with a score and the reasons.
  • The rules are transparent: instruction overrides ("ignore previous instructions"), role hijacking, requests to send credentials or forward all mail, fake tool or system markup, text hidden with CSS, invisible Unicode characters, and a failing DMARC result.
  • Screen before notify is on by default: inbound mail is held until the verdict exists, so message.received never reaches your agent before screening finishes.
  • Messages with verdict review get the review label, stay hidden from every list and read, and fire only the message.security.review event, without the body. A human with a release permission decides; each release is audited.
  • When the screener is down or slow, the hold fails closed: the message waits for review instead of being delivered unscreened.
  • The screener also extracts the new text of a reply without quoted history, which shrinks the attack surface the model reads.
  • Screening reduces risk; it does not remove it. Keep sensitive actions behind a confirmation step in your agent.

Tenant isolation with row level security

  • Every tenant table carries the organization id and has Postgres row level security enabled and forced.
  • The application connects with a role that is not a superuser, so the policies apply to every query, including bugs.
  • The end to end test suite tries to read another organization's data and must fail.

API keys, permissions and audit log

  • Keys are random, shown once, and stored only as SHA-256 hashes.
  • Keys can be scoped to a list of permissions and given an expiry date. A key can never grant permissions it does not hold, and revocation is immediate.
  • MCP tools check the same permissions as the REST endpoints, so a scoped key also limits what a coding agent can do.
  • Security relevant actions, including agent actions through MCP, are written to an audit log you can read through the API.
  • The fixed mai_live_ prefix makes leaked keys easy to detect with secret scanners.
  • Repeated failed authentications from the same address are throttled.

Signed webhooks and SSRF protection

  • Every delivery is signed with HMAC SHA-256 following the Standard Webhooks scheme, with a per webhook whsec_ secret and a timestamp checked within 5 minutes.
  • Webhook URLs must use HTTPS. Connections to private, loopback, link local and unspecified addresses are refused when the socket opens, after DNS resolution, so DNS tricks do not reach internal services.
  • Redirects are not followed and each attempt times out after 15 seconds.

Email authentication

  • Outbound mail is DKIM signed. Each custom domain gets its own key; SPF and DMARC records are part of domain verification.
  • Inbound mail is checked for a DKIM signature aligned with the From domain, and the result is exposed on every message.
  • Inbound mail is scored by a spam filter. Clear spam is rejected during the SMTP session; suspected spam is kept with the spam label.
  • Mail to unknown recipients is refused at the SMTP RCPT stage, so the platform does not accept mail it cannot deliver.

Abuse prevention

  • Daily and monthly send limits per plan, a footer on the free plan, and a cap of 50 recipients per message.
  • Cold outreach and unsolicited bulk mail are forbidden by the terms. Accounts that send it are suspended.
  • Per organization API rate limits.

EU hosting

  • Application servers, the database and stored mail run on Hetzner Online GmbH infrastructure in Germany.
  • Nightly database backups go to Hetzner Object Storage in the EU.
  • Outbound mail to external recipients is currently relayed by Brevo (France). Mail between inboxes on the platform does not leave it.
  • The API is served over TLS with certificates from Let's Encrypt, and the SMTP server offers STARTTLS.

Compliance status

We do not hold SOC 2, ISO 27001 or any other certification today, and we will not claim one until an audit is complete. The service is in staging and offers no uptime commitment yet. Data protection is described in the privacy policy (draft).

Responsible disclosure

If you find a vulnerability, write to security@aimulti.inbox with the steps to reproduce it. Please:

  • test only against accounts and data you own;
  • do not send spam, run denial of service tests or access other customers' mail;
  • give us reasonable time to fix the issue before you publish it.

We will acknowledge your report, keep you informed and credit you if you wish. We do not run a paid bug bounty yet.