Security
Security foundations available; production hardening planned
Katra’s current implementation treats authorization as a domain boundary rather than a user-interface concern. The local environment is still development infrastructure and must not be exposed as a production service without the remaining security and deployment gates.
Authorization principles
Section titled “Authorization principles”- Organization scope is explicit and restored safely around each operation.
- Global administration is installation-wide authority and is not erased by organization role changes.
- Channel, Direct Message, meeting, search, and realtime access fail closed.
- Conversation membership does not grant Product, Project, repository, or workflow access.
- Meeting guest sessions grant meeting-only authority and do not widen ordinary Katra access.
- Search authorization is enforced before ranking and reconciled again before results are returned.
Privacy principles
Section titled “Privacy principles”- Realtime payloads contain minimal refresh hints rather than private content.
- Meeting abuse counters are aggregate and avoid collecting unnecessary guest identity data.
- Invitation and guest bearer URLs must not be written to ordinary application logs.
- Pulse avoids third-party avatar requests.
- Diagnostic surfaces must redact credentials, private messages, and tenant-sensitive data.
Secrets
Section titled “Secrets”Never reuse local Compose credentials in a shared installation. LiveKit, Reverb, mail, database, model-provider, and future workspace credentials stay server-side or are issued through a bounded short-lived mechanism.
Shared-installation requirements
Section titled “Shared-installation requirements”Before exposure to an untrusted network, Katra needs trusted TLS, secure cookies, installer-controlled first-user bootstrap, invitation-only enrollment, rate controls, dependency and image scanning, security headers, backup and restore proof, and an incident-response process appropriate to the enabled authority.
Reporting a vulnerability
Section titled “Reporting a vulnerability”Do not publish sensitive vulnerability details in a public issue. Contact support@katra.io with a concise description and a safe way to coordinate evidence.