1. Purpose and commitment
Viridian Labs operates a documented information security program that governs how we design, build, and run every product on the viridianlabs.co platform, including MedVault and CardLedger. This policy, along with the procedures register in §13, constitutes our formal operational information security program. The program is continuously matured: each quarter we review the controls below against operational incidents, audit-log findings, vendor-security updates, and customer feedback, and we revise the policy and its procedures accordingly. All changes are versioned and preserved in the git history of this document.
2. Scope
This policy applies to all Viridian Labs production systems, source code, customer data, employee accounts, third-party vendors, and physical or virtual infrastructure used to deliver the service. It covers every person — founder, contractor, or automated agent — who has or requests access to Viridian Labs systems or data.
3. Data classification
Data handled by Viridian Labs is classified into four tiers:
- Tier 1 — Restricted. Authentication credentials, Supabase service-role keys, Twilio / Resend / Stripe / Plaid / Anthropic secrets, Supabase database URL. Stored only in Vercel encrypted environment variables. Never committed to source control.
- Tier 2 — Sensitive. Personally identifiable information (name, email, phone), health records (MedVault patients, medications, session notes, refill requests), financial records (CardLedger card balances, transactions, shared expenses). Stored encrypted at rest in Supabase Postgres.
- Tier 3 — Internal. Audit logs, rate-limit counters, login events, push-notification subscriptions. Operational data that supports Tier 2 handling.
- Tier 4 — Public. Marketing content, public documentation, this policy. Stored in the public git repository.
4. Access control
Access to customer data is granted on a least-privilege, need-to-know basis and is enforced at every layer:
- Application layer. Every API route requires an authenticated session and a per-resource ownership check (
canAccessWorkspace, user_id guards, requireRealOwner for admin-only actions). Workspace membership is verified before any cross-tenant data is returned. - Database layer. Supabase Row-Level Security (RLS) is enabled on every public table. The Next.js server uses a Postgres role with
BYPASSRLS; the anonymous/publishable key used in the browser has no row access without an authenticated JWT. - Admin actions. Platform-owner endpoints use
requireRealOwner(), which bypasses the impersonation cookie so an impersonating owner cannot execute admin operations as the impersonated user. - Infrastructure layer. Only the Principal holds credentials to Supabase, Vercel, and third-party vendor dashboards. Vendor accounts are protected with strong passwords and two-factor authentication (OTP or WebAuthn passkey).
- Revocation. On termination of any contractor relationship, credentials are rotated within 24 hours.
5. Authentication
- Primary authentication is handled by Supabase Auth with email + password.
- A second factor is required for every sensitive session: either an 8-digit email OTP (rate-limited to 5 attempts per user / 10 minutes, with brute-force lockout) or a WebAuthn passkey bound to
viridianlabs.co. - The OTP code space is 10,000,000–99,999,999, giving a brute-force resistance 100× higher than a 6-digit code. Tokens expire in 10 minutes and are single-use.
- Session cookies are HTTP-only,
Secure, and SameSite=Lax. Supabase refresh tokens can be invalidated platform-wide by an owner-only "force logout all" action, logged to the audit trail.
6. Encryption
- In transit. All traffic to and from viridianlabs.co is served over TLS 1.2+, enforced by Vercel. HTTP requests are redirected to HTTPS. HSTS is enabled.
- At rest. Supabase Postgres encrypts all data at rest using AES-256. Vercel encrypts environment variables at rest using AES-256-GCM. Backups inherit the same encryption.
- Secrets management. Secrets are stored in Vercel encrypted env vars and referenced at runtime.
.env files are never committed and are excluded via .gitignore. Secrets rotated quarterly and immediately on suspected exposure.
7. Network security
- All compute runs on Vercel's serverless edge, which terminates TLS and enforces standard HTTP security headers (CSP, X-Frame-Options, X-Content-Type-Options).
- The database is reachable only via the Supabase connection pooler with password-authenticated TLS; the direct connection URL is held only in Vercel env and never exposed client-side.
- Rate limiting is applied at the application layer on authentication endpoints (send-OTP: 5 / IP / 10 min; verify-OTP: 5 / user / 10 min, with a 429 response + Retry-After header).
8. Audit logging
Viridian Labs maintains an append-only audit log of all sensitive actions. The AuditLog table records the actor, timestamp, action, entity type, entity name, before/after values where applicable, and the source IP. Logins and login attempts are recorded separately in LoginEvent. The log is retained for the life of the account and is accessible to the platform owner through an in-app audit viewer with filtering and CSV export for forensic review.
9. Vulnerability and patch management
- Dependencies are kept current via automatic GitHub security advisories; critical vulnerabilities are patched within seven days of disclosure.
- The codebase is statically type-checked on every commit and builds fail if TypeScript errors are introduced.
- Third-party libraries are reviewed before introduction and re-evaluated during quarterly policy review.
- Application errors are monitored in real time via Sentry, allowing rapid detection of anomalous behavior.
10. Incident response
The incident response procedure (IRP-01, §13) is executed when a suspected or confirmed security event occurs. The procedure defines four phases:
- Detection. Triggered by Sentry alerts, audit-log anomalies, customer reports, or vendor notifications.
- Containment. Affected credentials are rotated immediately. The "force logout all" platform action is used when refresh-token compromise is suspected.
- Eradication and recovery. Root cause is identified and patched; impacted records are restored from Supabase point-in-time backups.
- Notification. Affected users are notified via email within 72 hours of confirmed compromise, as required by applicable breach-notification law.
Every incident is written up in an incident log, reviewed during the next quarterly program review, and fed back into policy and procedure updates. To report a security concern, email security@viridianlabs.co.
11. Backup and recovery
Supabase performs daily automated backups of the Postgres database with seven days of point-in-time recovery. Vercel retains deployment history for six months, providing rollback to any prior build. Source code is version-controlled in GitHub with off-site copies on all developer workstations. The recovery time objective for the full platform is two hours; the recovery point objective is 24 hours.
12. Vendor and third-party management
Viridian Labs relies on the following subprocessors, each chosen for their published security posture and reviewed during quarterly policy review:
- Supabase (SOC 2 Type II) — Postgres database, authentication, storage.
- Vercel (SOC 2 Type II, ISO 27001) — hosting, serverless compute, edge network.
- Resend — transactional email delivery.
- Twilio (SOC 2 Type II, HIPAA-eligible) — SMS and voice.
- Anthropic (SOC 2 Type II) — AI inference for pill identification and card scanning.
- Stripe (PCI DSS Level 1) — payment processing via Payment Links.
- Plaid (SOC 2 Type II, ISO 27001) — banking data connectivity (scheduled).
- Sentry (SOC 2 Type II) — application error monitoring.
- GitHub (SOC 2 Type II) — source control and CI.
Each vendor is granted only the scopes required to perform its function. Webhooks are authenticated with shared secrets where supported. Customer data is not sold, licensed, or transferred to any third party beyond the subprocessors listed above.
13. Procedures register
The following documented procedures support this policy and are executed as listed. Each procedure has an owner, a defined trigger, and an audit record.
- IRP-01 — Incident response and breach notification.
- ACC-01 — Access provisioning, review, and revocation.
- KEY-01 — Secret rotation (quarterly and on suspected exposure).
- BKP-01 — Backup verification and restore testing.
- CHG-01 — Change management: code review, type-check, build verification before production deploy.
- VEN-01 — Vendor onboarding and annual review.
- RET-01 — Data retention and deletion on user request.
- TRN-01 — Security training and acknowledgment for all personnel.
14. Data retention and user rights
Customer data is retained for the life of the account. Users may export their full data bundle from within the product (Owner → Workspaces → Export for MedVault; top-nav Export for CardLedger). Account deletion removes all personal data within 30 days except for audit-log entries, which are retained with the user identifier redacted to preserve forensic integrity. Users may request access, correction, or deletion of their data by emailing security@viridianlabs.co.
15. Personnel security and training
All personnel with access to production systems acknowledge this policy before being granted credentials and re-acknowledge annually. Training covers phishing awareness, secure coding, secret hygiene, and incident reporting. Credentials are personal and never shared.
16. Continuous improvement
The Viridian Labs information security program is reviewed and matured on a quarterly cadence:
- Audit-log review for anomalous access patterns.
- Incident log review for recurring root causes.
- Vendor posture review (published security reports, certifications, breach disclosures).
- Dependency and patch-backlog review.
- Policy and procedure version updates.
Material changes to the policy are versioned and effective on the date shown at the top of this document.