Security
Security is part of how Kanera is built, operated, and documented, especially for teams choosing between hosted and self-hosted deployment.
Effective July 16, 2026 · Version 1
Hosted Kanera is designed with layered controls across application security, infrastructure, monitoring, access management, and operational review.
Self-hosted Kanera gives your team control over the runtime environment. That control also means your organisation is responsible for deployment hardening, patching, backups, network exposure, and monitoring.
Workspace owners control which users are invited, what access they receive, and what content is placed in Kanera.
Kanera should not be used to store highly regulated data unless your organisation has reviewed the deployment, configuration, contractual terms, and legal requirements for that use.
Email suspected vulnerabilities to [email protected]; do not use a public issue. Include the affected component, version, URL, endpoint, or deployment mode; reproduction steps or a minimal proof of concept; likely impact; relevant requests, logs, or screenshots with secrets removed; and your preferred contact details and whether you want public credit. We aim to acknowledge a report within 3 business days and provide an initial assessment or request for more information within 10 business days. These are targets, not guarantees.
In scope are authentication and authorisation, tenant isolation, private-board access, stored secrets and token leakage, uploads and file handling, APIs, OAuth, MCP, webhooks, realtime features, billing boundaries, and the default self-hosted deployment. Social engineering, spam, findings that depend only on intentionally weak development settings, and denial-of-service testing against production without written permission are out of scope.
We do not currently publish a PGP key and ordinary email is not an end-to-end encrypted reporting channel. Do not send live credentials or personal data. Ask in the first email if you need us to arrange a more secure exchange for sensitive evidence.
If you act in good faith, test only accounts, data, and systems you own or have explicit permission to test, stay within the scope above, avoid privacy violations and service disruption, access only the minimum data needed to demonstrate the issue, stop and report if you encounter another person’s data, do not retain or disclose that data, and comply with applicable law, we will treat the research as authorised for the purpose of our policy and will not pursue legal action against you for the research itself. This is not permission to test third-party systems or infrastructure outside our control, use social engineering or physical attacks, or demand payment.
Please give us a reasonable opportunity to investigate and remediate before public disclosure. We will work with you on a disclosure timeline based on severity, affected users, fix availability, and deployment needs, and we aim to keep you informed at meaningful milestones. If you believe urgent disclosure is necessary, explain the risk to [email protected] so we can coordinate.
Delete test data and confidential evidence when it is no longer needed. If you unintentionally access personal data, credentials, or customer content, stop testing, do not copy or share it, and tell us what was accessed so we can respond appropriately.
This is Security Policy version 1, effective July 16, 2026. We may update it as Kanera, our infrastructure, or verified practices evolve.