Security Overview
In one line
The security controls qypu has in place today, the ones still planned, and the gaps we know about. We hold no security certification yet.
The short version
This short version helps you understand the full text. Read the full text for the complete terms.
- We hold no security certification. We do not claim SOC 2, ISO 27001, or similar. (Full text, section 1)
- Every control below is marked In place or Planned. We update this page when that changes. (Section 2)
- In place today: OAuth sign-in with no stored platform passwords, encrypted tokens, strict browser security headers, rate limits, staff access behind Cloudflare Access, and automated code and dependency scanning. (Section 3)
- Most important planned work: a separate database and storage for qypu, per-workspace encryption keys, a permanent audit log, and an independent penetration test. (Section 4)
- We publish what we watch, how fast we aim to recover, and who does what. (Sections 5 to 7)
- Found a problem? See the Vulnerability Disclosure Policy. (Section 8)
Full text
Read the full text (about 4 minutes)
1. Our position
qypu is an early-stage service. We would rather show you an honest list than a badge. We hold no third-party security certification or attestation. When we start an audit, we will say so here, and we will not describe ourselves as "compliant" with a standard until an independent auditor says so.
2. How to read this page
- In place: running in the code on our main branch, and checked by tests or configuration review.
- Planned: designed or partly built, not yet relied on. No date unless stated.
3. Controls
| Area | Control | Status |
|---|---|---|
| Hosting | Application on Vercel; DNS, TLS, and edge security on Cloudflare | In place |
| Hosting | Database on Supabase (Postgres) | In place |
| Separation | Dedicated database, storage bucket, and vendor keys for qypu (today some are shared with another product run by the same team) | Planned, top priority |
| Customer sign-in | WorkOS AuthKit, supporting single sign-on and multi-factor authentication | In place in code; switched on at launch |
| Staff access | Admin console only behind Cloudflare Access, with an allow-list that fails closed and 8-hour sessions | In place |
| Staff access | Multi-factor authentication enforced for all staff access | Planned |
| Least privilege | Staff roles with only the access each task needs | Planned |
| Least privilege for AI | Drafting steps run with no tools; publishing, messaging, tokens, billing, and code execution are off-limits to all AI steps | In place in code; being extended to every stage |
| Platform passwords | None collected or stored for customer channels; OAuth only | In place |
| Token encryption | AES-256-GCM authenticated encryption at rest | In place |
| Token encryption | Per-workspace keys, record binding, and key rotation | Planned (code built) |
| Encryption in transit | TLS on all public endpoints; HSTS | In place |
| Encryption at rest | Database and storage encryption by our providers | In place (provider default) |
| Browser security | Strict Content Security Policy with per-request nonce, anti-framing, and other security headers | In place |
| Abuse protection | Rate limits on API, sign-in, connection, and publishing routes; sensitive routes fail closed | In place |
| Abuse protection | Managed web application firewall rules | Planned |
| Webhooks | Signature checks on platform callbacks | In place |
| AI safety | Untrusted text (comments, web pages, files) isolated from instructions; links and secrets filtered from AI output | In place in code; being connected to every stage |
| AI cost safety | Daily AI budget per workspace and a global kill switch | In place |
| Logging | Error monitoring with Sentry; tokens filtered from the main log paths | In place |
| Logging | Permanent, tamper-evident audit log of sign-offs, connections, and staff actions | Planned |
| Code | Secret scanning (gitleaks), static analysis (Semgrep), dependency checks, and Dependabot updates on every change | In place |
| Code | Protected main branch with required review | Planned |
| Testing | Independent penetration test | Planned |
| Backups | Provider-managed database backups | In place (provider default) |
| Recovery | Tested restore and a written recovery plan | Planned |
| People | Security training and confidentiality terms for everyone with access | Planned |
| Vendors | Security and data protection review before adding a subprocessor | In place (manual) |
4. Known gaps we are fixing
We keep an internal security audit and fix list. The most important open items, in order:
- Separate qypu's database, storage, and vendor keys from the other product they are shared with today.
- Connect per-workspace token encryption.
- Store audit events permanently, not only in logs.
- Enforce multi-factor authentication for all staff.
- Commission an independent penetration test before we take paying customers at scale.
5. What we watch
We monitor errors, failed sign-ins, rate-limit hits, AI spend, token refresh failures, and publishing failures. Alerts go to the on-call person. A public status page is Planned.
6. Recovery targets (draft)
| Measure | What it means | Draft target | Status |
|---|---|---|---|
| Recovery point (RPO) | The most recent data we could lose in a disaster | 24 hours | Planned (depends on provider backups) |
| Recovery time (RTO) | How long until the service is back after a disaster | 24 hours | Planned (not yet tested) |
Signed, scheduled posts are not published while qypu is down. They publish when service returns, unless their time has passed by more than 2 hours; then we ask you again.
7. Who does what
Security is shared. See the "Who does what" page for the split between qypu, you, platforms, and our providers.
8. Post-quantum readiness
How we prepare for future quantum computers is on the Post-Quantum Readiness page (/trust/post-quantum).
9. Reporting a vulnerability
See the Vulnerability Disclosure Policy, or /.well-known/security.txt.
Change log
- 2026-10-10 · 0.1.0 · First draft, based on the internal security audit of 10 October 2026.
Open questions for counsel
We publish these while the page is a draft, so you can see what is not settled yet.
- This page is a public representation. Engineering must re-verify every "In place" row against production before publication; misstatements risk deceptive-practice claims (FTC Act s.5, ACL s.18, UK CPRs/DMCC Act).
- Do not attach this page to the DPA as contractual commitments beyond "In place" rows.
Useful for: Business owners, IT and security reviewers, Platform reviewers. To save this page as a PDF, use your browser's Print command. Back to the trust centre.