Security

Security model

Knwlge is split so that the part we run knows who you are, and the part you run knows what your code says. This page explains what each part protects, what crosses between them, and what we do not claim yet.

Who does what

	Knwlge Global (we run it)	Your Enterprise Server	The developer's machine
Holds	Accounts, organizations, projects and memberships; licences; which servers are enrolled and how healthy they are.	The index of your repositories, knowledge, memories, captured sessions, audit log, and your provider and integration credentials.	The CLI's sessions, in the operating system's keychain, and a local activity log.
Decides	Who someone is, and whether they belong to a project. It issues the tokens.	What each person may read and change, on every request, from its own database — and which ways of signing in it accepts.	Which project a folder belongs to, and what leaves the machine after redaction.
Never has	Your code, prompts, context cards, knowledge, memories, guardrails or credentials.	Passwords: it has no sign-in of its own.	Other people's data.

There is no content path through Knwlge Global. When an admin reads a memory or a prompt in the console, the browser talks to your server directly.

Identity and tokens

Signing in happens at knwlge.com: with a Knwlge password (stored only as a salted scrypt hash), a Microsoft work or school account, or GitHub. Sign-ins and sign-ups are throttled per network, keyed on a hash of the address, never the address itself. The Knwlge app's session is an HttpOnly, SameSite cookie.
Developer tokens — what the CLI and the console carry to your server — are ES256-signed JWTs that last an hour. Each is minted for one server: its audience is that server's URL, so no other server accepts it. It says who the person is, their organization and project roles, and how they signed in. The refresh token that renews it is an opaque secret, rotated on every use, and stored at Knwlge only as its SHA-256; it lasts 30 days.
Signing keys are generated by Knwlge Global, sealed with AES-256-GCM under a key-encryption key, and published as public keys at /oauth/jwks, where your server checks every token.
Your server's own policy applies on every request: the sign-in methods it accepts and the email domains each may come from (Settings → Sign-in). An admin can disconnect a device or sign someone out everywhere; the server refuses the session at once and Knwlge Global revokes its refresh token.
Enrollment keys are shown once and stored at Knwlge only as their SHA-256. At enrollment the server generates its own key pair; afterwards it proves itself with signed assertions, and Knwlge keeps only the public key. A key can be deactivated at any time and ends at its valid-until date.
The licence is a signed token re-issued with every heartbeat. If Knwlge Global is unreachable, the server keeps serving for seven days before readiness fails.

What crosses the boundary

From → to	What	Contains	Never contains
Developer → Global	Sign-in	Email, name, the provider's assertion	Anything about code
Global → developer	Tokens	User id, organization, roles, audience, expiry, sign-in method	Passwords
Server → Global	Heartbeat, status report	Version, uptime, readiness checks, database and storage health and size, allowed clients and sign-in methods, counts of active people and of prompts, briefs and tokens	Credentials, connection strings, prompts, cards, repository, file or user names
Server → Global	Usage export	Daily totals per organization	Questions, cards, paths, memory text
CLI → Global	Usage report	Install id, CLI version, OS, device name, and per project the counts of requests, briefs and memory writes by AI client	Prompts, answers, cards, memory text, repository, file or branch names
Global → server	Keys and revocations	Public keys; sessions and people to refuse	—

Your server needs to reach api.knwlge.com, your own database and storage, the model providers you choose and your source hosts — nothing else. Provider hosts are an explicit allowlist.

Inside the Enterprise Server

Authorization comes from the database. Every request is authenticated, then the person's organization, teams, repositories and role are read from the server's own rows — never taken from token claims or request bodies.
Tenant isolation is enforced by Postgres. Every table has row-level security enabled and forced, with policies; the role the server runs as cannot bypass it. Work that spans people — an admin reading prompts — goes through reviewed functions that check the admin's membership again.
Secrets are sealed. config.json is readable by its owner only. Provider keys and integration credentials are envelope-encrypted — under a local master key, Azure Key Vault or a key service — and never shown again once saved.
The console is hardened. Its session is sealed with AES-256-GCM in an HttpOnly, SameSite cookie; every request that changes something must carry a header another site cannot add; pages are served with a strict Content-Security-Policy and cannot be framed. Markdown is rendered without raw HTML, and remote images in documents are never fetched.
Limits and audit. Requests are rate-limited per person and per organization. Admin writes, prompt views, sign-in changes and updates are audited, with retention and export to your SIEM.
Updates are verified. A release is installed only when its SHA-256 matches the one Knwlge Global lists, migrations run under a data guard, and a version that does not start is rolled back.

Inside Knwlge Global

It holds no content. Status reports are validated against closed vocabularies; anything unknown or oversized is refused, not stored.
It stores a network address in one place only — the CLI's usage reports, shown to the person they belong to and deleted after 30 days. Throttling uses a hash of the address.
The Knwlge app talks to its API from an allowlisted origin; every request that changes something is origin-checked, and cookies are HttpOnly and SameSite.
Control-plane actions — creating projects, enrollment keys, approvals, releases — are audited.
It runs on AWS, with its database on RDS PostgreSQL and its secrets in AWS Secrets Manager.

On the developer's machine

Credentials live in the keychain — the macOS Keychain, the Linux Secret Service or Windows DPAPI. A plaintext file is used only when explicitly allowed, for test machines.
The sidecar listens on 127.0.0.1 only. Its health endpoint needs a secret only the installed service knows; per-prompt hooks reach it with a separate owner-only capability and never touch the credential. Its HTTP MCP surface is off unless explicitly turned on in the foreground.
Redaction happens before upload. Secrets are removed and personal data masked on the machine, and again on the server.
Installs are reversible. install writes only its own entries, backs up what it touches, and refuses to overwrite wiring it cannot prove is its own.
The background upkeep cannot change code. It may use Knwlge's tools and read files; it never edits code or runs commands.
Releases are signed. CLI artifacts are built only by a pinned release workflow from an immutable tag, signed and attestation-verified before distribution.

Untrusted content

Everything indexed or captured is treated as untrusted input to the agent:

Each unit gets a deterministic injection score; units at or above the threshold are withheld from briefs, and excerpts reach the agent wrapped in untrusted-evidence markers.
When nothing clears the evidence floor, the brief is empty — never a fallback to unverified content. Every brief has a receipt, and context.explain says why each item was served or withheld.
What assistants and imports write waits for review before it reaches other people's briefs, and nobody reviews their own candidate unless the server allows it — audited when it does.
Your organization's guardrails tell every assistant what it must not do.

What is not claimed yet

Security reviewers can ask for the Enterprise Server's security package — architecture, threat model, row-level security proof, data inventory and control map — through the contact page.