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

# Trust & compliance

> Encryption, authentication hardening, isolation, and the platform's security posture.

This page summarizes Karta's security posture for teams evaluating the platform.
The live trust page at [karta.sh/trust](https://karta.sh/trust) carries current
trust, policy, and sub-processor details. For uptime and incidents, use
[status.karta.sh](https://status.karta.sh).

For a full enterprise review path, start with
[Production architecture review](/security/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

| Area               | Karta control                                                                                                             | Customer control                                                                              | Review evidence                                                                           |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Server credentials | API keys are digested, scoped, revocable, and expire when configured.                                                     | Keep `kt_live_...` keys server-side, scope them narrowly, and rotate them after exposure.     | [API keys](/platform/api-keys), [API authentication](/api-reference/authentication)       |
| Browser access     | Browser callers use short-lived session tokens or publishable embed keys fenced by allowed origins.                       | Never ship a server API key to a browser; use verified identity when user identity matters.   | [Session tokens](/security/session-tokens), [Chat widget security](/security/chat-widget) |
| Agent execution    | Sessions run in isolated runtime environments, scoped to one session and karta.                                           | Keep agent tools least-privilege and require approvals or handoff for destructive actions.    | [Security model](/security/security-model), [Inputs](/api-reference/inputs)               |
| Model credentials  | BYOK provider keys are encrypted at rest and scrubbed from logs and errors.                                               | Choose managed model access or BYOK based on provider contracts, data terms, and rate limits. | [BYOK](/platform/byok)                                                                    |
| Spend controls     | Requests are gated when credits, budgets, key limits, user caps, karta caps, seat caps, or widget ceilings are exhausted. | Set caps before launch and route threshold webhooks to the team that can act.                 | [Usage & budgets](/platform/usage-and-budgets), [Webhooks](/platform/webhooks)            |
| Account changes    | Material changes write immutable audit events.                                                                            | Review audit events, export them when needed, and set internal retention policy.              | [Audit log](/platform/audit-log)                                                          |
| Webhooks           | Deliveries are signed and unsafe delivery targets are rejected before send.                                               | Verify signatures, use HTTPS endpoints, and monitor delivery failures.                        | [Webhooks](/platform/webhooks)                                                            |

## Encryption

<Columns cols={2}>
  <Card title="At rest" icon="lock">
    `kt_live_` API keys are stored as one-way digests. BYOK provider keys are
    encrypted at rest.
  </Card>

  <Card title="In transit" icon="lock-keyhole">
    HTTPS everywhere, HSTS (preload-eligible), a strict CSP with no wildcard
    `script-src`, and `frame-ancestors: none`.
  </Card>
</Columns>

## 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](/concepts/how-karta-works#per-session-isolation).
* **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](/concepts/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](/security/session-tokens)
  your backend mints server-side.
* **API keys carry explicit [scopes](/platform/api-keys)**, 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](/platform/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](/platform/audit-log). 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](/platform/audit-log), and
[BYOK](/platform/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](https://karta.sh/trust) for the current contact and scope.

<CardGroup cols={2}>
  <Card title="Production architecture review" icon="shield-halved" href="/security/architecture-review">
    The checklist for platform and security teams evaluating a launch.
  </Card>

  <Card title="Security model" icon="user-shield" href="/security/security-model">
    Prompt injection assumptions, boundaries, credentials, and residual risks.
  </Card>

  <Card title="Session tokens" icon="ticket" href="/security/session-tokens">
    The browser-safe credential and what it pins.
  </Card>

  <Card title="Audit log" icon="scroll" href="/platform/audit-log">
    Immutable record of every account change.
  </Card>
</CardGroup>