Security & privacy

Symorva's security model starts from ownership: community data lives in the operator's deployment, and every shared service receives only what a single request needs. On top of that, each module states exactly what it protects and what it does not. This page collects those statements and the controls around them.

Protections marked preview are part of the module design and are not yet running in the reference deployment; see Status & roadmap.

Trust boundariesCopy Anchor Link

Module protectionsCopy Anchor Link

The deployment plan returns one protection statement per enabled module:

What the protections do not implyCopy Anchor Link

• Chat encryption does not make meetings, AI inference, wallet operations or partner apps end-to-end encrypted.
• Chat encryption does not hide metadata: who communicates with whom, when, in which groups, and message sizes.
• TEE key protection does not make on-chain transactions anonymous and does not imply any particular custody model. Exact key handling depends on the wallet implementation.
• Meeting media is encrypted in transit, not end to end.
• Content a member forwards, reports or grants to the assistant is readable at its destination.

When chat.e2ee is off, validation warns with privacy.e2ee-off. Operators running without encryption should tell members that message content is readable by the community server. The reference deployment's messaging runs without end-to-end encryption today and enforces content policy on the server before delivery.

Accounts and sessionsCopy Anchor Link

The controls below run in the reference deployment:

• Session and device management. Members see their signed-in devices; operators and members can end sessions, and a forced sign-out takes effect on the device.
• Verification codes. Sign-in and sensitive changes are confirmed with one-time codes. Development environments may use fixed test codes; staging and production never do.
• Login policy. Operators configure sign-in policy, allowlists and restrictions in the admin console.
• Payment confirmation. Payment PINs are encrypted on the device with the server's public key; biometric confirmation is enabled only when the server advertises a protocol for it.
• Account isolation on devices. Client caches are bound to the signed-in account. Signing out or switching accounts cancels outstanding work, discards late results and clears account-scoped caches, so one account's data is never shown under another.

Operator controlsCopy Anchor Link

• Role-based console access. Every console route requires a permission key. Permission keys are registered by managed migrations in the same change that adds the route, so a new database has the complete catalogue and no route is left unguarded.
• Audit trail. Operator actions are recorded with the acting user, taken from the authenticated console session. Configuration changes record before and after values and a revision.
• Optimistic concurrency. Edits must submit the revision they read; a stale revision is rejected instead of silently overwriting another operator's change.
• Withdrawal review. Withdrawals can require operator review before they are executed.
• No content access by construction. The Server API has no endpoint to read message content, create AI grants or move member funds.

Money and integrityCopy Anchor Link

• Idempotent commands. Every money-moving command carries a stable request id; replays return the original result.
• Unknown outcomes are queried. A command with an unknown outcome is never resent automatically.
• Double-entry ledger. Balances are derived from balanced postings, never edited directly.
• Restore invariants. Restored backups are checked — postings balanced and paired, references resolved, no negative balances — before use.
• Separated custody. Key operations run in a separately deployed boundary with its own databases and explicit policies for networks, purposes and amounts. TEE protection for that boundary is the wallet module's preview design.

Platform hygieneCopy Anchor Link

• Secrets outside source. Secrets, certificates and signing material live only in secret stores or generated runtime directories excluded from version control.
• Credential scanning. Repositories are scanned with a pinned scanner. Reviewed exceptions are recorded by file hash, classification and rationale; any byte change triggers a new review.
• Pinned dependencies. Third-party images are locked by digest; releases record the source revision behind each image.
• Explicit migrations. Schema changes ship only as managed, versioned migrations that run before a service starts; no manual SQL against shared databases.
• Isolated environments. Development, staging and production never share data, credentials or app identifiers.

Reporting a vulnerabilityCopy Anchor Link

Report suspected vulnerabilities privately to the Symorva team through your design-partner contact. Please do not disclose them publicly until the team has confirmed a fix.

No third-party certifications or audits are claimed in this documentation.