Privacy

Kin answers repository queries locally by default. If you configure a remote embedding provider, Kin sends code entity text to that endpoint. If you use kin agent run, Kin sends the conversation, including source-bearing tool results, to the model endpoint you specify. That endpoint can run locally or remotely. Hosted KinLab also processes the repository content you choose to connect. These are separate choices from local repository queries.

The local Kin CLI has no analytics, no crash reporting, and no usage tracking. There is no product that counts how often you run it. The one feature named telemetry is off by default, writes only to a file inside your own repository, and never uploads anything. It is described in full below.

Kin also uses the network to acquire software and model files, check for updates when requested, and use services you configure. The sections below explain the data choices. Our technical network-exit inventory gives configuration details.

Running kin init creates a .kin/ directory in your repository for repository state. Machine-level Kin files can use the configured KIN_HOME directory. Downloaded model files can use a separate provider cache, including the Hugging Face hub cache. Setting KIN_HOME does not relocate every model cache. See the technical network-exit inventory for the selected provider and model configuration.

Kin uses your operating system's keychain for a CLI sign-in credential when that storage is available and enabled. If it cannot use the keychain and KINLAB_AUTH_PASSPHRASE is set, it writes an age-encrypted file in your user data directory. Otherwise, it writes plaintext JSON containing the bearer token, account email, and display name, and prints a warning naming the file. On Unix systems, Kin creates the file with mode 0600 inside a directory with mode 0700. File permissions are not encryption. Configure KINLAB_AUTH_PASSPHRASE before signing in if you need the encrypted-file fallback.

Local files remain on your machine until you remove them. Copies sent through a configured service are handled separately, as described below.

Downloading the Kin binary. If you install through npm, the first run of @kinlab/kin or @kinlab/kin-mcp downloads the matching release archive from GitHub, at github.com/firelock-ai/kin/releases. This happens when you first run the command, not when npm installs the package. Kin then fetches the SHA-256 published beside the archive, checks the bytes against it, and refuses to install on a mismatch.

That request carries nothing about you. Your platform and architecture decide which filename is requested, and @kinlab/kin-mcp identifies itself with its own version in a User-Agent header. No machine identifier, hostname, username, or repository path is sent. GitHub, as the host, necessarily sees the IP address the request comes from, and its own privacy policy applies to that.

Downloading the embedding model. With the default local embedding provider, Kin fetches an embedding model from Hugging Face on first use. It is roughly 522 MB and it is cached under your Hugging Face cache directory. Worth knowing: the background daemon starts this work on its own when a repository's index has not caught up, so it can begin without you running an embedding command. Set KIN_DAEMON_AUTO_EMBED=0 if you would rather it never did. With that provider, embedding runs in process, on your machine.

Checking for updates. Kin does not check for updates on startup or in the background. It asks GitHub for release information only when you run kin update yourself.

Hosted services. Signing in and using hosted remotes or publishing contact the configured service. Local repository queries are answered against your graph. Choosing a hosted workflow changes which data is sent and who processes it.

Optional model endpoints. With KIN_EMBED_PROVIDER set to a remote provider, Kin sends code entity text to the configured embedding endpoint. With kin agent run --base-url <URL>, Kin sends the conversation and tool results to the endpoint you name. Those results can contain graph answers and source code. Local embedding is the default; the agent command requires you to name its endpoint.

Your coding agent. Kin's MCP tools can run locally while the calling agent sends their results to a remote model service. Check that agent's configuration and the selected provider's training, retention, and deletion terms before using it with private code. Local tool execution does not determine where the calling agent processes its conversation.

Kin can record what kin locate did, to help you debug why a query returned what it returned. It is off unless you turn it on, either with kin telemetry consent or the KIN_LOCATE_TELEMETRY environment variable. With no consent marker and no variable set, nothing is written at all.

When it is on, each query appends a line to .kin/telemetry/ inside your repository. Those lines include your raw query text, the file paths that matched, their ranks and scores, and why candidates were dropped. That is sensitive content, which is exactly why it is off by default and why Kin prints a notice to your terminal the first time it engages.

Nothing uploads this file. There is no code in Kin that sends it anywhere, and no command that submits it. Turn it off with kin telemetry revoke and delete what it collected with kin telemetry purge.

KinLab signs you in through Google, GitHub, or Microsoft Entra, and through SAML where an organization has set that up. We never see or handle your password for any of them. What we receive from the provider and store is your identifier at that provider, which provider it was, your email address, your display name, and whether the provider considers the address confirmed.

Alongside that we store your role, your organization memberships, and the timestamps for when the record was created and last changed. Browser sessions and CLI tokens are stored as one-way hashes rather than as the token itself, so the value in our database cannot be replayed as a credential. A CLI token also records the device label you gave it, its scopes, and when it was last used, which is what makes it revocable.

Using the hosted product means the repository content, review context, and collaboration data you connect are processed to render those surfaces to you and to the people you have given access. Request logs and service diagnostics are processed to keep the service running and to investigate failures.

KinLab is in development. Do not put regulated or highly sensitive production data into it without a written agreement covering that use.

Website analytics is kept for 13 months. Events and sessions older than that are removed from our self-hosted Umami database. What we write down about a removal is a count, not a list of people. That database keeps seven daily backups, so a removed record can sit in a backup for up to a week after it leaves the live database.

Inquiries are kept for 24 months after the last contact, as described above. Our inquiry database has no backup copy, so a deletion there takes effect at once. Email replies stay in our mailbox for as long as the conversation does, and a spreadsheet someone exported from our own console is a separate copy that we delete alongside the record when we action a deletion request.

Local Kin data stays on your machine until you remove it. Content sent to KinLab, a configured model endpoint, or through your coding agent has a separate retention and deletion boundary.

In the hosted service, a browser session expires 24 hours after it is issued. A CLI token expires 30 days after it is issued, and you can revoke one sooner. The short-lived code exchanged during CLI sign-in expires after 10 minutes. Account records and the content you connect are kept while your account is active. Write to us at the address below to request deletion. We assess the request, verify identity where needed, and explain any legal or security reason for retaining specific records.

Retention windows and deletion guarantees can still change while the hosted product is in development. Where a separate written agreement exists, that agreement controls.

We do not sell your data, we do not share it with advertisers, and we do not use your code or your repository content to train models.

The hosted service runs on Google Cloud, which stores and processes hosted data on our behalf as our infrastructure provider. Your chosen identity provider, Google, GitHub, or Microsoft, sees the sign-in itself, because that is what signing in through them means. GitHub and Hugging Face see the download requests described above.

Configured model endpoints and the services used by your coding agent can also receive the content described above. We may disclose data if the law requires it, and we would tell you unless we were legally barred from doing so.

You can run Kin without a KinLab account at all. The local product does not require one, and it is open source under Apache-2.0, so you can read exactly what it does rather than take this page's word for it.

You can ask us for a copy of the account data we hold, ask us to correct it, or ask us to delete it and close your account. Write to the address below and we will action it. Depending on where you live, rights under the GDPR, UK GDPR or California law may also include access, portability, correction, deletion, restriction, objection, and withdrawal of consent. You can use the contact address below without creating an account. We may need proportionate identity verification before disclosing or deleting personal records. We do not discriminate against people for exercising applicable privacy rights. You may also complain to your local data protection authority. Withdrawing consent does not change the lawfulness of earlier processing.

Privacy questions, data requests, and account deletion go to troy@kinlab.ai. Security issues go to troy@kinlab.ai so they reach the right place quickly.

Firelock, LLC is the data controller for this site and the hosted service. We update this page as the product changes, and the date at the top is the date of the current version.