Skip to main content
Karta assumes agents execute user-influenced work. Prompt steering, hostile retrieved content, and bad tool choices are expected inputs. The security model is containment: a bad turn should be bounded to the current session, karta, credentials, spend limits, and tool permissions instead of becoming account-wide authority.

​
Assumptions

  • End users can send hostile or confusing instructions.
  • Retrieved content, files, and tool results can contain prompt-injection text.
  • An agent may make a bad tool call unless a permission boundary stops it.
  • Browser credentials may leak, so browser credentials must be short-lived and narrowly scoped.
  • A production integration needs budget, audit, rollback, and troubleshooting controls before it handles real users.

​
Boundaries

​
Prompt injection and tool use

Treat prompt injection as expected input, not an exceptional event. Karta’s job is to keep the blast radius small:
  • A running session does not inherit your account administrator privileges.
  • End-user browsers do not receive a kt_live_... API key.
  • Approval prompts can pause a turn before a tool action proceeds.
  • Sessions and kartas are scoped by organization and agent, so guessed IDs do not cross tenant boundaries.
  • Spend caps can stop runaway loops before another turn executes.
Your agent project still owns its own tool design. Keep tool scopes narrow, prefer read-only tools where possible, and make destructive tools require approval or first-party handoff.

​
Credentials

Use the narrowest credential that can do the job. See API authentication for route-family compatibility and Session tokens for the browser flow.

​
Network and data exposure

Karta can only enforce boundaries around the platform surface. If your agent has tools that call your own services, your service authorization still matters.
  • Do not trust a soft userId from the browser to authorize access to your own systems. Use verified identity.
  • Do not put provider keys, API keys, identity-verification secrets, or webhook signing secrets in browser code.
  • Document what user content your widget sends to Karta and the model provider backing the agent. The chat widget security page has disclosure guidance.
  • Use BYOK when your policy requires model-provider credentials under your own provider account. See BYOK.

​
Operator access

Running an agent platform means Karta’s systems process the content your agents handle. The trust commitment is minimization: operators should not read customer content as part of normal operations, access should be limited and logged, and material account changes should land in the audit log. Review the current public trust posture at karta.sh/trust.

​
Residual risks

No platform boundary removes the need to design the agent carefully.
  • A tool with broad authority can still do broad damage inside the authority you gave it.
  • A shared karta intentionally shares memory between everyone who uses that id.
  • A browser session token is narrow and short-lived, but it is still a bearer token for its lifetime.
  • BYOK keeps provider credentials under your account, but your provider may still process prompts and outputs under its own terms.
  • Logs, transcripts, and workspace exports should be enabled and retained only according to your own policy.
For the full production review sequence, use Production architecture review and Production readiness.