Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.karta.sh/llms.txt

Use this file to discover all available pages before exploring further.

This page summarizes Karta’s security posture for developers evaluating the platform. The live trust page at karta.sh/trust carries current status and sub-processor details.

​
Encryption

At rest

kt_live_ API keys stored as bcrypt digests; BYOK provider keys AES-256 encrypted via Rails MessageEncryptor with a domain-separated purpose.

In transit

HTTPS everywhere, HSTS (preload-eligible), a strict CSP with no wildcard script-src, and frame-ancestors: none.

​
Authentication hardening

  • Devise with confirmable, lockable, trackable, plus a HIBP breached-password check.
  • Second factor via TOTP (encrypted secret + 10 one-time recovery codes) and WebAuthn passkeys (bound to allowed hosts, with sign-counter replay protection).
  • Step-up required for sensitive actions.

​
Tenant isolation & secrets

  • Default-deny cross-org access; session ownership is durably recorded. See Multi-tenancy.
  • Secrets are never logged, never put on spans, and scrubbed from error reports — kt_live_*, sk-ant-*, whsec_*, and bare Bearer … patterns are redacted. Header capture of authorization is explicitly guarded against.

​
The internal surface

Cross-plane internal endpoints are defended in depth: a service token and an IP allowlist and a Host allowlist. A leaked token replayed off-network or against the public host gets a 404, not the controller. Unsafe configuration (a missing host allowlist) raises at boot rather than shipping silently insecure.

​
Outbound webhooks

Webhooks are signed HMAC-SHA256 and protected by an SSRF guard that validates statically at write time and re-resolves DNS at delivery time, pinning the socket to the resolved IP to defeat DNS rebinding.

​
Audit

Every material mutation writes an immutable audit event in the same transaction, locked at both the application and database-trigger level.

​
Rate limiting & abuse

Per-IP throttles (Rack::Attack) on login, signup, password reset, key minting, and checkout, with a public abuse-reporting path. The webhook receiver is IP allowlisted to the payment provider.

​
Reporting a vulnerability

Karta publishes an RFC 9116 /.well-known/security.txt and a vulnerability-disclosure policy with safe-harbor terms. See karta.sh/trust for the current contact and scope.
The biggest open trust item is operator access to tenant content — addressed by BYOK-based encryption and an operators-don’t-read policy, flagged for a dedicated security audit. See Personas → the trust claim.