Skip to main content
Source-aligned trust boundary

Security transparency before security theatre.

This page separates safeguards implemented in the current application source from deployment, isolation, recovery, legal, and independent-assurance evidence that still has to be produced. It is a due-diligence starting point—not a certificate, audit opinion, or procurement approval.

Application safeguards

Source-verified

Capability gates, scoped clients, bounded endpoints, safe failures, and file-ticket paths are regression-locked.

Independent assurance

Not completed

No penetration-test, certification, or independent architecture opinion is claimed.

Live tenant isolation

Not proven

Direct deployed database and storage denial evidence remains blocked on migration reconciliation.

Commercial readiness

Evaluation only

Legal, privacy, support, resilience, and procurement evidence remains outside the current product promise.

Implemented in the current source

Reviewed application safeguards

These statements are deliberately scoped to application source and automated contracts. They do not generalize to a hosted environment or operating program.

Workspace and capability checks

Protected pages, route handlers, and Server Actions declare application policy before their scoped data operations. A page gate is never treated as a substitute for endpoint or database enforcement.

User-scoped data access

Ordinary server reads and writes use the authenticated user's Supabase context. The current executable application source contains no service-role client, while database RLS remains the intended authoritative boundary.

Bounded exposed endpoints

Route handlers are explicitly inventoried. Search and AI request bodies have strict size and schema limits, sensitive reads re-check capability scope, and machine responses avoid caching raw workspace results.

Server-mediated evidence files

Evidence upload, attach, download-ticket issuance, cleanup, and delete paths are server mediated. Downloads use a short-lived signed single-object transfer after application checks.

Contained failure messages

Guarded operations convert unexpected failures into generic user-safe results with opaque incident references. Structured logs avoid echoing arbitrary action names or raw provider detail.

Baseline browser protections

The source applies framing, MIME, referrer, permissions, opener, and production HSTS policy. A browser-compatible Content Security Policy remains an explicit open item.

Evidence ledger

What has evidence—and what does not

“Not proven” is a release boundary, not a hidden footnote. Each item needs retained, accountable evidence before the corresponding claim can advance.

  • Application policy and source contracts

    Verified in repository

    Automated contracts inventory executable boundaries, capability gates, safe failures, public claims, and regression-sensitive interaction behavior.

  • Production compilation and route tracing

    Verified locally

    The current candidate completes its production build and static/dynamic route classification in the managed development environment.

  • Public browser, keyboard, responsive, and Axe journeys

    Historical candidate only

    A previous locally servable candidate passed Chromium and WebKit desktop/mobile journeys. The current host rejects local listeners, so this trust page has no fresh rendered pass.

  • Authenticated role and cross-tenant browser journeys

    Not executed

    The persona contract exists, but approved short-lived synthetic tenants and roles have not been provisioned or accepted for execution.

  • Direct database and storage denial tests

    Not proven

    Historical migration state is not yet reproducible, so deployed RLS, storage isolation, and cross-tenant denial behavior are not represented as verified.

  • Backup, restore, resilience, and incident response

    Not proven

    No accepted restore drill, recovery objective, availability history, on-call path, or customer-notification exercise is published for this candidate.

  • Independent security and accessibility review

    Not completed

    No current penetration-test, independent architecture review, screen-reader acceptance report, or accessibility-conformance claim is published.

  • Legal, privacy, and procurement package

    Not published

    Terms, privacy notice, DPA, subprocessors, retention/deletion, SLA, support, and AI disclosures still require accountable review and publication.

Current architecture boundary

Defense in depth, with the unproven layer visible

Application checks narrow access before data operations. Database and storage policy must still deny invalid access independently, and that live proof remains open.

  1. 01 · Browser

    Session and bounded request

    The browser submits authenticated, same-origin interactions and receives generic failures rather than internal diagnostics.

  2. 02 · Application

    Workspace, release, and capability policy

    Pages, handlers, and actions independently establish the current workspace and the relevant product or authority boundary.

  3. 03 · Supabase

    User context and intended RLS authority

    Ordinary operations retain the user's identity. Application checks add defense in depth but do not replace database policies.

  4. 04 · Storage and providers

    Narrow transfer or explicit enablement

    Evidence files use server-issued object tickets. AI reaches an external provider only when explicitly configured and enabled; it is off by default.

Paid-pilot gate

Diligence that still needs accountable closure

A polished demo does not waive these decisions. Contracted scope should identify an owner, acceptance evidence, and rollback or response path for every applicable item.

  • Named security, privacy, legal, support, and incident owners
  • Approved deployment regions, data flow, subprocessors, and retention/deletion contract
  • Reproducible database history plus direct active/inactive/cross-tenant RLS and storage denials
  • Backup/restore exercise with accepted recovery objectives and retained evidence
  • Independent application-security review and remediation evidence
  • Authenticated keyboard, mobile, screen-reader, zoom/reflow, and browser acceptance
  • Incident response, customer communication, availability, support, and escalation expectations
  • Content rights, standards currentness, expert review, and claim approval for the contracted scope

What this trust center does not prove

This page is not an ISO certification, SOC report, penetration test, legal opinion, privacy approval, accessibility conformance statement, uptime SLA, disaster-recovery proof, live tenant-isolation test, or declaration that Fluid is generally available. The evidence ledger must advance separately as accountable work is completed and independently accepted where required.

Evaluate the product with the open boundaries in view.

Compare the trust ledger with product status, then validate the exact design-partner scope and evidence you would require before relying on Fluid.