# Vibosome Mailroom security and trust boundary

This document summarizes the current invite-only, single-owner Mailroom beta. It is a product boundary statement, not a certification, penetration-test report, uptime commitment, or guarantee that email content is accurate or safe.

## Hosted access

- Cognito self-registration is disabled.
- The deployment admits one exact, verified owner email.
- Software-token MFA is required.
- Public Caddy owns ports 80 and 443. oauth2-proxy, the application, and the API remain behind the authenticated proxy chain.
- Browser-supplied identity and private proxy headers are removed or replaced at the relevant boundaries.
- Non-read browser requests require the exact trusted origin before body parsing.

## Credentials and secrets

- Mailbox credentials remain in the control plane and are never returned to the browser.
- The single-owner deployment persists the active mailbox credential as an AES-256-GCM authenticated record on encrypted storage.
- The credential key is separate from the stored record.
- Missing keys, wrong keys, corrupt records, unsafe file types or permissions, and conflicting environment credentials fail startup closed.
- Runtime infrastructure uses an EC2 instance role and Secrets Manager rather than embedded AWS access keys.

## AI boundary

- Mailroom uses narrow typed OpenAI Responses tools, not shell or unrestricted mailbox access.
- Relevant message text, bounded search results, correlated Sent-mail excerpts, and the working profile may be included only for an owner-requested task.
- Mailbox credentials, full mailbox dumps, attachment bytes, and signature-logo bytes are not sent to the model.
- Requests use application-managed replay with `store:false`.
- Message content is untrusted data and cannot grant permissions, change the profile, or bypass approvals.

## External and destructive actions

- Sending, forwarding, moving, and deleting create immutable proposals.
- The owner reviews the exact action before execution.
- AI reply tools create editable drafts but cannot approve or send them.
- Draft revisions and approval claims use conditional checks to prevent a stale view from executing unseen content.
- Ambiguous SMTP delivery is not automatically retried.
- Forward, move, and delete proposals are bound to the originating mailbox identity.

## Attachments, exports, and signatures

- Attachment paths and file names are normalized and constrained to the private artifact area.
- Image previews are bounded and limited to supported raster types.
- Signature HTML is rendered by the server from escaped facts and allowlisted style tokens.
- Signature revisions and logo hashes are frozen into the reviewed proposal.
- Logo assets are decoded, stripped, resized, normalized, stored privately, and kept out of model input.

## Infrastructure operations

- The production image is pinned by immutable ECR digest.
- Releases require automated tests, type checks, production dependency audit, container startup smokes, and zero HIGH/CRITICAL ECR scan findings.
- The data disk is encrypted and retained.
- CloudWatch monitors instance status, CPU credits, memory, swap, root disk, data disk, and end-to-end service health.
- The account has a monthly cost guardrail.
- The deployment is intentionally one instance in one Availability Zone and can experience maintenance downtime.

## Limitations before multi-user production

The current data model and execution claims are not tenant-partitioned. A safe multi-owner service requires tenant-scoped transactional PostgreSQL, private object storage, a durable queue/outbox, transactional delivery claims, dynamic tenant credential protection, shared rate limits, tenant-aware authorization, and a complete audit/retention policy.

Do not add a second owner, API replica, or concurrent worker host to the current runtime and represent it as multi-tenant safe.

Report vulnerabilities through <https://vibosome.com/security/disclosure>. Do not use destructive testing or include live secrets, mailbox content, or personal data in a report.