// security.md
Security model
In short
Layer 1Getting mail in
- The service holds no credential to your mailbox. It cannot read it, send from it, or change its settings.
- It receives mail delivered to your alias, including manual forwards, automatic forwards and direct messages. It cannot fetch other mail from your inbox.
- Your alias is randomly generated. Anyone who learns it can deliver mail to it.
- Senders are not authenticated. A sender name or From address can be forged; treat all email as untrusted.
Layer 2Letting an agent read it
- An agent credential is bound to one address and has no tool that sends or deletes mail.
- Your own address is replaced with the alias before an agent reads a message.
- A sender address can be forged, so treat everything an agent reads as untrusted input.
- Stored content is encrypted under per-address keys and is readable by the running service. It is not end-to-end encrypted.
- Deleting an address destroys the external keys its content was stored under.
The sections below are the operative description. This list is a reading aid.
1.Scope
This document describes the security properties of the service as implemented in V1. The service sits between your mailbox and an agent, so it has two boundaries: what reaches the service at all, and what an agent may do with what arrived. The sections below follow that order.
It describes current behaviour rather than granting a warranty. Where a property is an engineering target rather than a recorded result, that is stated. Properties the service does not provide are listed under known limits.
2.Account access
Sign-in establishes identity only. The service requests the openid, email and profile scopes from the identity provider and requests no mailbox permission.
It holds no credential that would let it read your mailbox, send on your behalf, or change your mail settings. Mailbox access is not requested, granted or stored.
3.What the service receives
The service receives messages delivered to the alias it issues you. Mail reaches that alias because you configured a forwarding rule in your own mail provider, because you forwarded a message by hand, or because someone sent directly to the alias.
Mail you do not forward is not transmitted to the service. Changing or removing the forwarding rule stops delivery at the source.
4.Sender handling and trust
Manual forwards, automatic forwards and direct messages to an active alias are available to its agent, subject to plan limits and retention. Gmail setup confirmations are handled separately and hidden from agents.
The service does not authenticate inbound senders. A From address can be forged, and a message may not have come from the person it names.
An alias is a delivery address, not an authentication secret. Anyone who knows it can send mail that your agent may read.
All agent-visible content is treated as untrusted input.
5.Address masking
Before an agent reads a message, your own address is replaced with the alias wherever it appears: message headers, sender and recipient fields, subject, message identifiers, body text and attachment filenames.
Masking is pattern-based. It does not identify an address that has been obfuscated or embedded in an image.
6.Storage and encryption
Message content and attachments are encrypted before storage under keys scoped to a single address.
The running service can decrypt content to answer an authorised request. This is not end-to-end encryption, and the service is not designed to be unable to read stored content.
7.Agent access
Agent access uses MCP. Each credential is bound to one address and cannot reach another address on the account.
The tool surface is read and draft only. There is no tool that sends a message or deletes a stored message. Results are capped, and access is recorded in an access log.
8.Retention and deletion
Each address carries an explicit retention period within the limit of its plan, and expiry is automatic.
Deleting an address destroys the external content keys under which its messages were stored. Deletion timing across backups is covered under known limits.
9.Known limits
These are properties the current implementation does not provide. They are listed so they are not assumed.
- 9.1An alias can leak once it is shared or forwarded; it is a selection boundary, not a secret.
- 9.2Malicious prompt-injection text can still arrive in a delivered message.
- 9.3Address masking is pattern-based and cannot identify every obfuscated or image-embedded address.
- 9.4Attachments are stored within size limits; V1 does not claim malware scanning.
- 9.5Deletion timing remains an engineering target until the backup restore-and-shred exercise is recorded.
10.Reporting
Report a suspected vulnerability to support@eml.ai with the affected surface, the steps to reproduce it, and any request identifiers. Do not include another person’s message content.