Security & data-handling overview

Audience: security reviewers, CISOs, compliance and procurement teams evaluating a product built on the CMC platform. This is a factual engineering statement of posture, not marketing and not legal advice. Operators: have your counsel review this alongside your own Terms of Service and Privacy Policy before relying on it contractually — those legal documents are yours, not CMC's.

Identity & authentication

• Identity is delegated to a dedicated OIDC provider (Zitadel, self-hosted per deployment). Application surfaces never receive or store passwords; sessions are server-side with opaque HttpOnly/Secure cookies. MFA is available to every account.
• Service-to-service and client authorization uses short-lived signed JWTs; messaging-layer permissions are per-connection NATS JWTs minted from a deployment-local signing chain (decentralized operator model). Offline/edge credentials are pre-minted, signed, and verifiable without a network round trip.
• Authorization is attribute-based, computed mechanically from platform claims. Per-user isolation is enforced at the message broker on every publish/subscribe — subject-level grants, not application-side checks.

Encryption & data at rest

• In transit: TLS on all public surfaces; broker connections authenticated per-connection.
• At rest: user content (messages, posts, media) is stored platform-readable by design — content moderation (report review) and channel bridging (re-rendering messages into external networks) require it. No end-to-end encryption is claimed anywhere in the product, and product copy is required to state this posture verbatim: transport-encrypted, platform-readable.
• Media is stored by reference in an object store; access honors the referencing content's visibility on every request.

Payments (PCI scope)

• All card handling is delegated to Stripe (Elements/hosted surfaces + Connect for seller payouts). Primary account numbers and CVCs never transit or persist on platform systems — stored-card references are Stripe tokens plus display metadata (brand, last4, expiry). Target PCI posture: SAQ-A.
• Off-session charges require explicit recorded consent per stored card; charge outcomes are returned as platform-defined categories, never raw processor declines.

Moderation & administrative access

• Reports snapshot content at report time; snapshots are reviewable by the moderators of the owning organization (org-scoped content) or platform operators (platform-scoped content).
• Every moderation action lands in an append-only ledger (actor, authority, action) with UPDATE/DELETE revoked at the database layer.
• Removed content is tombstoned (structure-preserving marker), never silently deleted.
• Direct messages are not accessible to organization staff; they enter review only via a participant's report.

Abuse & availability controls

• Per-user sliding-window rate limits on every write surface; per-address rate limits on unauthenticated inbound (bridge pairing).
• Notification delivery is storm-controlled by design: signature deduplication, escalating digest windows, hard per-recipient channel budgets, and a circuit breaker that collapses event floods into a single updating notification.
• Services are distroless containers with health probes, structured audit-grade logging (correlation IDs), and self-describing introspection manifests.

Subprocessors & external networks

• Stripe — payment processing and seller payouts.
• Optional, per deployment: Telegram (bridged messaging), Slack (planned), Twilio/SMS (planned), an email provider (when enabled). Bridged messages traverse the chosen external network under that network's own terms; users opt in per channel and can revoke pairing at any time. Unpaired external senders are inert.

Disclosure

Security contact: the operator of this deployment. Reports are welcomed; please include reproduction detail. (Operators: set this value in your deployment's branding/config.)