How Karta protects agent data.
Karta deploys agents as dedicated specialists with files, transcripts, credentials, tool outputs, sessions, and durable workspace. The trust model is built around isolating each karta, governing who can access it, and keeping model and tool credentials under explicit policy.
Refreshed automatically from Karta service health. Full uptime history and incidents at status.karta.sh.
Karta isolation
A karta is the durable boundary for one user-agent relationship, a virtual employee or role in a team-owned roster, one backend job, or one fleet member. Teams can own rosters of kartas; each karta still has its own workspace and access boundary. Sessions route into the right karta through verified identity, a backend-supplied agent_instance_id, or server-side embed configuration - not public browser metadata.
- · durable workspaces are scoped by org, agent, and karta
- · public widgets cannot redirect themselves to another workspace
- · workspace inspection is default-off, MFA-gated, and audited
Per-session isolation
Agent turns run in isolated execution environments attached to the karta's durable workspace. Customer agent code and tool calls stay outside the control plane that manages account, billing, audit, and organization metadata.
- · releases materialize in the execution plane
- · the control plane authorizes identity, budget, and release state
- · agent authority is scoped to the current karta and session
Control / data plane split
Karta separates platform metadata from the data plane that runs agent sessions and durable workspaces. For enterprise deployments, that boundary is the basis for BYOC: metadata reaches Karta's control plane, while customer content can remain in a data plane designed for the enterprise cloud account and network boundary.
- · control plane: identity, billing, audit, deploy metadata
- · data plane: agent sessions, transcripts, durable workspaces
- · BYOC terms and architecture are handled on Enterprise plans
Encryption
Customer API keys are stored as one-way digests - we never see the plaintext after creation. BYOK provider keys, webhook secrets, agent environment variables, and MFA secrets are encrypted at rest with domain-separated key material.
- · one-way digests for customer API keys
- · AES-256-GCM for decryptable secrets
- · full secret values are shown exactly once
Bring-your-own-key
On the Pro and Enterprise plans you can register your own Anthropic or OpenAI key. Karta encrypts on write, decrypts only when brokering the model request, and never logs plaintext. Rotation and revocation are self-service.
- · key material is scoped to the organization and provider
- · revoked keys stop new model requests
- · last-four shown in UI; full value never returned
TLS, CSP, HSTS
HTTPS is enforced in production with HSTS preload eligibility. The public site and console use a strict Content Security Policy with nonce-based scripts, plus frame-ancestor protections for clickjacking defense.
- · HSTS: max-age=31536000; includeSubDomains; preload
- · CSP nonces on every script tag; report-uri active
- · Webhooks refuse non-HTTPS and re-resolve at delivery
MFA: TOTP + WebAuthn
Every account can enroll a TOTP authenticator and one or more WebAuthn passkeys. Step-up auth is required for sensitive admin actions (deleting an org, rotating BYOK, viewing the audit export).
- · RFC 6238 TOTP, 30-second window, replay-protected
- · WebAuthn/FIDO2 passkeys with userVerification: preferred
- · Step-up via separate session flag, ~5 min freshness window
Audit log
Every key mint, key revoke, login, plan change, and budget event lands in an append-only audit log. Application and database-level controls enforce immutability so audit records cannot be edited or deleted by ordinary product paths.
- · append-only audit records for sensitive account activity
- · retained at least 1 year; exportable on request
Rate limits
Karta applies per-IP and per-account throttles to login, signup, password reset, key minting, and checkout. Provider webhooks are validated before use. Public abuse reporting at /abuse.
Sub-processors
Karta contracts these vendors as sub-processors and updates this list whenever a new vendor is onboarded.
| Vendor | Purpose | Data processed | Contact-of-record | Location |
|---|---|---|---|---|
| Stripe | Payments and subscription billing | Billing email, last 4 of card, charge amounts | privacy@stripe.com | United States (us-west) |
| Anthropic | LLM inference for non-BYOK requests | Prompt and response payloads proxied through karta-python | privacy@anthropic.com | United States |
| Hetzner Online GmbH | Control plane hosting and primary Postgres (accounts, organizations, billing, audit log) | Primary application database at rest - account, billing, and audit records | data-protection@hetzner.com | United States (Hillsboro, Oregon) |
| AWS (Amazon Web Services) | Data plane - agent session compute (Bedrock AgentCore), durable workspace/merge store (S3), per-session + transcript database (RDS) | Agent session state, workspace and merge artifacts, and hosted-chat transcripts at rest - encrypted with provider-managed keys | aws-privacy@amazon.com | us-east-1 |
| Postmark | Transactional email (confirmation, password reset, abuse reports) | Recipient email address, email body | privacy@postmarkapp.com | United States |
| Sentry | Application error monitoring and performance telemetry | Account/tenant identifiers (organization ID, user ID, role) and server-side error and performance diagnostics attached to exceptions and traces; secret values are scrubbed | privacy@sentry.io | United States |
Compliance
SOC 2 Type I targeting Q4 2026. Annual pen test. Disclose security issues per /.well-known/security.txt or the security policy. Bug bounty alongside Type I.