Public summary

System architecture

Public summary of how Rahoto is structured. The full document — with trust boundaries diagrammed, internal services named, and operational hooks specified — is available under NDA during procurement.

Audience
Enterprise security teams, procurement, auditors (full version)
Last reviewed
2026-05-16

What this page is

A public summary of Rahoto’s system architecture. We don’t publish the full document on the open web — it names internal services, data flows, and key store locations that we don’t want indexed for either competitors or attackers. The complete architecture document is shared under NDA during the procurement security review. Email [email protected] and we’ll send it within one business day.

What follows is what we can say in public and what your security team usually needs to assess vendor risk at the proposal stage.

Trust boundaries

Rahoto’s architecture is organized into six trust boundaries. Crossing a boundary requires authentication, authorization, and (where relevant) encryption. The boundaries cover:

  • The public internet edge into our application tier
  • The application tier into our primary data tier
  • The application tier into customer-managed storage
  • The application tier into third-party data connectors
  • Customer VPC agents (mTLS) into the application tier — enrollment contract and certificate pinning built; the deployable agent is in design-partner preview
  • Administrative access (break-glass, audit-export)

Every boundary has documented authentication, authorization, and audit requirements. The full document lists each policy, the enforcing service, and the test that verifies it.

Identity sources we accept

  • OAuth 2.0 (Google, GitHub, Microsoft)
  • SAML 2.0 (any identity provider that speaks standard SAML)
  • OIDC (any OIDC-compliant provider)
  • SCIM 2.0 for directory sync
  • CAC / PIV smart cards (gov pilots)
  • Username + password (disable-able per organization with verified domain)

Tenant isolation

  • Every multi-tenant table is protected by PostgreSQL row-level security
  • Every request enters a tenant context that the database enforces, not just the application
  • Customer keys (BYOK) are encrypted independently per organization
  • Audit logs are partitioned per organization and immutable

Where your data lives

  • Primary region pinned per organization (EU or US, others on request)
  • Secondary region for backup, configurable
  • Customer warehouses are read-only sources — Rahoto does not move warehouse data to our infrastructure unless a published report explicitly requires it
  • Sub-processor list with DPA status is public here

Key engineering commitments

  • All data at rest encrypted (AES-256-GCM); bring-your-own-key supported via four KMS providers
  • All data in transit encrypted (TLS 1.2 minimum, TLS 1.3 preferred)
  • Audit log is append-only and hash-chained — daily integrity verification with tamper alerts
  • Vulnerability response SLAs are public here and quotable in MSAs
  • FIPS mode enforceable per environment (required for GovCloud deploys)

What this summary deliberately does not cover

  • Internal service names, file paths, function signatures
  • Specific data flow diagrams for the publish pipeline
  • Exact storage layout of audit logs and KMS audit trail
  • Authentication token formats, rotation cadence, signing keys
  • Network topology, internal subnets, load-balancer configuration
  • Continuous monitoring beacon destinations and signal types

These are in the NDA-gated document. They’re not secret because they’re a vulnerability — they’re under NDA because exposing them lets a competitor copy the implementation and lets an attacker shortcut reconnaissance.

How to get the full document

Email [email protected] with your company name and a brief description of the engagement (procurement evaluation, security review, audit, etc.). We’ll send the full architecture document, the STRIDE threat model, and the latest pen-test summary as a single bundle, under a mutual NDA, within one business day.

If you’re already at the questionnaire stage, attach your questionnaire — we typically return it in 3–5 business days with documentation references to specific sections.