Current security baseline
- Cloudflare Workers execution with separate logical privileges and in-process service bindings.
- D1 tenant metadata, private R2 artifacts, and short-lived Worker-mediated asset access.
- Workspace-scoped authorization on every tenant query and server-side role enforcement.
- Better Auth passwordless access with hashed single-use tokens, short-lived codes, secure cookies, and rate limiting.
- Capture sanitization that strips scripts and handlers, blocks arbitrary replay-network access, neutralizes forms, and supports masking or synthetic data.
- OxyBlink plan/execute/verify separation with allowed origins, action limits, read-only defaults, isolated sessions, and explicit confirmation for consequential actions.
- Immutable published releases, replay evidence, health history, repair approval thresholds, and one-click rollback.
- Structured logs, trace identifiers, audit events, dependency and secret scanning, and incident-response runbooks.
Tenant and data isolation
Every tenant-owned relational object carries a workspace identifier. APIs derive authorization from the authenticated membership rather than trusting client-supplied scope. R2 keys are tenant-prefixed, never accepted directly from untrusted clients, and accessed through signed or Worker-mediated routes. Cloud services receive only the bindings their function requires.
Browser and capture safety
Page content is untrusted data, never an instruction to the capture agent. Browser tasks use origin and route allowlists, maximum actions and time, forbidden selectors and data classes, and a test-account expectation for sensitive applications. Purchase, deletion, invitation, permission, publishing, and external-message actions require explicit authorization and confirmation. Sessions are destroyed after use.
AI governance
Workspaces choose allowed providers, sensitivity classes, raw-data policy, budget, and autonomous-action limits. Inputs are reduced to necessary structural data or focused crops. Outputs pass schema and source validation. Model text cannot grant permissions, approve claims, pass replay, or publish content.
Vulnerability reporting
Send suspected vulnerabilities to security@sansavision.com with reproduction steps and impact. Do not access another customer’s data, degrade service, use destructive payloads, or publicly disclose before we have had a reasonable chance to investigate and remediate. We will acknowledge credible reports and coordinate updates.
Compliance roadmap
Before paid beta we target a documented threat model, access reviews, incident process, backup and recovery tests, privacy documents, automated dependency/secret scanning, and a vulnerability channel. At growth stage we plan SOC 2 Type I followed by Type II, formal vendor risk management, external penetration testing, SSO/SCIM, audit exports, and an accessibility conformance report targeting WCAG 2.2 AA. These are roadmap goals, not current certifications.
Legal entity and rights requests
Sansa Group AB, Sweden · Soldathemsgatan 20, 415 28 Göteborg, Sweden · Organisation no. 559111-9507 · VAT SE559111950701. Showmesh is operated under the Sansa Vision division.
Contact privacy@sansavision.com. General product support is forwarded to support@sansavision.com.