Security · KANAP

Principles

KANAP is designed for IT departments that handle sensitive data. We treat your data the way we want IT vendors to treat ours, transparent, isolated, and within reach when you need it.

Transparent by default

The full source is on GitHub under AGPL v3. Your security team reads it, audits it, or forks it. Nothing is hidden behind proprietary binaries.

Isolated by design

Row-level security in the database itself enforces tenant isolation on every query the application runs.

Exportable, always

Your data is yours. CSV export on the main lists, document export to PDF, DOCX and ODT. No extraction tax.

Tenant isolation

KANAP is multi-tenant at the database level. Every row in every shared table carries a `tenant_id`, and PostgreSQL Row-Level Security policies enforce the filter on every read and write. The policy is part of the database schema, so it applies to every query the application runs.

PostgreSQL RLS policies on every table that holds tenant data, all forced
`tenant_id` filtering enforced at the database level, not just in the app
The current tenant is set at the start of every database transaction, and the policies read it
The application database role has no superuser or bypass rights, and the application refuses to start otherwise
A table that holds tenant data without its isolation policy fails the CI tests
Tenant isolation tests on every CI run

Data protection

Standard practices, applied rigorously. Strong password hashing, encrypted secrets, hashed tokens, and HTTPS on every cloud connection.

Cloud: HTTPS for every connection between users and the platform, with HTTP redirected to HTTPS and Cloudflare terminating TLS in front of our servers. Self-hosted: you terminate TLS with your own certificates
Argon2id password hashing (64 MiB memory cost) with per-user salts
Secrets stored via environment, not checked into source
Your own AI provider keys and integration credentials (GLPI, Netbox) encrypted at rest with AES-256-GCM
MCP tokens and session refresh tokens stored hashed, and revocable
Access tokens held in memory in the browser, refresh tokens in an HttpOnly cookie

Access control

Fine-grained permissions per module, per role. Every feature gate and every entity query honours the same RBAC matrix, including Plaid and MCP.

Reader, contributor, member and admin levels per module
Workspace-level admin role separate from module admins
SSO via Microsoft Entra ID (OIDC) on both cloud and self-hosted
Local password authentication with Argon2 + optional password reset flows
Plaid and MCP enforce the same RBAC as the UI, no privilege escalation
API tokens scoped to individual users, revocable at any time

Audit trail

Every meaningful change is recorded. Who changed what, when, with before and after snapshots. Activity is visible in the app.

Per-entity activity timeline (tasks, projects, documents, etc.)
Create, update and disable actions logged with the user, the timestamp, and before and after values
Administrators browse and filter the audit log in the app
Changes made through Plaid are logged in the same trail, with their source. Agents keep their own activity history, with the sources each agent used

Agent governance

Agents act under the same controls as everything else, plus limits specific to autonomous work. Every agent action is recorded and scoped to what you allowed, and you can stop an agent at any moment. Every agent starts with each type of action waiting for your approval. You choose when a type runs automatically, with the agent's track record (reviewed proposals, acceptance rate, days of activity) shown beside the choice.

Agents act only through defined operations, with no raw database or shell access
Each agent scoped to the operations you allow. Who can configure agents or review their work follows the same roles as the rest of the application
Every agent action recorded in the agent's activity history, kept 30 days by default and configurable from 7 to 90 days
Answers carry the sources the agent used, so a decision can be checked
Pause any agent immediately, one at a time or across the board
Per-agent spend caps keep running cost bounded
AI features are off by default. On the cloud, the built-in model receives no data until the workspace has accepted its provider and processing location, both named in the application. An administrator confirms them, and a new confirmation is asked if either changes. You can use your own model provider instead

Deployment & operations

Cloud deployments run on Linux hosts in Germany, in the European Union, with Cloudflare in front. Self-hosted deployments run wherever you choose. Both ship with the same security model.

Cloud hosting by Hetzner Online GmbH in Nuremberg, Germany (EU), with Cloudflare as CDN, TLS termination and protection in front
Self-hosted: the full source is public, and you build and run it yourself with Docker Compose
Self-hosted: no mandatory outbound calls for core functions, so KANAP can run without internet access
Self-hosted: you choose where it runs and how it is backed up
Self-hosted: AI features use only the model provider your administrator configures

Questions about security?

We're happy to share architecture details and walk through a threat model with your security team.

Talk to us Self-host and audit the code