Security

Last updated: February 6, 2026

Security is foundational to Styrby. We handle sensitive data including AI agent session content, cost records, and user credentials. This page describes the measures we take to protect your data and how we respond to security incidents.

Security Measures

Encryption

• End-to-end encryption: session messages between your CLI and mobile/web clients are encrypted using TweetNaCl (public-key authenticated encryption). Styrby cannot read the plaintext content of your encrypted messages.
• Encryption at rest: all data stored in our database is encrypted using AES-256.
• Encryption in transit: all connections use TLS 1.2 or higher. HTTP is automatically redirected to HTTPS.

Access Control

• Row Level Security (RLS): every database table has RLS enabled, ensuring users can only access their own data.
• Authentication: we use Supabase Auth with secure magic links and OAuth providers (GitHub).
• API key hashing: API keys are hashed with bcrypt (cost factor 12) before storage. Plaintext keys are shown once on creation and never stored.

Application Security

• Input validation: all API endpoints use Zod schema validation to prevent injection and malformed input.
• Rate limiting: all write endpoints are rate limited to prevent abuse.
• Security headers: Content Security Policy, HSTS, X-Frame-Options, and other headers are configured in production.
• Webhook signatures: incoming webhooks are verified using HMAC-SHA256 with timing-safe comparison.
• Audit logging: security-relevant actions (login, machine pairing, API key operations, data export) are logged with timestamps and IP addresses.

Responsible Disclosure

If you discover a security vulnerability in Styrby, we ask that you disclose it responsibly:

1. Email security@styrby.dev with a description of the vulnerability, steps to reproduce, and any proof-of-concept code.
2. Allow us reasonable time (up to 90 days) to investigate and address the issue before any public disclosure.
3. Do not access, modify, or delete other users' data during your research.

We commit to acknowledging your report within 48 hours and providing regular updates on our progress.

Incident Response

In the event of a confirmed security incident or data breach, we follow this response plan:

1. Detection and Assessment (0-4 hours)

• Confirm the incident scope, affected systems, and data categories
• Assess severity: critical, high, medium, or low
• Activate incident response team

2. Containment (4-24 hours)

• Isolate affected systems to prevent further exposure
• Revoke compromised credentials or API keys
• Preserve evidence for investigation

3. Notification (within 72 hours)

• Supervisory authority: if the breach is likely to result in a risk to individuals, we notify the relevant data protection authority within 72 hours of confirmation (GDPR Article 33).
• Affected users: if the breach is likely to result in a high risk to individuals, we notify affected users without undue delay via email (GDPR Article 34). Notifications include: nature of the breach, categories of data affected, likely consequences, and measures taken.
• Team/B2B customers: Power tier team administrators are notified directly per our Data Processing Agreement.

4. Recovery and Review (1-7 days)

• Restore affected systems from verified backups
• Implement fixes to prevent recurrence
• Conduct post-incident review and update security practices
• Publish a post-mortem for significant incidents

Infrastructure

• Hosting: Vercel (SOC 2 Type II compliant)
• Database: Supabase (SOC 2 Type II compliant, daily backups, point-in-time recovery)
• Email: Resend (DKIM, SPF, DMARC configured)
• Payments: Polar (PCI DSS compliant as merchant of record; we never handle payment card data)

Contact

For security concerns: security@styrby.dev

For general inquiries: support@styrby.dev

Related documents: Privacy Policy | Terms of Service | Data Processing Agreement