SECURITY
Publicly discoverable. Privately operable.
FineMail publishes product and protocol descriptions for discovery while keeping mailbox data, agent identities, and write operations behind owner authentication and explicit scopes.
Trust boundary
FineMail's public surface contains documentation, schemas, protocol metadata, and product descriptions. The unified inbox, agent inboxes, message details, metrics, and domain state require an authenticated Fine Structure account. Public crawlers cannot retrieve account mailbox content from the public pages.
Private console routes also publish an X-Robots-Tag: noindex, nofollow, noarchive response header. This indexing control complements authentication; it is not used as an access-control mechanism.
Owner isolation
FineMail resolves inboxes and messages in the context of the authenticated account owner. Message retrieval and updates include owner checks, and sending requires an agent identity belonging to that owner. A caller cannot select another account's mailbox by supplying its ID.
FineMail addresses are unique in the configured domain. Address changes preserve identity routing while preventing two current agents from claiming the same address.
API tokens and scopes
External clients use Fine Structure MCP/API bearer tokens. The security pipeline validates the token before dispatching any FineMail tool and enforces the required email scope.
| Scope | Allows | Does not allow |
|---|---|---|
email:read | List inboxes, search messages, and retrieve one owned message. | Send mail or change message state. |
email:write | Send from an owned identity and change read/archive state. | Access mail owned by another account. |
Treat bearer tokens like passwords. Keep them server-side, grant only required scopes, and revoke or rotate them if exposed.
Provider credentials and inbound events
Sending credentials, inbound-routing secrets, and signing material stay on the server. FineMail's UI may report whether an email path is configured, but it does not return those credentials to the browser or public discovery endpoints.
Inbound email is accepted through the configured provider integration and routed to the matching FineMail identity. Provider events are validated by the backend before they become owner-visible mailbox records.
Read and write actions
FineMail separates observational operations from side effects. Listing inboxes and reading mail require read permission. Sending, archiving, restoring, or changing read state require write permission. Agent clients should confirm user intent before a send and report the delivery state returned by FineMail without overstating it.
Web transport controls
The public deployment uses HTTPS and sends transport and content-security response headers at the edge. API requests stay on the first-party FineMail host and are proxied to the authenticated backend. Private routes are excluded from search indexing, while the documented public HTML and machine-readable files remain indexable.
Security questions
For account or security support, use the authenticated Fine Structure support channel. Do not include API tokens, provider credentials, or private message content in a public report.