Security Architecture

Deep dive for security teams.

Technical architecture document for security, IT, and compliance reviewers. Goes beyond the SOC 2 letter — explains the design decisions, the threat models we considered, and how isolation is enforced at every layer.

Trust Center Email security@

Architecture pillars

6 layers of defense

Tenant isolation

Every customer is a logical tenant. All data access funnels through the org_id discriminator at the row level. Cross-tenant queries are blocked at the ORM layer and the database constraint layer.

Postgres row-level security policies enforce org_id matching on every SELECT, UPDATE, and DELETE — application code cannot accidentally cross tenant boundaries.
Read replicas inherit the same RLS policies. Backups are tenant-segregated for restore.
Background jobs carry org_id in the message envelope; workers refuse to process payloads without it.
S3-style object storage uses per-tenant prefix isolation with bucket-level policies that deny cross-tenant reads.

Threat model

Adversary: another customer's compromised account. Defense: RLS at DB + bucket policy at object store + worker-level org_id assertions. A bug at any single layer is caught by the others.

Encryption at rest + in transit

AES-256 at rest for all PII and customer-content data. TLS 1.3 in transit. Key rotation quarterly. Customer-managed keys (CMK) optional on Enterprise.

Application database, object storage, and backups: AES-256-GCM via cloud-provider KMS with per-org data-encryption-keys.
TLS 1.3 enforced site-wide with HSTS preload. Older protocols rejected at the load balancer.
Internal service-to-service calls use mTLS with rotated short-lived certificates (24h validity).
Customer-managed keys (BYOK) supported on Enterprise plans via AWS KMS / GCP CMEK / Azure Key Vault.
Certificate rotation automated; audit log entries record every rotation event.

Threat model

Adversary: cloud-provider operational read of cold storage, network MITM. Defense: encryption-at-rest with org-segmented DEKs, TLS 1.3 with HSTS, per-link certificate rotation.

Audit log immutability

All security-relevant actions write to an append-only audit log. Once written, records cannot be edited or deleted — even by platform engineers.

Audit log table uses Postgres before-update triggers that refuse mutation. Deletes blocked at row-level policy.
Hash-chain validation: each audit row carries the SHA-256 of the previous row, enabling tamper detection.
Audit log replicated to write-once S3 with object-lock (governance mode); compliance retention 7 years.
Every login, role change, data export, and admin action emits an audit event.
Customer-accessible read-only audit log via the /audit endpoint; full export available on Enterprise.

Threat model

Adversary: compromised internal employee attempting log redaction. Defense: schema-level mutation block, hash chain that fails to validate after redaction, replicated immutable storage on object-lock.

RBAC + scoping

Six built-in roles + custom roles on Enterprise. Per-project scoping. Per-action permissions checked at the API gateway and the data layer.

Built-in roles: Owner, Admin, Estimator, Reviewer, Viewer, External Auditor.
Project-level scoping limits role grants to specific projects (estimator A on project 1, viewer on project 2).
Permission checks at three layers: API gateway, service-layer middleware, database RLS — defense in depth.
Role changes captured in audit log with prior + new value.
MFA enforcement configurable per-role; required for Owner + Admin by default.
SSO via SAML 2.0 / OIDC on Pro and Enterprise; SCIM provisioning available.

Threat model

Adversary: privilege escalation via gateway bypass or role-grant audit gap. Defense: triple-layer permission checks, audit-logged grants, MFA required for elevated roles.

Secret management + key rotation

All secrets stored in HashiCorp Vault with dynamic-credentials issuance. Quarterly rotation. Zero secrets in environment variables or repos.

Vault is the single source of truth for service credentials, API keys, signing keys, and encryption keys.
Application services receive short-lived (24h) dynamic credentials via Vault agent — no long-lived secrets on disk.
Repository scans (TruffleHog + GitGuardian) run on every commit, blocking merges if secrets detected.
Quarterly forced rotation of all internal credentials. External integration tokens rotated per partner SLA.
Audit log captures every secret access; anomalous access triggers alerts.

Threat model

Adversary: leaked git history, compromised CI runner, stolen developer laptop. Defense: dynamic short-lived creds (max 24h blast radius), repo scanning, no static secrets at rest in app config.

AI + customer-data handling

Customer drawings, takeoff data, and project metadata are NEVER used to train shared models. Only opt-in customers contribute to platform-wide model improvements.

Per-customer recognizer models trained from each org's own annotations only. Models do not cross tenant boundaries.
OpenAI / Anthropic / Gemini API calls are made with zero-data-retention agreements (ZDR endpoints).
Customers can opt out of all third-party model providers entirely; OmniTakeoff falls back to in-house models.
Customers may opt into the platform-wide symbol-library improvement program; participation is per-feature, revocable, and surfaced in the admin console.
PII redaction applied to any drawing metadata before any external API call.

Threat model

Adversary: data leak via training set contamination, vendor data retention. Defense: per-tenant model isolation, zero-data-retention vendor configuration, opt-out toggle, PII redaction at the boundary.

Compliance

Attestations + retention

SOC 2 program

Annual SOC 2 program with an independent audit firm. Attestation reports are shared under NDA via the Trust Center. We do not publicly claim certifications we have not yet earned; ask security@ for current status.

GDPR + CCPA

Right-to-access export, right-to-erasure soft-delete with PII scrub, opt-out preference, DPA endpoint. EU/CA data residency on roadmap.

Federal procurement

Audit-log immutability + retention design is built to satisfy federal audit-trail requirements. Specific federal-procurement audit outcomes are not publicly published; they are shared under NDA with prospective federal customers via /trust-center.

Vendor security review?

We answer security questionnaires under NDA via the Trust Center.

Send us your vendor-security-review form (CAIQ, SIG, custom). SOC 2 program status (current Type I/II progress), penetration-test summary, and architecture diagrams shared under NDA via the Trust Center. We don't publish specific turnaround SLAs because timing depends on your form's complexity — we'll commit to a specific date in the response email.

Email security@Trust Center