Security

Security

Monocrat is in private beta and v1 launch preparation. This page describes intended and launch-required controls. It is not a SOC 2, ISO, PCI, HIPAA, or other certification claim.

Security Principles

• Tenant isolation is a product requirement, not an optimization.
• Owner authority comes from the server-side session and tenant record, not client claims.
• Missing, stale, conflicting, unauthorized, or low-confidence evidence blocks high-stakes actions.
• Push, email, and app-link notices may wake the owner up, but authenticated web/app review is required for sensitive decisions.
• Public trust claims require evidence, freshness, consent or publication authority, and review checks.

Access Model

The launch account model uses one verified business owner-operator account per tenant. That owner controls source connections, app/web sessions, Billing & Usage authority, Stripe payment-method decisions for Monocrat billing, Trust Graph consent decisions, account lifecycle requests, and high-stakes approvals unless a later written agreement adds a different account model.

Tenant Isolation

Tenant-scoped product state is designed to carry tenant identifiers, row-level security, source refs, and audit metadata. Operational state is stored in tenant-scoped relational tables, and graph facts are written through tenant-scoped graph access patterns. Cross-tenant reads are restricted to explicitly approved policy paths with audit evidence.

Google And Source Access

The public waitlist uses identity-only Google OAuth scopes. Product onboarding for approved users may request Google Workspace access only through a separate source-onboarding flow. Broad self-serve Google Workspace OAuth remains private-beta gated until verification and review requirements are satisfied.

Source credentials and secrets are not displayed in product UI. Connected-source health, freshness, degraded states, and disconnect actions are shown through server-authoritative settings and review surfaces. See the Connected Sources Policy.

Data Boundaries

Monocrat separates business records, source refs, provider evidence, billing ledgers, public Trust Graph claims, support/debug records, security logs, and internal provider-cost records. Customer-facing Billing & Usage surfaces show Monocrat usage credits, invoices, receipts, adjustments, and disputes, not internal provider COGS or per-call model routing.

High-Stakes Action Controls

Actions involving money movement, payment, refund, payroll, tax, legal commitments, public publication, customer promises, source-system writes, account deletion, privacy, or security require the owning action gate. Review packages are bound to source refs, package or payload hashes, idempotency keys, owner session evidence, and audit records where applicable.

Support And Admin Access

Support is a recovery channel, not a substitute for the owner account. Support may use redacted summaries, billing state, connector health, structured errors, audit summaries, and case-bound operational status. Raw private business content, source documents, message bodies, customer PII, raw graph excerpts, provider payload bodies, and prompt/LLM transcripts require scoped break-glass approval for a specific tenant, case, purpose, and time window.

See the Support & Admin Access Policy for customer-facing support, recovery, case binding, no-impersonation, and break-glass commitments.

Trust Graph Publication Security

Public Trust Graph claims require source refs, freshness, provenance, consent or publication authority, privacy/safety review, and action-gate audit. Counterparty triggers, private source details, deletion reasons, and sensitive relationship metadata are not exposed through public graph output. See the Trust Graph Publication Policy.

Billing And Payment Security

Monocrat uses Stripe for Monocrat subscription billing, payment methods, invoices, receipts, direct usage charges, refunds, disputes, and Customer Portal sessions. Stripe stores payment instruments. Monocrat stores Stripe object references, immutable invoice/receipt snapshots, webhook event IDs, and reconciliation state.

Monocrat public pages and payment-entry flows are required to use HTTPS. Payment card entry is handled through Stripe-hosted or Stripe-controlled payment surfaces, and Monocrat does not store full card numbers or card security codes. PCI responsibilities are shared between Monocrat, Stripe, and the customer according to the selected Stripe integration and each party's role.

Incident And Vulnerability Reporting

Report suspected vulnerabilities or security issues to security@monocrat.ai. Include the affected URL, account context if relevant, reproduction steps, impact, and your contact information. Please do not access, modify, delete, export, or disclose data that is not yours.

Current Beta Notes

• Private beta access is invitation-based.
• Some integrations may be allowlisted, degraded, manual, or disabled.
• Fixture, sandbox, or demo data does not count as production readiness for real customer-source paths.
• Security, privacy, billing, DPA, and legal artifacts still require the applicable human approval before first paying tenant launch.