karta
// platform / your cloud

The data plane in your cloud account.

Run your agents' durable computers inside your own AWS account. Workspace content, per-user state, and model traffic stay inside your boundary, and you keep the managed experience: Karta operates the platform without inbound access to your environment.

Early access · design partners
// who needs it

When the data cannot leave.

Compliance boundaries

Regulated workloads where agent workspaces - files, memory, work product - must stay inside an account you control and audit.

Security review friction

Your review gets a short answer to "where does the data live": in our account, operated through an outbound-only connection.

Your cloud economics

Data-plane infrastructure runs on your bill, so committed-use discounts and credits apply, and inference can run against your own provider agreements.

Network control

Your VPC, your network policy, your flow logs. You can audit the traffic without asking us.

// how it works

Split planes, one direction.

Karta keeps operating the control plane; the data plane - where agents actually run and store work - lives in your account and dials out. There is no inbound path into your environment.

Karta's account · control plane
  • · Console, API, and identity
  • · Release orchestration and rollback
  • · Metering, budgets, and billing
  • · Account, agent, and session metadata
Your account · data plane
  • · Durable workspaces: files, memory, artifacts
  • · Isolated per-session execution
  • · Model traffic, on your provider agreements
  • · Connects outbound-only to the control plane

your account ── outbound TLS ──▶ control plane   (no inbound path, no SSH, no VPN)

// access model

What crosses the boundary, and what never does.

Crosses to Karta

  • · API-key validation and session metadata
  • · Usage and metering events
  • · Release and deployment coordination

Never leaves your account

  • · Workspace content and agent memory
  • · Conversation and file data
  • · Model prompts and responses
  • · Your cloud and provider credentials

Provisioning is customer-owned, from a versioned infrastructure module you can read before you run it. Access is scoped cross-account IAM with a per-tenant external id - no static keys, and nothing interactive.

// straight answers

Should you use BYOC?

Probably not first. Karta Cloud is the fastest path to production and carries the same isolation model; most teams meet their requirements there. BYOC is for organizations with a hard boundary requirement - residency, regulator, or contract - and it currently means working with us as a design partner: we stand up your install together, on AWS first.

Common questions

Does Karta have access to our cloud account?

No interactive access: no SSH, no VPN, no inbound path. Coordination happens over an outbound connection your install initiates, plus scoped cross-account IAM you can read and revoke.

What happens if the connection to the control plane drops?

Your data stays where it is, in your account. The install reconnects outbound; nothing about the outage grants or requires access.

How does billing work?

Two bills: your cloud provider bills you for data-plane infrastructure directly, and Karta bills platform usage. Your committed-use discounts and credits apply to the infrastructure.

Which clouds are supported?

AWS first, with design partners. Tell us what you run; that is exactly the signal that sequences what we build next.

Keep the boundary. Keep the managed experience.