Skip to main content
This page summarizes Karta’s security posture for teams evaluating the platform. The live trust page at karta.sh/trust carries current trust, policy, and sub-processor details. For uptime and incidents, use status.karta.sh. For a full enterprise review path, start with Production architecture review. It links the trust posture here to the request path, credential model, spend gates, release controls, webhooks, audit, and operational failure modes.

​
Responsibility map

​
Encryption

At rest

kt_live_ API keys are stored as one-way digests. BYOK provider keys are encrypted at rest.

In transit

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

​
Authentication hardening

  • Email confirmation, account lockout, and login tracking, plus a breached- password (HIBP) check at sign-up and password change.
  • Second factor via TOTP (encrypted secret + 10 one-time recovery codes) and WebAuthn passkeys (bound to allowed hosts, with sign-counter replay protection).
  • For accounts with a second factor enrolled, sensitive actions (API key, BYOK, webhook, and billing changes) require a recent step-up re-authentication (15-minute freshness).

​
Isolation

  • Every session runs in its own per-session isolated runtime environment, so a running agent is bounded to its current session and karta rather than sharing a process with other tenants. See How Karta works.
  • Default-deny cross-org access; session ownership is durably recorded, so one org’s key cannot reach another org’s sessions even by guessing IDs. See Multi-tenancy.
  • Agents are treated as their own actor. A running karta for one user, virtual employee, backend job, or fleet member has authority scoped to its session and configured identity, not the platform. A team can own a roster of kartas without collapsing their workspaces together, so a prompt-injected or misbehaving karta is contained to its own boundary.

​
Credential boundaries

  • End users never hold a Karta API key. The only credential that reaches a browser is a short-lived, agent-scoped session token your backend mints server-side.
  • API keys carry explicit scopes, including fine-grained scopes such as releases:write, webhooks:write, audit_log:export, and model_keys:write, so each integration holds only the authority it needs.

​
Secrets

Secrets are never logged, never put on spans, and scrubbed from error reports. Known key formats and bearer-token patterns are redacted, and authorization headers are guarded against capture.

​
Outbound webhooks

Webhooks are signed and protected by destination checks that reject unsafe delivery targets before events are sent.

​
Audit

Every material change to your account writes an immutable audit event. Entries cannot be edited or deleted after the fact.

​
Rate limiting & abuse

Per-IP throttles on login, signup, password reset, key minting, and checkout, with a public abuse-reporting path.

​
Operator access

Karta’s systems process the content your agents handle. Karta’s posture is that operators do not read customer content during normal operations: access is minimized and logged, backed by the audit log, and BYOK keeps your model-provider credentials under your own control.

​
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.

Production architecture review

The checklist for platform and security teams evaluating a launch.

Security model

Prompt injection assumptions, boundaries, credentials, and residual risks.

Session tokens

The browser-safe credential and what it pins.

Audit log

Immutable record of every account change.