Skip to content
Attaché Join the waitlist (opens your email app)

Attaché

Security

How Attaché protects your accounts, your calendars and the permissions you set.

On this page

Attaché is built around one rule: a delegate should only ever see and do what you have allowed. This page explains how we protect your accounts, your calendar data and those permissions. The privacy policy covers what data we collect and why.

Your accounts stay yours

  • You connect Google, Microsoft and Zoho accounts through each provider’s own OAuth 2.0 sign-in page. Attaché never sees your password for those accounts.
  • Delegates sign in to Attaché as themselves. They never receive your provider passwords or tokens, and everything they do goes through Attaché’s permission checks.
  • We ask providers only for the calendar permissions Attaché needs to work.

Encrypted token vault

  • Provider refresh tokens are encrypted with AWS Key Management Service (KMS) envelope encryption: each token is encrypted with a unique data key, and that data key is encrypted with a KMS key that never leaves AWS KMS.
  • Each encrypted token is bound to its account and connection by a KMS encryption context, so it can’t be decrypted outside that context.
  • The web-facing API can only encrypt tokens. Only the background workers that sync and update your calendars can decrypt them.
  • The KMS key is rotated automatically.
  • Provider tokens are never sent to browsers or devices, including your delegates’.

Permissions enforced on our servers

  • Every read and write passes through Attaché’s permission engine on our servers. Events are redacted before they leave our servers, so a delegate’s app never receives details you haven’t shared, even if someone modifies the app.
  • Events hidden by your filters can’t be edited or deleted by delegates.
  • In propose → approve mode, nothing is written to your Google, Microsoft or Zoho calendar until you approve it.

Encryption in transit and at rest

  • In transit: every connection to Attaché uses HTTPS with TLS, and so do our connections to Google, Microsoft and Zoho.
  • At rest: our database, its backups and our file storage are encrypted.

Infrastructure and access

  • Attaché runs on Amazon Web Services in the United States (us-east-2, Ohio).
  • Least-privilege access: each part of the system gets only the AWS permissions it needs, scoped to specific resources.
  • The database runs in a private network and is not reachable from the internet.
  • Deployments use short-lived credentials instead of long-lived access keys, and application secrets are stored encrypted, never in source code.
  • A web application firewall with rate limiting protects the production service.

Append-only audit log

  • Every action taken in your calendars through Attaché, by you or by a delegate, is recorded: who acted, what changed, when, and copies of the event before and after the change so that it can be undone.
  • The log is append-only: nobody using Attaché can change or delete its entries. Entries are kept for 12 months by default.

Backups and recovery

  • The production database has automated, encrypted backups with point-in-time recovery, kept for 35 days.
  • When you delete your account, your data leaves our backups as they expire (see retention and deletion).

Reporting a vulnerability

If you believe you have found a security vulnerability in Attaché, please email security@tryattache.com with a description, the steps to reproduce it and any proof of concept. We will acknowledge your report within three business days, keep you updated while we investigate, and credit you once it is fixed if you would like us to.

When you research Attaché, please:

  • test only against accounts you own or have permission to use;
  • never access, change or delete other people’s data;
  • avoid degrading the service: no denial-of-service testing, spam or high-volume automated scanning;
  • don’t use social engineering or physical attacks; and
  • give us reasonable time to fix the issue before you disclose it publicly.

If you follow these guidelines in good faith, we will not pursue legal action against you for your research, and we will work with you to understand and fix the issue. We don’t offer a paid bug bounty at this time. Our contact details are also published in security.txt.