How Stryde protects account access, health data, MCP tokens, and privileged operations.
The short version
Full technical details are below.
Stryde does not store passwords, password hashes, or Stryde-side MFA secrets. Account recovery and multi-factor authentication live with your Google account. We never handle your Google password.
Web sessions use cryptographically signed tokens with HttpOnly and Secure flags. Sessions expire and rotate regularly — there are no indefinitely-persistent session cookies.
Sensitive health payloads, OAuth provider tokens, and coaching context are encrypted with AES-256-GCM before being written to the database. Even if the raw database rows were extracted, they would contain ciphertext — not your heart rate, sleep, or training data.
The encryption master key is never stored in plaintext. In production it is managed by Google Cloud KMS and never written to disk or logs. The system fails closed — if key material is unavailable, requests are rejected rather than falling back to unencrypted storage.
All traffic between your device and Stryde's servers is encrypted with TLS. Database connections run over private network paths with encryption required. There are no unencrypted transport paths to your data.
Support and admin workflows operate on operational metadata — not on your raw health data. Reading the plaintext of your heart rate, sleep, or workout records requires active key material scoped to your session. Routine support flows do not have this access.
MCP API calls authenticate with a user-generated Bearer token. Tokens are stored as one-way hashes — the plaintext is shown once at creation and is never recoverable from the database.
Each token is bound to a single user. Claude cannot use your token to access another user's data. There is no admin token that spans multiple users.
When MCP clients (like Claude) authenticate via OAuth, the flow uses PKCE (S256 code challenge). This prevents authorization code interception attacks even on public clients.
Deleting a key from Settings → Security immediately invalidates all future requests carrying that token hash. There is no delayed propagation.
Stryde operates a two-layer audit trail. The application layer writes every security-sensitive action to an append-only log, tagged by actor type so operator access is always distinguishable from user access. The infrastructure layercaptures all data access — including paths that bypass the application — into audit logs stored outside Stryde's control and outside our ability to modify retroactively. Raw health payloads and credentials are never logged — only their presence or absence.
All API endpoints are protected by per-identifier rate limiting to prevent brute-force and enumeration attacks.
Cross-origin requests are blocked by default. Only the endpoints required by the MCP protocol spec accept cross-origin requests.
All API request bodies and tool parameters are validated against strict schemas before any business logic runs. Parameterized queries are used throughout — no raw user input reaches the database.
If you discover a security vulnerability in Stryde, email security@stryde.coach before disclosing publicly. This address is monitored whether or not you have an account — you do not need to be signed in to report. We will acknowledge receipt within 48 hours.
We do not pursue legal action against researchers who report vulnerabilities in good faith, do not access or modify user data beyond what is necessary to demonstrate the issue, and do not disrupt service availability.
If Stryde suffers a breach that affects your data, we will notify affected users by email within 72 hours of confirming the scope of the incident. Notification will include what data was involved, what we have done to contain it, and what you should do. We will not delay notification to manage reputational impact.
Breach notices are sent to the email address on your account. Keeping your Google account email current ensures you receive them.