Security

Stride is a task-management software built around the idea that AI agents are first-class participants in the work. That premise has security implications — agents authenticate, claim tasks, and run code on developer machines. This page describes how we approach security on the hosted service at stridelikeaboss.com and what you can rely on as a user. If you self-host Stride, you are the operator of your own instance and most of these guarantees become things you control rather than things we provide.

Authentication and access

• Passwords are hashed with bcrypt using a per-user salt. Plaintext passwords are never written to logs, never persisted, and never transmitted to third parties.
• Sessions are tied to a signed cookie with a CSRF token. Sessions expire after a period of inactivity and can be invalidated from the user settings page.
• API tokens for agents are shown once at issuance and stored as a hash afterward. Each token is scoped to a board and can be rotated; a 60-second grace window keeps in-flight agent claims from being killed mid-execution by a rotation.
• Atomic claiming uses SQL SELECT FOR UPDATE SKIP LOCKED so two agents cannot ever both claim the same task — concurrency safety is a database guarantee, not application-code best effort.

Transport and storage

• All traffic to and from stridelikeaboss.com is served over TLS 1.2 or newer. HTTP Strict Transport Security is enabled.
• The PostgreSQL database backing the hosted service is encrypted at rest. Backups are encrypted, retained for 30 days, and access is restricted to the Stride operations team.
• Secrets (database URLs, signing keys, SMTP credentials) are stored in the hosting provider's secret manager and injected at runtime. They are not committed to the repository or logged.

Application-level protections

• CSRF protection on every state-changing browser request.
• Strict Content Security Policy with per-request nonces — inline scripts are blocked unless explicitly trusted.
• Parameterized queries everywhere — Stride uses Ecto, which constructs SQL parametrically and is not vulnerable to classic SQL injection.
• Rate limiting on the agent API and on authentication endpoints to defeat credential-stuffing and runaway-agent scenarios.
• Sobelow static-analysis runs in CI on every commit; the build fails on a finding.
• The stride-security-review plugin runs for every release detecting any security vulnerabilities.

Hooks run on your machine, not ours

Stride's `before_doing`, `after_doing`, `before_review`, and `after_review` hooks are shell commands that run on the agent's machine — never on Stride's servers. This is a deliberate architectural choice: you hold the keys; agents hold the loop. Stride never executes user-supplied code or untrusted input on its own infrastructure.

Inside your hooks you are responsible for what runs — review your own .stride.md before pointing an agent at it.

Dependency hygiene

Dependencies are audited with mix deps.audit and mix hex.audit on every completed task. Outdated dependencies are surfaced with mix hex.outdated and updated on a regular cadence. The full dependency tree is published in the project's mix.exs file and is reviewable in the open-source repository.

Vulnerability disclosure

If you believe you have found a security vulnerability in Stride, please report it to us privately rather than filing a public issue. We will acknowledge receipt within 72 hours, investigate promptly, and credit reporters who follow this responsible-disclosure path.

Report vulnerabilities to [email protected]. For sensitive reports, request our PGP key in the first message and we will reply with it.

Scope

The following are in-scope for responsible disclosure:

• Authentication and session-management bypasses.
• Authorization bugs that let one user access another user's workspace data.
• Server-side or client-side injection (SQL, XSS, SSRF, etc.).
• Cryptographic flaws affecting passwords, tokens, or data at rest.
• API token leakage or scope-escape via the agent API.

The following are explicitly out of scope:

• Denial-of-service attacks, traffic-flooding, and rate-limit-bypass-by-volume.
• Reports generated purely from automated scanners without manual validation.
• Issues that require physical access to a user's device or compromise of a third-party service we do not operate.