Privacy Policy

Last updated: 2026-08-08

This policy covers two separate things. Part A is the managed automations service Roux sells to businesses, which processes messages sent to you by your own customers. Part B is a set of internal tools the operator uses on his own Google account, which have no customers and no external users. They share a policy page but not a system.

Part A — Managed automations

A1. Who this covers

This part applies to businesses that subscribe to a Roux managed automation, and to the people who write to those businesses. Roux is operated by Thomas Peng, a sole proprietor based in Toronto, Canada.

If you emailed a business and Roux processed that message, the business is the data controller and Roux is its processor. Requests about your data are best directed to the business you contacted; we will assist them in answering you.

A2. What we process

  • Inbound messages— the content, sender name and address, subject, and technical headers of email sent to the dedicated Roux address issued to a subscriber, or of submissions to a subscriber's website form that they have pointed at Roux.
  • Generated drafts — the replies our automations write, any edits the subscriber makes, and whether the draft was approved, edited, or discarded.
  • Configuration — material the subscriber gives us to do the work, such as tone notes and a pricing sheet.
  • Account and billing — name, email, and the subscription record. Card details go directly to Stripe and are never seen or stored by Roux.
  • Operational logs — run outcomes, timing, error detail, and token counts.

A3. What we do with it

We process a message for one purpose: to run the automation the subscriber is paying for. That means reading the message, drafting a response, and holding that draft until a human approves it.

Nothing is sent automatically.Every outbound message is released by a person at the subscriber's business. This is a design property of the product, not a setting.

We do not sell your data, use it for advertising, or use it to train machine-learning models.

A4. Who else sees it

Running this service requires a small number of subprocessors. Message content is sent to the inference provider; the others see only account or delivery metadata.

  • The inference provider— receives the message content and the automation's instructions in order to draft a reply. The provider currently in use is named in your service agreement. We will tell subscribers in advance of changing it, because which company processes your customers' words is a decision you are entitled to make rather than discover.
  • Clerk — authentication for the approval inbox. Sees your email address, not your messages.
  • Stripe — subscription billing and card handling.
  • The email delivery provider — transmits approved replies, and necessarily sees those replies.
  • Hetzner — the German hosting provider whose server in Finland runs the service and its database.

We disclose data to no one else, except where the law compels us and we are permitted to say so.

A5. Where it lives, and for how long

Message content, drafts, and run history are stored in an access-restricted Postgres database on a single server in Finland.

Message bodies and drafts are retained for 90 days after a run reaches a final state, then deleted. Run metadata without message content — timestamps, outcomes, token counts — is kept for twelve months so we can answer questions about billing and reliability. Account and billing records are kept as long as the law requires.

On cancellation we delete a subscriber's message content and drafts within 30 days. A subscriber may ask for immediate deletion at any time and we will act on it.

A6. Security

The service runs on a hardened Linux host with key-only SSH, no password authentication, and a default-deny outbound firewall. The database listens only on the local interface. Application secrets are stored with restrictive file permissions and are never logged. Application logs record identifiers and outcomes rather than message bodies.

Each subscriber's data is scoped to their own account at every layer of the application, and that isolation is covered by automated tests that fail if the scoping is removed.

No system is perfect. If we discover a breach affecting your data we will tell affected subscribers promptly and describe what happened plainly.

A7. Your rights

Depending on where you live, you may have rights to access, correct, export, or delete your personal data, and to object to its processing. Write to us and we will honor them; we will not make you justify the request. Canadian subscribers may also complain to the Office of the Privacy Commissioner of Canada.

Part B — The operator's internal Google tools

B1. What these are

This part applies to OAuth-authorized applications operated by Thomas Peng against his own Google account: roux-drive-mcp, agency-brain, roux-pitch, roux-sender, staging-deliver, and ai-news-brief.

These six applications have a single authorized user, the operator himself. They are not offered to customers, and the managed automations service described in Part A does not use them or hold any Google OAuth credential belonging to a customer.

B2. What data they access

  • Google Drive— read, create, update, and organize files in the operator's Drive. Used to find folders, create briefing Documents, and store generated artifacts.
  • Google Docs — read and edit Documents owned by or shared with the operator. Used to compose briefings, proposals, and digests.
  • Google Sheets — read and append rows to Spreadsheets owned by or shared with the operator. Used to log prospect activity and operational metrics.
  • Gmail (roux-sender only)— send, label, and watch messages in the operator's own mailbox, to send outbound email and detect replies. Nothing is retained outside that mailbox.

Data accessed through these scopes is not shared with third parties, sold, used for advertising, or used to train machine-learning models, and does not leave the operator's Google account except where he individually initiates it.

B3. Processing, retention, and revocation

Processing is ephemeral: API responses are held in memory for the duration of a run. Persistent storage is limited to OAuth refresh tokens on disk at file mode 0600, per-run operational logs containing URLs and exit codes but no document or email bodies, and local markdown copies of generated briefings that mirror what already exists in the operator's Drive.

Tokens persist until revoked at Google Account → Security → Third-party apps. Revoked tokens stop working immediately and subsequent runs fail loudly rather than degrading quietly.

Contact and changes

For questions about this policy, a data request, or to report a security concern, contact Thomas Peng at thomas@rouxagency.com.

We update this policy when what we actually do changes. The “Last updated” date at the top reflects the most recent change, and material changes affecting subscribers are sent by email rather than left to be noticed. The canonical URL is https://rouxagency.com/privacy.