Answered before you ask.

The scopes we refuse.

RocketMail requests gmail.modify on Gmail and Mail.ReadWrite on Microsoft Graph. That is the smallest scope that allows the product to do its job. It is not gmail.readonly, because RocketMail archives and labels, and it is not full access, because full access would let us permanently delete mail. We deliberately gave that ability up.

Encryption and token storage.

OAuth refresh tokens are the crown jewels of a system like RocketMail. Losing one means losing access to a customer's mailbox until it is rotated. We treat them accordingly.

• Envelope encryption. Every OAuth token is encrypted with a per-tenant data key. The data key is itself encrypted by a customer-master key held in AWS KMS. Tokens are never written to disk or a log in plaintext.
• In transit. TLS 1.2 or higher on every external hop. Internal service-to-service is mTLS.
• At rest. AES-256 on the underlying block storage, in addition to the envelope encryption above.
• Key rotation. Data keys rotate every 90 days. KMS master keys rotate on the AWS default schedule. Rotations are transparent to the running product.
• Secret hygiene. Application secrets, third-party credentials, and provider webhooks live in a hardware-backed secret store. There is no .env in production.

tenant_id : "t_meridian_health"
provider : "google"
user_email : "priya@meridian-health.example"
scope : "gmail.modify"
refresh_token : <envelope-encrypted>  # DEK id: dek_2f9a…, wrapped by KMS key kms/rocketmail-prod
access_token : <in-memory only, never persisted>
last_rotated : "2026-08-17T09:14:22Z"
expires_after : "90d"

Isolation, per tenant.

RocketMail's inference pipeline is designed so that one rep's writing style, one deal's context, and one tenant's history do not touch another. This is not a policy. It is a data model.

• Per-user voice profiles. The retrieval index that grounds a draft is built from a single user's sent mail. It has no read path into anyone else's sent mail, in the same organization or otherwise.
• Per-tenant embeddings. Vector indices are stored in per-tenant collections. Cross-tenant reads are denied at the query layer, not just the API layer.
• Row-level tenancy. Every operational table carries a mandatory tenant id, enforced by row-level security in the database, so a bug in application code cannot leak across boundaries.
• Deal-level scoping. When a draft is composed, the retrieval query filters to the user's own sent mail and the specific opportunity's thread history. Nothing else.

Nothing trains on your email.

Customer email does not train any shared model. Not the base model, not the reply model, not the classifier that decides priority. Per-user voice profiles are retrieval indices, not model weights, and they belong to the user they were built for. The retrieval index for one user is not accessible to another, including inside the same organization, and it is deleted on seat deprovision.

• No customer data is used for training foundation models by RocketMail or its inference providers, per our contracts with those providers.
• Inference providers are on zero-retention configurations where the provider offers one, so prompts and completions are not stored on their side either.
• If a customer's DPA requires additional restrictions, those are added on top, not renegotiated against.

CRM write controls.

RocketMail writes to your CRM. That is what makes it useful, and that is also what RevOps is most nervous about. The controls below exist so RevOps stays in charge of that channel, not us.

• Field-level mapping. Every field RocketMail can write is listed in the console. RevOps enables, restricts, or disables each one before rollout. Nothing writes by default outside a curated set of low-risk fields.
• Dry-run mode. For the first two weeks by default, every write is proposed but not committed. RevOps reviews the log, approves the pattern, then flips writes on.
• Per-object and per-field permissions. A field can be set to auto-write, propose-then-approve, or read-only. Different tiers can be set per object.
• Full audit log. Every write records the source message, the reasoning, the confidence, the user session, and the fields changed. Exportable to your SIEM.
• One-click revert, 30 days. Any write can be rolled back for thirty days after the fact. Reverts are themselves audited.
• Rate limits. An anomaly detector caps writes per object type per hour. A misbehaving pipeline pauses itself and pages the on-call.

object: Opportunity
fields:
  - name: Stage
    mode:       propose_then_approve   # show me first
    min_confidence: 0.85
  - name: NextStep__c
    mode:       auto_write
    min_confidence: 0.70
  - name: CloseDate
    mode:       read_only                # RevOps owns the forecast date
  - name: Amount
    mode:       read_only
rate_limit: 400 writes/hour/user

The approval model.

Every RocketMail action sits on one of four tiers. The tiers are not settings that hide inside an admin panel. They are the contract the product ships with. The last tier, outbound email, is locked. An admin cannot loosen it. The company cannot loosen it either.

Compliance, without the badges.

We are an early-stage company. Certifying is a process, not a purchase. Here is where we actually are. If a state below is not Ready, we say so. We do not put a placeholder logo on the site and hope no one asks.

Deliverability.

Mail from RocketMail is sent through your own provider. Your SPF, your DKIM, your DMARC, your domain reputation. There is no third-party sending relay in the path. When Priya hits Send in RocketMail, the SMTP hop is Priya's own account, and the recipient sees the same headers they would see on a message sent from Priya's mail client.

• No relay. No shared IP pool.
• No content injected into the message that was not visible in the draft.
• No tracking pixel added without an admin explicitly enabling it, off by default.
• Bounces and complaints are returned to your provider, and mirrored to RocketMail's deliverability view. You keep the ground truth.

Subprocessors and data residency.

Short on purpose. Each entry says what data it sees. Additions get 30 days' notice.

Your mail provider and CRM are not listed. They are your systems, connected on your instruction.

Every row says us-east-1 because that is the only region we run in. We are not offering to pin your data elsewhere, because we cannot yet. No analytics, logging or billing subprocessor, because the product uses none. When that changes, this table changes first.

Reporting a vulnerability.

If you found something, send it to us. We will acknowledge inside one business day, and we will not lawyer up.

• Email: security@rocketmail.ai. A PGP key is available on request.
• Safe harbor for good-faith research, no legal action against researchers who follow the disclosure policy.
• Public thanks in the changelog if you want it, silent fix if you would rather.