Privacy Policy

Information you give us

• Account details. Your name, email address (stored lowercased), and — if you register with a password — a cryptographic hash of that password. We never store your password itself.
• Profile details. Optional job title, location, phone and mobile number, timezone, birthday, and join date, plus a profile photo if you upload one and a light/dark theme preference.
• Workspace content. Everything you create in a board: item names, cell values in every column type, subitems, groups, documents and their blocks, updates and replies, reactions, tags, views, templates, forms, and automation rules. This content is whatever you and your team choose to put there, so it can contain personal information about you or about other people — including people who are not Kolaboreyt users.
• Files. Documents, images, and other attachments you upload, up to 50 MiB per file, together with the file name, content type, and size.
• Invitations. When you invite someone, we store the invitee’s email address, the role and scope you selected, any personal message you wrote, and who sent it.
• Correspondence. Messages you send us for support, security reports, or privacy requests.

Information from your sign-in provider

If you sign in with Google, we receive and store your Google account identifier, the email address and profile details Google returns, the OAuth scopes granted, and the access, refresh, and identity tokens needed to keep that link working. We request offline access so the link survives without prompting you at every sign-in. We do not receive your Google password.

Information generated automatically

• Sessions. A session record holds a session token, its expiry, the IP address the session was created from, and your browser’s user-agent string.
• Activity and audit log. An append-only record of significant actions — items created and moved, cell values changed, boards and workspaces created or deleted, files added or removed, invitations, permission changes, API-key issuance and revocation, and user lifecycle events. Each entry records who acted, whether they acted through the interface, an API key, a public form, or the system, and when.
• Notification records. The notifications generated for you, your per-channel settings, and read markers showing which items and updates you have seen.
• Push subscriptions. If you turn on desktop notifications, we store the push endpoint URL your browser issues, the two encryption keys that accompany it, and the user-agent string so you can recognise the device.
• Operational metrics. Request paths, response statuses, timings, queue depths, worker health, and backup freshness. These describe the system, not the content inside it.
• Abuse-prevention records. Rate-limit and request-deduplication counters. Where these are keyed to a network address, the address is stored as a truncated SHA-256 hash rather than in the clear.
• Error logs. Server-side error output for diagnosis. Secrets, API keys, and AI provider keys are never written to logs.

Information from integrations you connect

If an administrator connects a GitHub organisation, we store the installation identifier, the organisation or user login, the permissions and repository selection granted, and — for each linked board — the repository identifiers, name, and default branch, along with the plan data synchronised between the two systems.

Where the model runs

By default, AI requests are served by a language model running on infrastructure we operate ourselves, reached over a private network. In that default configuration your prompts and the board context accompanying them are not sent to any external AI company.

You may explicitly select a third-party model provider instead. If you do, the prompt and the board context for that request are transmitted to that provider and handled under their terms and privacy policy. The automatic setting never silently selects a third-party provider on your behalf.

What is and is not kept

• Conversations are not stored. An interactive AI transcript lives only in your browser tab. It is not written to our database and not written to your browser’s local storage. It is discarded when you start a new chat, refresh, switch board context, or sign out — and it cannot be recovered afterwards, by you or by us. This is a deliberate architectural decision, not a default we might quietly change: adding conversation history would require a new retention policy, access controls, and deletion behaviour first.
• Memory is opt-in, one fact at a time. The assistant may propose a short fact worth remembering, but nothing is retained until a person approves it. Each approved memory is a single short sentence, scoped to one user inside one account, and is never read for anyone else.
• AI column results are saved. When an AI column computes a value for a row, the result is stored as that cell’s value along with a fingerprint of the inputs, so unchanged rows are not recomputed.
• Queued AI jobs are deleted automatically seven days after they complete.

What the assistant is allowed to do

When the assistant acts on your behalf — creating an item, changing a value, reordering a board — it acts as you, under exactly your permissions. It cannot read or change anything you could not read or change yourself, and every action it takes is recorded in the activity log attributed to you, marked as agent-performed and correlated to the run that produced it.

If you supply your own provider key

An account may supply its own AI provider key. Stored keys are sealed with AES-256-GCM authenticated encryption under a server-held master key, so a copy of the database alone does not disclose them.

With people in your account

Content you create is visible to the people the account’s permissions make it visible to — board members, workspace members, guests you invite to a specific board, and administrators. Your name and profile photo are visible alongside your activity.

With service providers who help us run the service

Each provider is used for the stated purpose only, and we ask them to handle the data accordingly.

For legal reasons

We may disclose information where we are legally required to, or where it is necessary to investigate a security incident, enforce our Terms of Service, or protect the rights and safety of users. We will not disclose more than the request requires.

In a business transfer

If the service is ever acquired or merged, personal information may transfer as part of that transaction. We will give notice before your information becomes subject to a different privacy policy.

Confidentiality

• Encryption in transit. The application and API are served over HTTPS with HTTP Strict Transport Security set to one year and applied to subdomains, so conforming browsers refuse to connect over plain HTTP.
• Passwords are never stored. Only a scrypt hash is kept. Passwords must be at least 12 characters and contain upper case, lower case, a digit, and a symbol.
• Secrets are encrypted at rest. Stored AI provider keys are sealed with AES-256-GCM under a dedicated master key.
• API keys are hashed with a server-side pepper. The plaintext token is shown once at creation and never stored, and the pepper is versioned so it can be rotated without invalidating existing keys.
• Files are never publicly readable. Uploads and downloads use pre-signed URLs valid for five minutes, issued only to a caller already authorised for that board.
• Tenant isolation. Every query is scoped to the account it belongs to, so authorisation is enforced by the data access itself rather than by a check that could be forgotten.
• Least privilege. Role-based access control, board- and workspace-scoped permissions, guest accounts limited to the boards they were invited to, and read-only membership.
• Step-up authentication. Managing personal API credentials requires having authenticated recently, so a stolen idle session cannot mint new keys.
• Secrets never leave the server. Provider keys and API tokens are never logged and never returned in API responses; responses carrying sensitive values are marked no-store.

Integrity

• Cross-site request forgery protection. State-changing requests from a browser must both originate from a trusted origin and carry an application-specific header a cross-site form cannot set.
• Strict browser security headers. A restrictive Content Security Policy, framing denied outright, MIME sniffing disabled, and a referrer policy that withholds path details from other origins.
• A strict cross-origin allowlist. Requests from origins that are not on the configured list are refused rather than reflected.
• Input handling. Database access is parameterised, user-supplied text is length-bounded and sanitised, uploaded file names are stripped of path separators so a crafted name cannot escape its storage prefix, and user-controlled values are HTML-escaped before they are placed in outbound email.
• Verified webhooks. Inbound integration webhooks are verified against a signature computed over the exact bytes received.
• An append-only audit trail and transactional writes for multi-document operations, so a partial failure cannot leave inconsistent data.
• Idempotency keys on public form submissions and API writes, so a retried request cannot silently duplicate data.

Availability

• Backups taken from the artifact, not the job. The database is dumped nightly, verified, kept locally, and uploaded to separate object storage. Freshness is measured by inspecting the newest archive that actually exists, so a backup job that fails but exits cleanly still registers as stale and raises an alert.
• Replicated database and monitored background workers.
• Operational metrics and alerting across queue depth, delivery backlogs, and backup age.
• Abuse brakes. Rate limits on sign-in, sign-up, password reset, verification email, public form submission, and API traffic; a 50 MiB cap on any single upload; and per-board item capacity limits.

Honest limitations

A privacy policy that overstates security is itself a privacy problem, so these are the limits as they stand today:

• Multi-factor authentication is not yet enforced. The account settings include two-factor and single-sign-on policy switches, but they are not currently enforced at the authentication layer. Do not rely on them. Use a unique, strong password.
• Some rate limits are per-process. Several limiters hold their counters in the memory of a single application process. They are an abuse brake, not a security boundary.
• Database contents are not encrypted field-by-field. Aside from password hashes, API key hashes, and the sealed provider keys described above, workspace content is stored unencrypted at the application layer and protected by access control, host security, and transport encryption.
• OAuth tokens are stored. Linking Google sign-in stores the access and refresh tokens needed to maintain that link.

No system is perfectly secure. We work to protect your information but cannot guarantee absolute security, and we will notify affected users and any required authority of a personal-data breach as the law requires.