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

# Security model

> How Karta thinks about prompt injection, execution isolation, credentials, tools, egress, operator access, and residual risk.

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

| Boundary            | What it protects                                                              | Where to configure or review it                                                                                  |
| ------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| Organization        | Account state, members, API keys, BYOK, budgets, billing, webhooks, audit     | [API keys](/platform/api-keys), [Usage & budgets](/platform/usage-and-budgets), [Audit log](/platform/audit-log) |
| Karta               | Durable workspace and memory for one user, role, backend job, or fleet member | [Kartas & memory](/concepts/instances-and-memory)                                                                |
| Session             | One active conversation and its current approval state                        | [Sessions & participants](/concepts/sessions-and-participants), [Inputs](/api-reference/inputs)                  |
| Runtime environment | Files, process state, and tool execution for one running session              | [How Karta works](/concepts/how-karta-works#per-session-isolation)                                               |
| Browser credential  | One agent and a short time window, not the whole org                          | [Session tokens](/security/session-tokens), [Chat widget security](/security/chat-widget)                        |

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

| Caller                | Credential                                         | Rule                                                             |
| --------------------- | -------------------------------------------------- | ---------------------------------------------------------------- |
| CLI, CI, or backend   | Scoped `kt_live_...` API key                       | Keep server-side; rotate and revoke from the dashboard.          |
| Anonymous widget      | Publishable `pk_live_...` embed key                | Fence by explicit allowed origins and anonymous spend caps.      |
| Signed-in widget      | Verified identity plus widget-minted session token | Sign the user id on your server; never ship the identity secret. |
| Custom browser client | Backend-minted session token                       | Mint a short-lived token server-side and refresh it as needed.   |

See [API authentication](/api-reference/authentication) for route-family
compatibility and [Session tokens](/security/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](/sdks/widget/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](/security/chat-widget) page has
  disclosure guidance.
* Use BYOK when your policy requires model-provider credentials under your own
  provider account. See [BYOK](/platform/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](/platform/audit-log).
Review the current public trust posture at
[karta.sh/trust](https://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](/security/architecture-review) and
[Production readiness](/platform/production-readiness).