HSTS, CSP, and browser security headers
implementedSecurity headers are configured at the app edge; CSP is currently report-only.
Safety
Safety rules for voluntary moral trade
Moral Trade should make serious cooperation easier without rewarding coercion, harassment, manipulation, or unsafe background networking.
Anti-threat and baseline integrity
Safety review starts with the no-trade baseline: what would each participant do absent the trade? Proposals involving threat creation, newly escalated harmful behavior, or coercive compensation requests should be rejected or sent to challenge review.
Read anti-threat baseline rulesBlocked proposal classes
The platform should reject or review proposals involving violence, illegal acts, fraud, extortion, doxxing, harassment, exploitation, or pressure on vulnerable people.
Validator-backed safety evidence
Public health endpoints expose whether the security, disclosure, challenge-appeal, incident-response, performance, and AI-governance contracts pass their current validators. Safety claims should stay tied to these checks rather than implying hidden automation, escrow, or unrestricted reviewer authority.
Security posture contract
Controls, scale gates, and non-claims are public.
The security profile names browser headers, private cache rules, Supabase session boundaries, provider encryption assumptions, admin-scale gates, key-rotation gates, abuse throttles, and incident reporting. It also says what the pilot does not yet claim.
Private no-store cache policy
implementedAuthenticated and sensitive routes, including private match rooms and saved-user surfaces, should not be cached as public pages.
Supabase auth cookies
implementedAuthentication is cookie-backed through Supabase.
Provider encryption at rest
provider boundaryEncryption-at-rest is a provider-boundary control unless a field-level encryption control is explicitly published.
Platform-wide field-level encryption is not claimed
not claimedProvider encryption, RLS, redaction, cache, and consent controls still protect non-background private tables unless a table-specific field-encryption control is published.
Background field-encryption keyring
implementedBackground-networking exact wishes, sensitive constraints, private source notes, connector consent notes, and deterministic synthesis summaries use app-level field encryption with versioned key ids and rotation support.
Server-only secret management
implementedSecrets must stay in deployment/provider secret stores and never be copied into public docs or client bundles.
2FA/MFA admin gate
implementedOperator consoles and review mutations require an allowlisted admin account with an active authenticator MFA session.
Participant session review and revocation
implementedParticipants can inspect the current background-networking session window and revoke other active Supabase sessions from the dashboard.
Contact disclosure MFA step-up
implementedContact-level introductions require an explicit disclosure stage and MFA step-up before contact details can be released.
Device/session review gate
required before scaleSensitive admin scale requires provider-level device inventory and anomalous-session review evidence in addition to participant session revocation.
Key rotation gate
required before scalePaid-action or trust-badge scale requires provider secret/key rotation records and rollback notes; background field encryption exposes its own versioned keyring boundary.
Platform abuse throttling
implementedAbuse-prone surfaces are rate-limited and must fail safely.
Incident response reporting
implementedIncident intake, response phases, public aggregate disclosure rules, and non-claims are validator-backed; this does not complete MFA, key rotation, device/session review, or field-level encryption.
Operations contract
Headers, sessions, retention, and fallback controls are inspectable.
The operations profile names the platform controls that were previously unspecified in public materials: HTTP security headers, private no-store routes, rate-limit surfaces, session/privacy controls, retention lifecycles, observability metrics, and safe fallback behavior.
Header and cache evidence
- Strict Transport Security: next.config.ts sets Strict-Transport-Security for all routes.
- No MIME sniffing: next.config.ts sets X-Content-Type-Options: nosniff.
- Frame denial: next.config.ts sets X-Frame-Options: DENY.
- Referrer policy: next.config.ts sets Referrer-Policy: strict-origin-when-cross-origin.
- Permissions policy: next.config.ts disables camera, microphone, geolocation, and payment.
- CSP report-only baseline: next.config.ts publishes a Content-Security-Policy-Report-Only baseline.
- Private route no-store: Private dashboard, admin, profile API, and job API routes get private no-store headers.
Privacy and session controls
- Supabase auth cookies: src/lib/supabase/proxy.ts refreshes auth claims through server-side cookies.
- Private route cache control: Private route prefixes receive Cache-Control: private, no-store.
- Data-right request lane: Profile data-right requests validate destructive/corrective details and due dates.
- Field-level disclosure grants: Background networking grants stage public previews, detail requests, and mutual consent.
- Email outbox safety gate: src/lib/moral-trade/email-copy.ts centralizes generic dashboard-directed Moral Trade email copy and src/app/api/jobs/email/route.ts suppresses unsafe rows before provider send when body text contains contact details, exact offer terms, payment amounts, agreement or payment identifiers, evidence, raw source notes, or private wish markers.
- Audit events: Match, privacy, and admin actions record audit events where disclosure is safe.
Observability without private text
- funnel event counts
- route error rate
- api latency p95
- web vitals
- blocked proposal rate
- email outbox suppression count
- privacy incident count
- copilot fallback rate
- evidence review sla
- appeal overturn rate
Operational telemetry is framed as counts, route health, latency, Web Vitals, privacy incidents, fallbacks, and review SLAs rather than raw wishes or source notes.
Rate-limit surfaces
25 surfaces, including public contract read (240/1 minute), signup (5/15 minutes), login (8/15 minutes), offer create (8/15 minutes), privacy access request (12/1 day), match concierge request (10/1 day), offer comment (12/15 minutes), offer collection read (120/1 minute).
Retention lifecycle controls
account profile lifecycle, private wish source lifecycle, evidence provenance lifecycle, payment donation reference lifecycle, analytics attribution lifecycle, notification delivery lifecycle, data right request lifecycle.
Fallback and rollout gates
- If copilot, provider, or evidence tooling fails, keep deterministic validation and manual review available.
- Invalid or timed-out copilot output must not publish, match, disclose, or complete a proposal.
- Provider or payment/evidence timeouts remain pending or manual-review states.
- Core Moral Trade email outbox rows with contact details, exact offer terms, payment amounts, agreement or payment identifiers, evidence, raw source notes, or private wish markers are marked suppressed before provider send.
- State transitions should be idempotent, auditable, and safe to retry.
Security scale gates
Expansion is blocked unless the named controls are implemented or consciously held at a provider boundary. This keeps sensitive admin, paid-action, and trust-badge scale from outrunning the current security evidence.
Sensitive admin scale
blockedDo not expand sensitive admin access until MFA, device/session review, key rotation, and incident-response evidence are ready.
Requires two factor admin gate, device session review gate, key rotation gate, incident response reporting.
Paid-action volume scale
blockedDo not expand paid-action volume until provider/security boundaries, key rotation, incident response, and abuse throttles are documented.
Requires platform abuse throttling, provider encryption at rest, server only secret management, key rotation gate, incident response reporting.
Trust badge scale
passDo not expand public trust badges unless private cache, authenticated session, abuse throttling, and incident reporting remain verifiable.
Requires private no store cache, supabase auth cookies, contact disclosure mfa step up, platform abuse throttling, incident response reporting.
Public security non-claims
- Moral Trade does not claim custom field-level encryption for every private Moral Trade table; background-networking sensitive text has a separate versioned keyring control.
- Moral Trade does not claim the app-level MFA/2FA admin gate replaces provider-console MFA, device inventory, session revocation, or key-rotation evidence.
- Moral Trade does not claim a completed key-rotation program until provider rotation records are published.
- Moral Trade does not claim 24/7 staffed security operations or zero incidents; incident summaries stay aggregate and privacy-redacted.
- Moral Trade does not claim zero security risk; public health endpoints expose blockers instead.
Background networking boundaries
The current prototype does not run autonomous AI outreach, mass profile ingestion, or private-feed search. Matching is limited to explicit fields, broad previews, saved searches, and manual source notes so the first version stays legible enough to audit.
No surprise exposure. No autonomous outreach. No private-feed mining.
Collusion, secrecy, and review
The safety problem is not solved by either full openness or total opacity. Broad previews, review queues, match reports, and risk signals try to preserve enough oversight to investigate suspicious activity without exposing every participant's exact wishes to the public by default.
Dispute handling
Participants can record verification evidence, counterproposals, cancellation requests, and disputes on agreements. These records make review possible but do not replace professional legal or financial advice.
Review queues
Reports, payment-review requests, failed notifications, and blocked wish profiles are routed to an admin console so operators can inspect problems before they become public or affect counterparties.
Privacy gates
Match suggestions should reveal broad reasons first. Exact asks, identities, and contact details should be shared only after both sides consent.