Security whitepaper · Knowpoint

1. Overview

Knowpoint is IT documentation software for managed service providers and IT teams. Customers use it to store details about their clients' organizations, devices, networks, procedures and credentials. Because this information can give access to many other companies' systems, Knowpoint is designed on the assumption that it is a high-value target.

This whitepaper describes the controls built into the service as of the version and date above: how data is stored and encrypted, who holds the keys, how people sign in and what they can see, how workspaces are kept apart, what is logged, and which providers Knowpoint relies on. Section 15 states plainly what Knowpoint has and has not been audited for.

2. Architecture

Application. A Python web application (FastAPI), run as a managed service on Render.
Database. A managed PostgreSQL database on Render. Each customer workspace has its own database schema (see section 8).
Edge. Cloudflare provides DNS and sits in front of the application, terminating TLS and absorbing unwanted traffic before it reaches the application.
Addresses. Each workspace is served at its own subdomain, such as yourcompany.knowpoint.io. The marketing site, Help Center and sign-up live on the main address.
Email. Invitations, password resets and alerts are sent through Resend, from an authenticated sending domain.
Optional services. AI features (section 11) and integrations with PSA and RMM tools (section 12) only connect to outside services when a workspace admin turns them on.

3. The data we hold

Data	Examples	How it's protected
Stored secrets	Password values, one-time code (TOTP) secrets	Encrypted by the application with the workspace's key (AES-256-GCM), plus storage encryption
Connection secrets	PSA/RMM API credentials, alert channel secrets, a workspace's own AI provider key, SSO client secret	Encrypted by the application with the workspace's key, plus storage encryption
Documentation	Organizations, assets, flexible assets, documents, contacts, locations, domains, tags	Workspace isolation, access control and storage encryption
Account data	Names, email addresses, roles; users' two-factor secrets	Sign-in passwords stored only as bcrypt hashes; two-factor secrets encrypted by the application
Shared links	A password shared with someone outside the workspace	A snapshot encrypted with a key that exists only in the link, then encrypted again with the workspace's key; deleted once the link can't be opened
API keys	Keys for the REST API	Only a SHA-256 hash is stored; the key is shown once
Activity	Audit log entries, notifications	Workspace isolation and access control (viewing the audit log is its own permission)

4. Encryption

In transit

All traffic to Knowpoint uses HTTPS (TLS). Browsers are told to use HTTPS only (HTTP Strict Transport Security), and session cookies are marked Secure so they're never sent over plain HTTP. Connections from Knowpoint to integrations, AI providers and webhooks also use HTTPS.

At rest: storage

The database runs on Render's managed PostgreSQL, whose storage the hosting provider encrypts at rest. This protects all workspace data, including documentation, if physical storage is ever compromised.

At rest: application-level encryption of secrets

Storage encryption alone doesn't protect a secret from someone who can query the database. So the most sensitive values (stored passwords, one-time code secrets, users' two-factor secrets and connection secrets, listed in section 3) are also encrypted by Knowpoint itself before they're written:

Algorithm: AES-256-GCM, an authenticated cipher. Any change to the stored value is detected, and the value isn't decrypted.
Nonce: a new random 96-bit nonce for every value, so encrypting the same password twice gives different results.
Key: a 256-bit key unique to the workspace (section 5).
Format: each value carries a format version, so a future key or algorithm version can be introduced alongside existing data.

Encrypted values are only decrypted when an authorized person reveals or copies them (each time is logged), when the service needs a connection secret to talk to an integration, or in an export that explicitly includes password values (section 13).

Sign-in passwords

Passwords people use to sign in to Knowpoint are never stored. Only a bcrypt hash (cost factor 12, with a unique salt) is kept, so a password can be checked but not read back. Passwords must be at least 10 characters.

5. Key management

Who holds the keys. Knowpoint manages encryption keys. The service has one master key, held by Knowpoint.
Where it's kept. The master key is stored in the hosting platform's encrypted secret store and given to the application when it starts. It is never written to the database, the database's backups, logs or the source code. Someone with a copy of the database alone can't decrypt the secrets in it.
Per-workspace keys. Each workspace's key is derived from the master key with HKDF-SHA256, using the workspace's identity as input. Derived keys exist only in the running application's memory and are never stored. One workspace's key can't decrypt another workspace's data.
Customer-managed keys. Bringing your own key (BYOK) isn't available today.
Session signing. Sign-in sessions and one-time sign-in handoffs are signed with a separate secret key, also held in the hosting platform's secret store.

6. Identity and sign-in

Single sign-on with Microsoft 365. Workspaces can let people sign in with Microsoft Entra ID, using OpenID Connect with PKCE. Knowpoint verifies the ID token's signature against Microsoft's published keys and checks its audience, issuer, expiry and nonce. Only accounts in the Entra directory the workspace admin chose are accepted, and after the first sign-in a person is matched by their immutable Entra object ID, not their email. Admins can require SSO, optionally keeping password sign-in for admins as a break-glass route.
Two-factor authentication. Every user can turn on authenticator-app codes (TOTP). Admins can see who has two-factor on and reset it for a user. Workspace-wide enforcement of two-factor isn't available yet. Until then, requiring Microsoft SSO lets you apply your own Microsoft sign-in policies, such as MFA and conditional access.
Rate limiting. Sign-in and two-factor code attempts are limited to 10 per address in five minutes.
IP allowlist. A workspace can be limited to listed addresses and ranges (IPv4 and IPv6), for the web app and, optionally, the REST API. An admin can't save a list that excludes their own current address, and Knowpoint operators can turn a list off if a customer is locked out.
Sessions. Sessions are signed cookies, marked HttpOnly and Secure, with SameSite=Lax, expiring after 12 hours. A session belongs to one workspace and isn't accepted by another.
Invitations and resets. Setup and password reset links are single-use and expire.

7. Access control

Permissions and roles. Access is granted through 22 specific permissions, such as Reveal and copy passwords, Export data or View the audit log. They're grouped into built-in roles (Admin, Editor, Technician, Viewer) and roles you define. Seeing a password's name and revealing its value are separate permissions.
Organization access. People can be limited to chosen client organizations, directly or through teams.
Restricted items. A single password, asset, flexible asset or document can be limited to named people or teams, with view or edit access. Restricted items are hidden everywhere else: lists, search, Ask AI, exports and activity feeds.
Lock-out protection. A workspace always keeps at least one active person who can manage users, and admins can't delete their own accounts.
External sharing. People with the Share passwords externally permission (admins by default; it also needs Reveal and copy passwords) can send one password to an outside email address as a link. The shared snapshot is encrypted with AES-256-GCM using a key derived (HKDF-SHA256) from a random 256-bit value that exists only in the link's fragment, after the "#", which browsers don't send to servers. Knowpoint never stores it, so the database and the master key together can't open a share. Opening also needs a 6-digit code emailed to the recipient or a passphrase the sharer gives them separately. Links expire (1 hour to 7 days), are used up after a set number of views, can be revoked, and lock after five wrong attempts, at which point the snapshot is deleted. Every share, opening and failed attempt is audited, and the sharer is notified when it's opened. Shared links are reachable from outside a workspace's IP allowlist, since the recipient is outside the network.
Removing people. Deactivating or deleting a user ends their sessions immediately. Deleting also removes their API keys, team memberships, access, SSO link and Ask AI conversations, while the audit log keeps their name.

8. Workspace isolation

Each workspace's data is stored in its own PostgreSQL schema. Every request is bound to exactly one workspace, from its address, before any data is read.
Each workspace's secrets are encrypted with that workspace's own derived key.
Users, roles, sessions, API keys and settings belong to one workspace. An account in one workspace can't sign in to another.
The platform console Knowpoint uses to run the service shows each workspace's status, plan and item counts, not its documentation or passwords. For account recovery, the console can issue a one-time setup link to a workspace's owner, and this is recorded.

9. Application security

Forgery protection. Every form and API call that changes data from the browser needs a per-session CSRF token.
Browser protections. Pages can't be framed by other sites (X-Frame-Options: DENY), content types aren't guessed (nosniff), referrers aren't sent to other sites, and HTTPS is enforced (HSTS).
Injection. Database access goes through parameterized queries. Pages escape user content by default, and Markdown in documents is sanitized before display.
Outbound requests. Webhooks and integrations can't be pointed at private or internal network addresses, which prevents server-side request forgery.
Uploads. Logo uploads are checked by their content, not their name, limited in size, and served with a restrictive Content Security Policy.
Imports. An uploaded import is parsed into a preview without changing anything, and kept encrypted until it's confirmed or cancelled.

10. Logging and alerts

Audit log. Each workspace's audit log records changes, sign-ins and failed sign-ins, password reveals and copies, permission changes, API key creation, exports, imports, syncs and changes made by Ask AI. Each entry has who, when and the IP address. Viewing it is a separate permission.
Alerts. Rules can warn when someone reveals many passwords in a short time, sign-ins fail repeatedly, two-factor is turned off, someone gains admin rights, an API key is created, a user is added, data is exported, or many items are deleted. Alerts go to the app, email, Slack, Microsoft Teams, webhooks, or ConnectWise and Halo tickets.

11. AI features

Off by default. AI is off until a workspace admin turns it on, and using it is a separate permission.
Who processes it. Each workspace uses its own Anthropic or OpenAI account: an admin enters the workspace's API key, which is encrypted like other secrets. Knowpoint sends requests straight to that provider under the workspace's own agreement with it, and doesn't provide AI through an account of its own.
What it can see. Ask AI searches and reads only what the person asking is allowed to see. Password values are never sent to an AI provider.
What it can do. If allowed, it can create and update documentation within the person's own permissions. Every change it makes is recorded in the audit log.
Training. Under Anthropic's and OpenAI's commercial API terms, data sent through their APIs isn't used to train their models by default. Check your own agreement with your provider.

12. Integrations and the API

PSA and RMM sync. Connections to ConnectWise PSA, HaloPSA and NinjaOne only read data from those tools; Knowpoint never changes or deletes anything in them. Their credentials are encrypted with the workspace's key, and saved secrets are never shown again.
Alert channels. Slack, Teams, webhook, ConnectWise and Halo alert channels only send alerts. Their secrets are encrypted the same way.
REST API. API keys act as a chosen person and can never do more than that person. Each key can be limited further to read-only access, chosen areas, organizations and types. Keys are stored only as hashes, can be revoked at any time, and their changes are audited.

13. Data lifecycle

Export. People with the Export data permission can download what they're allowed to see as JSON and spreadsheets, at any time. Password values are only included with a separate permission, and every export is audited.
Trial end. When a trial ends, the workspace is paused, never deleted automatically.
Deletion. When a workspace is deleted at the customer's request, its database schema and everything in it is dropped. Backups held by the hosting provider expire on their normal schedule.
Deleted items. Items deleted in the app are removed from the database. The audit log keeps a record that they existed and who deleted them.

14. Infrastructure and providers

Knowpoint uses these providers to run the service. Attestations are those each provider publishes about itself.

Provider	Purpose	Data	Provider's attestations
Render	Application hosting and the managed PostgreSQL database	All workspace data	SOC 2 Type II, ISO 27001
Cloudflare	DNS, TLS and traffic protection in front of the application	Traffic in transit	SOC 2 Type II, ISO 27001
Resend	Sending email (invites, password resets, alerts)	Email addresses and email content	SOC 2 Type II
Anthropic or OpenAI (your own account)	AI, if a workspace adds its own API key	Documentation the asking user can see (never password values), under the workspace's own agreement with the provider	See the provider
Microsoft	Sign-in, if a workspace turns on Microsoft SSO	Sign-in identity	See the provider

15. Compliance status

Knowpoint is hosted on Render, whose platform has a SOC 2 Type II report and ISO 27001 certification, and runs behind Cloudflare, which holds the same. These cover the physical, network and platform security of the infrastructure Knowpoint runs on.

Knowpoint itself has not yet completed its own SOC 2 audit. The controls in this whitepaper are how the application is built and operated today. Customers who need provider reports can request them from the providers, and can send Knowpoint a security questionnaire at security@knowpoint.io.

16. Shared responsibility

Knowpoint is responsible for	You're responsible for
Encrypting secrets and keeping keys separate from data	Who you invite, and the roles and access you give them
Keeping workspaces isolated from each other	Turning on SSO, two-factor and the IP allowlist where you need them
Running, patching and monitoring the service	Setting up alert rules and reviewing the audit log
Choosing and reviewing infrastructure providers	Keeping exports safe, especially those with password values
Recording security-relevant activity in your audit log	Removing access promptly when people leave

17. Reporting a vulnerability

If you believe you've found a security issue, email security@knowpoint.io with a description and how to reproduce it. Please don't access other customers' data, disrupt the service, or share the issue publicly before it's fixed. We'll acknowledge your report, keep you updated, and credit you if you'd like.

Knowpoint security whitepaper