Capka Security Model
Capka separates the execution boundary, the user privacy boundary and the permission layer. They solve different risks and should be configured together.
Execution boundary
Every chat runs in a separate unprivileged Linux sandbox that cannot access the host filesystem. Linux capabilities are dropped, agent commands run as UID 1000:1000, and memory, CPU, PID, file-size and workspace quotas limit resource use. Workspaces are separated by container and bind mount. For higher-risk deployments, combine gVisor with rootless Docker and restrict network egress.
User and administrator privacy
Files and conversations are private per user. Administrators manage access, roles and token spending, but other people’s conversations and files do not appear in the administration panel.
Registration is closed by default. Open it only when the deployment is intended for public access and the sandbox has been hardened for untrusted users.
Permissions, integrations and auditability
Before a marketplace bundle is installed, Capka shows which hosts its connectors contact, which commands run in the sandbox and which secrets it requests. Updates that widen access remain blocked until accepted.
Administrators can use allow, ask or deny policies for agent actions and review the audit log afterwards. These controls reduce accidental access; the sandbox remains the primary technical boundary for executed code.
Report a vulnerability
Follow the private reporting instructions in the repository security policy. Do not publish an unpatched vulnerability in a public issue.