Skip to content
Milo

Trust

Security

Effective September 10, 2026

Milo handles your inbox, your prospects, and the messages that go out under your name. Below is a plain description of the controls that keep those things safe. If something on this page is unclear or missing, please write to us; we’d rather have the conversation than pretend the question does not exist.

1. Summary

  • Encrypted transit and encrypted storage of your mailbox credentials.
  • OAuth-only mailbox access. No password ever leaves Google or Microsoft.
  • Row-level access controls that scope every read and write to your workspace.
  • Signed, idempotent webhooks for payments and bookings.
  • Send guardrails built in: warm-up, rate limits, bounce handling, suppression.
  • Vendors with clear data-protection terms; a full subprocessor list below.

2. Your mailbox

You connect Gmail or Outlook to Milo using the provider’s official OAuth flow. We never see your password. The provider returns an access token and a refresh token that we store encrypted with AES-256-GCM before they touch the database. When a token expires we refresh it silently. When you disconnect the mailbox we revoke and delete the tokens; nothing lingers.

We request the minimum scopes required to do the work:

  • Send messages you have explicitly approved.
  • Read replies to the threads Milo started, so we can detect a response, stop the follow-up sequence, and surface the reply in your inbox view.

We do not read the rest of your inbox, we do not archive mail elsewhere, and we do not analyze mailbox content for advertising or third-party model training.

3. Data protection

Concrete controls that apply to every workspace:

  • All traffic is served over TLS.
  • Database access is scoped by row-level security. A read or a write that is not for the current workspace never leaves the database.
  • Payment card details are handled by Stripe and never sent to our servers.
  • Signed webhooks (payments, bookings) are verified for signature and idempotency before we accept them, so a replayed or forged request cannot affect your account.
  • Secrets (API keys, encryption keys, database credentials) live in a managed secrets store, are rotated on a schedule, and are only injected into the services that need them.

For collection, retention, rights, and international transfers, see the Privacy Policy.

4. Where your data lives

Application data (accounts, workspaces, drafts, sent messages, replies, and suppression lists) is stored in a managed Postgres database. Background jobs run through a managed Redis instance. Static assets are served from a global CDN. The specific region hosting your data is documented in the account settings; on request we will confirm the exact region for your account in writing. Subprocessor regions are listed under Subprocessors. Cross-border processing is governed by the safeguards in the Privacy Policy.

5. Deliverability and compliance

Cold outreach fails in the spam folder. It also fails legally when it hides the sender or ignores the recipient. Milo treats both problems as security problems and defends against them by default:

  • Warm-up ramp. A new mailbox starts small and grows over days, not minutes.
  • Rate limits and jitter. One message at a time, with a natural, randomized interval between sends. No batch blast.
  • Bounce handling. Bounces mark the address as suppressed and pause the campaign automatically.
  • Reply detection. Follow-ups stop the moment someone replies.
  • One-click unsubscribe. Every message carries a working unsubscribe token. Suppression is instant and account-wide.
  • Physical address. Every message carries your business name and mailing address, meeting CAN-SPAM and equivalent requirements.

6. Infrastructure and access

  • The service runs on managed cloud infrastructure with hardened defaults.
  • Production access is limited to a small, named group of maintainers, is two-factor protected, and is logged.
  • Dependencies are patched on a routine cadence; critical fixes ship faster.
  • Application, database, and job-queue errors are monitored and alerted so incidents surface quickly.

7. Subprocessors

We use a small set of vendors to run the service. Each is bound by data protection terms and receives only the data it needs. The current list:

  • Supabase. Managed Postgres, authentication, row-level access controls. Privacy notice.
  • Google (Gmail API). Sending outreach from your connected Gmail inbox. Privacy notice.
  • Public business directory data provider. Structured public information about local businesses (name, address, category, ratings) used for prospect discovery. Privacy notice.
  • Microsoft (Outlook via Microsoft Graph). Sending outreach from your connected Outlook inbox. Privacy notice.
  • Web content extraction service. Reading public business websites and your own site during onboarding to extract signals and enrich context. Privacy notice.
  • OpenRouter. Routing large-language-model calls for research summaries and email drafts. Privacy notice.
  • Stripe. Processing credit-pack purchases. Card data is handled by Stripe, not by us. Privacy notice.
  • Upstash. Managed Redis for background job queues and short-lived caching. Privacy notice.
  • Resend. System email (account emails, password resets, receipts). Privacy notice.
  • Cal.com. Optional booking integration. Booking events reach us as a signed webhook when you enable it. Privacy notice.
  • Vercel. Hosting the marketing site and the application front end. Privacy notice.

8. Certifications and audits

Milo is an early-stage product built by a small team. We do not currently hold a SOC 2 report, an ISO 27001 certificate, or an equivalent third-party audit. What we do instead is publish the controls we actually run (this page), name every subprocessor, and offer a Data Processing Agreement to business customers who need one. If you have specific compliance requirements before you can adopt the product, please write to us at stallwartofficial@gmail.com and we will tell you honestly what we can and cannot meet today, and where a certification sits on our roadmap.

9. Operations

  • Backups run on a routine schedule and are restored on a test cadence.
  • Incidents that materially affect customer data trigger a written postmortem and a customer notification, within the timelines required by applicable law.
  • We are a small, deliberate team. We prefer fewer moving parts and boring technology to feature spam.

10. Vulnerability disclosure

If you believe you have found a vulnerability, please email stallwartofficial@gmail.com with a description, steps to reproduce, and the impact you observed. Please give us reasonable time to investigate and fix the issue before you make it public. We will acknowledge your report within three business days and keep you updated as we work through it.

We ask that researchers:

  • Do not access data that does not belong to them.
  • Do not run denial-of-service tests or spam our recipients.
  • Give us a reasonable window to remediate before disclosing publicly.

Good-faith researchers who follow these rules will not be pursued under computer-misuse laws.

11. Contact

Security questions: stallwartofficial@gmail.com. For privacy and data-subject requests, see the Privacy Policy. For the rules that govern your use of the service, see the Terms of Service.