Security
Last updated: April 11, 2026
Security at soundOS starts with clear trust boundaries.
soundOS is not just a static website. The current product includes a public site, an authenticated dashboard, a Windows desktop application, hosted APIs, cloud-backed workspace state, voice-session infrastructure, and internal orchestration/session layers that support soundOS behind the scenes.
This page describes the current engineering posture reflected in the codebase. It is not a statement of certification, a formal audit report, or a guarantee that any system is invulnerable.
Product trust boundaries
The current soundOS architecture separates responsibilities across distinct surfaces:
1. Website and dashboard surface
The soundOS website and browser dashboard handle public pages, account entry points, and authenticated product access.
The browser dashboard is cloud-connected. It does not expose desktop-local process control in the browser host.
2. Desktop-local runtime
The current shipped desktop path is a Windows application. It can perform actions that only make sense on the local machine, including terminal and process workflows.
That means soundOS is designed to keep a meaningful line between:
- what runs locally on your machine
- what is stored in local app-data or OS keychain facilities
- what is sent to hosted APIs and cloud services
3. Hosted control plane and state services
The current soundOS cloud layer uses hosted service components built on Cloudflare Workers, Durable Objects, KV, R2, and queues for portions of:
- authenticated API access
- account settings
- workspace and orchestration state
- event fanout and session coordination
- voice artifacts, receipts, and related records
4. Voice and orchestration services
Voice features use a dedicated voice service path with session coordination, transcript handling, turn receipts, artifact storage, and approval/evidence-related flows.
Parts of the soundOS orchestration, session history, approvals, replay, and artifact behavior are implemented through internal T2P-derived host/session infrastructure behind soundOS. Those components matter to security because they enforce session scope, attachment flows, and controlled access to session state.
Authentication and session handling
The current soundOS codebase uses a layered authentication model.
Clerk-backed identity
soundOS uses Clerk-backed authentication for account identity and browser sign-in flows.
Browser session exchange
For the browser dashboard, soundOS exchanges the authenticated token for a secure application session cookie. In the current implementation, that cookie is:
- HttpOnly
- Secure
- SameSite=Lax
- scoped to the application path
- configured for up to 72 hours unless revoked or expired sooner
Desktop auth flow
The desktop app uses browser-based sign-in and local callback handling during authentication. The current implementation uses a local loopback callback path and refreshes access as needed for cloud-backed features.
Scoped token checks
Current soundOS services validate user and workspace scope before allowing access to protected routes. Voice bootstrap and related session flows check the authenticated scope rather than accepting arbitrary workspace claims from the client.
Desktop-local protections
The current desktop codebase contains several security-minded design choices.
OS credential storage
Sensitive desktop secrets are not stored in the workspace folder. The current implementation stores provider API keys and certain refresh/session material in the operating system credential manager or keychain.
App-data separation
The desktop app uses operating-system-managed app-data roots for local storage. The repo explicitly separates roaming/config-style data from local/cache-style data and avoids storing mutable application state under Program Files.
Workspace isolation from app-owned state
The repo also makes clear that soundOS should not write app-owned mutable state into the user's workspace folder. That reduces unnecessary mixing of product state with repository or working-directory content.
Startup integrity checks
The current Windows desktop distribution path includes executable integrity verification against checksum sidecar files at startup, with a stricter required mode available through configuration.
Hosted-service controls
The current service architecture includes controls that are visible in the codebase.
Per-user and per-workspace state boundaries
Hosted settings, topology, profiles, squads, session access, and event routing are scoped per authenticated user or workspace context rather than exposed as broad shared state.
Secure session storage and revocation
Application sessions are stored in managed server-side storage and can be revoked. Browser sign-out clears the soundOS application session in addition to the front-end auth state.
Concurrency and mutation safety
Account settings writes use revision-aware mutation handling and idempotency controls in the current service layer. That reduces accidental overwrite risk for synced settings.
Event fanout through controlled services
Live event delivery is routed through managed service components rather than exposed as open public broadcast channels.
Voice, transcripts, artifacts, and evidence
Voice features are one of the most security-sensitive areas of soundOS because they can involve live audio, transcripts, action candidates, approvals, receipts, and evidence records.
The current codebase includes controls such as:
- short-lived WebSocket session tokens for voice connections
- origin restrictions for current application surfaces
- signed internal routes for projection, evidence, retained-audio handling, and artifact playback
- dedicated R2-backed storage for retained audio, receipts, and TTS artifacts
- queue-based durable processing for finalized turn workflows
This design supports structured receipts and audit-friendly lineage for voice-driven actions, but you should still treat voice-enabled workflows as sensitive and use them only where appropriate for your environment and data.
Logging and operational visibility
soundOS maintains operational logging, event flow, and runtime state needed to keep the product functioning and to troubleshoot failures.
That may include:
- request and session metadata
- health and error information
- event-stream activity
- execution and workflow status
- voice-session lifecycle records
Retention and detail vary by component and feature.
Shared responsibility
Security in soundOS is shared.
You are responsible for:
- protecting your account credentials
- controlling who can access your workspaces and devices
- reviewing commands, prompts, automations, and outputs before relying on them
- deciding what data is appropriate to process through voice, hosted services, or third-party providers
- removing locally stored provider keys you no longer want the desktop app to use
- keeping your own machines, browsers, and operating environments secure
If you enable local execution or connect third-party providers, you are responsible for the consequences of those choices in your own environment.
Reporting security issues
If you believe you have found a security vulnerability in soundOS, report it to:
Please include enough detail for us to reproduce and assess the issue, such as:
- affected route, surface, or component
- reproduction steps
- expected vs. actual behavior
- potential impact
- screenshots, logs, or request details where helpful
Please do not publicly disclose unpatched vulnerabilities without giving us a reasonable opportunity to investigate and respond.
Contact
SemSwitch, Inc.
8 The Green, Suite B
Dover, DE 19901
legal@semswitch.com