Hardened by design. Yours, by default.

BetterAuth at the front door

Every identity flow — sessions, API keys, OAuth, SAML, OIDC — routes through BetterAuth. The user table lives on your Postgres, not ours. MFA is supported out of the box with TOTP and WebAuthn.

• Session tokens: HTTP-only, Secure, SameSite=Strict cookies
• API keys scoped to project + tenant with configurable expiry
• Self-hosted user table on your own Postgres instance
• MFA support via TOTP (authenticator apps) and WebAuthn (passkeys, hardware keys)

SpiceDB / Zanzibar for permissions

Every read and every write is a permissions check against SpiceDB, Google's Zanzibar-inspired authorization system. The schema lives in your repo; the relations live in your tenant. Supports RBAC, ABAC, and resource-level permissions.

• Model: subject → relation → resource (e.g., user:alice#viewer@repo:acme)
• Schema versioned alongside application code in your repository
• Per-tenant relation tuples for complete data isolation
• Supports RBAC roles, ABAC attributes, and fine-grained resource permissions

definition user {}

definition project {
  relation owner: user
  relation editor: user
  relation viewer: user

  permission admin = owner
  permission write = editor + owner
  permission read  = viewer + write
}

definition repo {
  relation parent: project
  relation maintainer: user

  permission push  = maintainer + parent->write
  permission view  = parent->read
}

HMAC-SHA256 on every event

Every payload entering Cuitty is signed with a per-project webhook secret using HMAC-SHA256. The signature is verified at the edge before the event reaches any persistence layer. Replay attacks are mitigated with a nonce and a 5-minute timestamp window.

• Per-project webhook secret used for HMAC-SHA256 signing
• Edge verification before any persistence or module processing
• Replay protection: nonce + 5-minute timestamp window
• Signatures stored alongside payloads for offline verification and forensics

Tamper-evident audit chain

Every admin action produces an audit entry containing the actor, action, resource, timestamp, a SHA-256 hash, and a pointer to the previous hash. The chain is cryptographically linked so any gap or mutation is detectable.

• Fields: actor, action, resource, timestamp, hash, previous_hash
• Cryptographically linked chain — any gap or mutation is detectable
• Cloud: weekly Sigstore transparency log notarization
• Self-hosted: cui audit verify CLI command for local chain verification

Findings, never material

The secrets module ingests detector findings — file path, line number, detector name — not the secret values themselves. Retrieval is backed by 1Password CLI. Pilot-captured secrets are redacted before artifact persistence.

• Ingests detector findings (file path, line, detector name), never raw values
• Backed by 1Password CLI for secure retrieval when needed
• Pilot-captured secrets redacted before artifact persistence
• Regex-based redaction applied to all log, trace, and error payloads

TLS everywhere

TLS 1.2+ is enforced on every endpoint. Cloud certificates auto-renew via Let’s Encrypt. Self-hosted deployments can bring their own certs or use the bundled ACME client. All inter-service communication uses mTLS.

• TLS 1.2+ enforced on every public and internal endpoint
• Cloud: Let’s Encrypt with automatic certificate renewal
• Self-hosted: bring-your-own certificates or bundled ACME client
• mTLS between all Cuitty services; WebSocket endpoints are WSS-only