Mode A
Fully local
A local model does the reasoning as well as the processing. With external tools and optional telemetry disabled, and model weights already present, no document content, prompt, embedding or generated output leaves the host.
Trust Center
Private by architecture. Verifiable by output.
Written for the people who have to sign off rather than the people who have to be convinced. What the product touches, what it stores, what it can reach, and what LM-Kit One commits to, release by release.
Applies to LM-Kit One 2026.x releases · Last updated August 2026
Where the data goes, in both modes.
There are two deployment modes and they have different disclosure properties. Anyone assessing this needs the difference stated, not blurred into one privacy claim.
Mode B
Local processing, external reasoning
An external assistant supplies the conversation and calls governed MCP tools. Files, OCR, indexes and rendering stay local. The tool result is disclosed to that assistant, and that is the boundary to assess.
Mode B discloses whatever the tool returns. The defensible claim is that source documents stay local and administrators choose which derived results are shared. It is not a claim that nothing leaves the network, and we do not make that claim.
Network behaviour and access control.
A private AI product that is reachable by default is not private. Every step that widens exposure is a decision an operator has to take deliberately.
Default
Loopback only
A fresh LM-Kit One install binds to the local machine. Reaching it from another host requires changing the network mode explicitly, and anonymous access over a network is refused rather than warned about.
Credentials
Tokens hashed at rest
API keys are stored hashed, not in plain text, so the settings store does not contain a usable credential. Admin sessions and remember-me tokens are handled separately, and TOTP is available for the admin surface.
Isolation
Sessions bound to an owner
MCP sessions and the files they can reach are bound to the authenticated owner, so one caller cannot read another owner's documents or collections through a shared endpoint.
Egress
Outbound access is a policy, not an assumption
Tools that reach the internet (web search, page reading, HTTP reads) are governed by an allowlist and an egress mode, so an operator decides what a model or agent may contact. Once model weights are present on the host, document processing, indexing, retrieval, inference and fine-tuning need no outbound connection at all, which is what makes air-gapped operation a supported mode rather than a claim. Model acquisition is the one step that needs network access, and it can be done once and then carried to the isolated host.
What is written, and where.
Everything the server writes resolves under one state directory, decided at startup and named in the startup log so you never have to guess which path is in use.
- State directory
- One directory holds everything the server writes. Its location follows the install type, is configurable, and the startup log names it on every boot.
- Settings
- The runtime settings file, including network mode, tool policy and model overrides, under the state directory.
- Model weights
- Cached in their own directory, separate from state by default: weights are large and usually belong on dedicated storage. The location is configurable.
- Search indexes
- The local search cluster's own data directory, or your PostgreSQL or Qdrant instance when you point collections at existing infrastructure.
- Uploads and caches
- Under the state directory. Files ingested for processing, and derived artifacts such as rendered pages and thumbnails.
- Logs and request history
- Under the state directory, readable from the admin console. Retention is configurable.
A machine-wide install never requires the service account to write inside the installation directory.
Model governance and provenance.
The weights are third-party artifacts running inside your perimeter, so their origin and licence are part of your supply chain, not ours alone.
Origin
Named source per model
Every catalog entry records where the weights come from and what they are, so a model inventory can be produced for review rather than reconstructed. You can also import your own weights and skip the catalog entirely.
Licence
The model's licence is its own
An LM-Kit licence covers LM-Kit. Each open-weight model carries its own licence from its own publisher, and those terms govern how you may use that model. Check them for anything you put into production.
Fit
Hardware fit shown before download
The console prices a model against the device before you commit to fetching it, so capacity problems surface at planning time rather than after a multi-gigabyte download.
What is committed, release by release.
The commitments an assessor can plan around, stated precisely rather than asserted in general.
Support
Support and response
Support and response-time commitments apply to both products, with direct access to the engineering team behind them.
Stability
Interfaces you can plan on
Calendar-versioned releases with documented changes, long-term-support builds, and security updates for supported versions.
Artifacts
Release evidence, per build
Windows installers are signed; the distributed macOS package is signed, notarized and stapled, verified per release.
SHA-256 checksums, an SBOM, release notes and known issues are provided for every build on request.
Reporting a vulnerability.
Write to security@lm-kit.com rather than opening a public issue, and give us a way to reach you for follow-up. We will confirm receipt, tell you whether we can reproduce it, and keep you informed until it is resolved. Please include the build you tested, the platform, and the steps to reproduce. This address is also published in security.txt.
Assessing LM-Kit