Skip to content
kazma.
Search Kazma Documentation & Site
↵ to navigate ESC to exit
kazma.
ع Star 6 Get Started
Security and trust

Security you can read.

Kazma runs on your machine and acts with your approval. Here is what protects you, where the limits are, and how to report a problem.

Who it is built for

Kazma is software you run for yourself, and each install has one operator: the person who runs the server, holds its keys and edits its settings. Everything on this page protects the operator from the agent — from its mistakes, and from the untrusted web pages, documents and messages it reads. Nothing here protects an install from its own operator: every safeguard can be switched off by whoever runs it, and anyone they let in acts with their authority.

Threat model

What protects you

Approval before anything risky

Writes, shell commands, outbound messages and posts wait for a person on the web, Telegram, Discord and Slack — in chat, multi-agent runs and pipelines alike. A tool nobody classified is gated, not allowed.

Docs

Plans checked before they act

The commitment layer checks a plan against memory: a reminder date is anchored to what you said, and catastrophic commands like rm -rf / are refused before an approval card ever reaches you.

Docs

Untrusted content is fenced

Web pages, search results, documents and recalled memory reach the model as data, not instructions. On the AgentDojo benchmark: 10.4% attack success, against 18.1% undefended.

Docs

An encrypted secrets vault

Keys and passwords live in an AES-256-GCM vault, are masked on every screen and API, and are never passed to programs a tool starts.

Docs

Web-level protections

Protection against server-side request forgery (SSRF), with the verified IP pinned, against cross-site requests (CSRF), and against request floods.

Docs

Sign-in and roles

Sign in with a secret, local users or OIDC single sign-on, with admin, operator and viewer roles.

Docs

Code in a container (opt-in)

Code the agent runs can be isolated in a Docker container or in E2B.

Docs

Verified skills

Skills installed from the agentskills.io ecosystem are signed at install and verified before they run; a tampered one is refused.

Docs

Backups that restore

Every 6 hours, local and offsite (restic), checked daily, with a weekly rehearsal that restores the database.

Docs

Approval is a decision, not a sandbox

A shell command you approve runs with the full power of the machine. Approval means you decided; for isolation, turn on the Docker or E2B container.

Stated limits

What Kazma doesn't do yet is written down and dated — so you decide knowing it.

  • Several users or teams on one install: Partial — separation is enforced for memory and chats, not audited end to end.
  • No security audit of multi-tenant, internet-facing deployments.
  • No paid bug bounty; responsible disclosure only.
  • No cryptographic trust tiers for skills beyond HMAC verification, and no signed delegation between agents.
Known gaps Every feature and its status

Report a vulnerability

Report privately — please don't open a public GitHub issue for a security problem.

Email admin@kazma.ai GitHub private reporting Mubder/kazma RFC 9116 security.txt

Response targets (best effort, not a contract)

Acknowledgment
48 hours
Initial assessment
7 days
Severity determination
14 days
Patch
30 days when practical

Supported versions: 0.11.x (the latest release). The full security policy