Lastday Security Policy

This internal security policy governs how 1001537887 Ontario Inc. operating as Lastday protects customer data, account data, secrets, OAuth tokens, and production infrastructure.

1. Security Principles

Lastday's security model is based on:

tenant isolation by default
no cross-tenant data sharing
least privilege access
no customer data in logs
no secrets in code
customer data stored in Supabase Canada Central
AI processing only through approved providers
human decision authority over Octavian outputs
rapid containment and transparent incident response

2. Data at Rest

Customer operational data is stored in Supabase in Canada Central, ca-central-1.

Supabase-managed encryption at rest applies to stored database and storage resources.

Customer data includes signals, issues, actions, events, attachments, links, users, tenant configuration, OAuth tokens, and AI usage metadata.

No secondary production database, external cache, or alternative customer data store may be added without founder approval.

3. Data in Transit

Production traffic uses HTTPS. TLS 1.2 or higher is required for public application traffic where supported by the hosting provider.

OAuth callbacks, API routes, webhooks, and browser sessions must use HTTPS in production.

Webhook providers must be configured to send events only to approved production URLs.

4. Access Controls

All tenant-scoped tables must include tenant_id unless a table is explicitly documented as global configuration.

Supabase Row Level Security must be enabled on every tenant-scoped table.

Every API route that reads or writes tenant data must resolve tenant_id from the authenticated session, verified webhook, or documented tenant routing mechanism.

Every database query must include tenant_id scoping or use a database policy that enforces tenant scoping.

Queries without tenant scope must fail closed.

Settings and administrative routes are restricted to owner or admin roles unless further restricted to founders.

5. Authentication and Session Management

Lastday uses Supabase Auth for email and password authentication.

Session tokens are validated on protected API routes.

User roles are owner, admin, operator, and viewer.

DEV_AUTH_BYPASS must be disabled in production.

Sensitive content unlock requires password re-authentication through the unlock endpoint.

Password reset and email templates must be configured before production customer use.

6. API Key and Secret Management

Secrets must be stored in Vercel environment variables or an approved secret manager.

Secrets must never be committed to code, included in client bundles, pasted in tickets, logged, or shown in screenshots.

Secrets include Supabase service role keys, Anthropic keys, OpenAI keys, NVIDIA NIM keys, Resend keys, Google OAuth secrets, QuickBooks secrets, Motive secrets, Stripe secrets, Twilio secrets, webhook secrets, and cron secrets.

.env.local must remain ignored by git.

Production secrets must be rotated:

immediately after suspected exposure
when a founder or privileged contractor loses access
annually as a baseline
when a provider requires rotation

Emergency rotation requires documenting the reason, time, person rotating, affected systems, validation step, and follow-up actions.

7. OAuth Token Handling

OAuth access and refresh tokens are stored in backend database tables only.

Tokens must not be sent to the frontend.

Gmail OAuth must use readonly scope where applicable.

Access tokens are refreshed before expiry.

On disconnect, Lastday must revoke tokens with the provider where supported, then null or delete token values in the database.

On tenant deletion, Lastday must revoke and delete OAuth tokens before deleting the tenant record where feasible.

8. Logging

Application logs must never contain:

raw signal content with personal information
passwords
API keys
OAuth tokens
session tokens
medical information
fuel card numbers
full payment card numbers
sensitive HR complaint details

Allowed logs include event type, entity ID, route name, timestamp, error category, provider name, performance timing, token count, and success or failure status.

If personal information is discovered in logs, treat it as a security incident and follow 15_INCIDENT_RESPONSE.md.

9. AI Security

Signal content is treated as data, not instructions.

Octavian prompts must wrap customer signal content in data delimiters.

Octavian may not access data outside the tenant.

Octavian may not reveal secrets, fabricate facts, conceal uncertainty, represent himself as human, or override the Constitution.

AI providers are limited to Anthropic Claude, NVIDIA NIM, and OpenAI embeddings as defined in the Constitution and Octavian architecture.

10. Vulnerability Management

Security vulnerabilities may be identified through code review, dependency updates, automated checks, manual testing, customer reports, provider notices, or founder review.

Critical vulnerabilities that risk customer data exposure must be triaged immediately and treated as P1 until assessed.

High-risk vulnerabilities should be remediated before the first paying customer connects where practical.

Dependencies should be reviewed before major releases and after security advisories.

Penetration testing is required before scaling beyond early customers as described in Trust & Compliance.

11. Employee and Founder Access

Current privileged access is limited to the two founders:

Jordan Layden: commercial, customer, billing, privacy contact
Sidney Wittman: technical, architecture, infrastructure, deployment, security

Privileged production access must be used only for support, security, deployment, incident response, or customer-authorized troubleshooting.

Any future employee, contractor, or vendor access must be approved by a founder, limited to least privilege, and revoked promptly when no longer needed.

12. Incident Response

Incident response is governed by 15_INCIDENT_RESPONSE.md.

Any suspected unauthorized access, cross-tenant exposure, OAuth token compromise, provider breach notice, credential compromise, or personal information leak must be escalated immediately to both founders.

13. Review Cycle

This policy must be reviewed before first paying customer, after any P1 security incident, after material architecture change, and at least annually.

Change Log

Version 1.1. April 20, 2026. Jordan Layden. Governance Wave 5 reconciliation. Header pin sweep: Constitution cite bumped to v3.14, Trust & Compliance cite bumped to v2.8. Voice exemption clause added citing §25.3(a). No substantive security control changes; DRAFT status preserved.