Privacy Policy

Overview

AiKey's main-site and installer collect only the minimum telemetry needed to improve the product. The pipeline does not require an email, does not require sign-up, does not tie events to any account. This page lays out exactly what fields are collected, why, how long they live, and how you reset or delete them. If anything on this page doesn't sit right with you, don't install — running the installer constitutes informed consent.

Anonymous Install ID (installer_id)

On first install, the installer writes a random UUID v4 to ~/.aikey/identity (macOS / Linux) or %LOCALAPPDATA%\Aikey\identity (Windows). The file is mode 0600 and persists across re-installs. This UUID is your installer_id.

• Not bound to email, username, IP, hostname, machine serial, or any personally identifying value.
• Only two uses:
  1. Unique-install dedup — distinguishing "re-install / upgrade" from "new independent user".
  2. Invite attribution slice — see next section.
• Dashboards and analytics never display the raw value — only MD5(installer_id) truncated to the first 6 chars.

Invite Attribution (inviter_id)

When you install via someone else's invite link (https://aikeylabs.com/i/inv/<code>), the main-site server looks up the inviter by the invite code and stamps the inviter's installer_id onto your install event as inviter_id.

• The invite URL itself carries no identity — just an 8–12 char random code; the lookup happens server-side.
• inviter_id is still an anonymous UUID; dashboards likewise show only the first 6 chars of its MD5 hash.
• An inviter can only see invite links they generated themselves (and only if they saved the URL); the server provides no "list every invite from this installer_id" endpoint, so even if an inviter's identity leaks, history enumeration isn't possible.
• Invite attribution does not double-count installs — it's an extra slice next to channel attribution, not an additional total.

How to reset / forget your identity

To fully rotate your anonymous identity, delete the file:

• The next installer run (or any aikey command) regenerates a fresh installer_id.
• Historical events keep the old ID server-side, but they're no longer linkable to your future behavior.
• MVP intentionally does not expose a reset button in the UI to prevent accidents, and does not ship an aikey identity reset shortcut.

Event collection & retention

The main-site only ingests the following event categories:

• "Identity-bearing" events (install / invite) keep a raw_ip column for 30 days, used only for incident response (e.g. tracing an abuse spike). Reads go through a DBA-only SQL audit log; dashboards never display it.
• Browsing events convert raw_ip to ip_region (country code) at ingest; the raw value is never persisted.
• MVP v1 does not implement an automatic retention cron. Once volume reaches the §8.4 threshold (90 days hot + 1 year archive) the policy lands and this page is updated.

Dashboards: usage boundary

All invite aggregations (Top N, funnel, inviter-channel × invitee-OS matrix) are for internal trend analysis only — they are not a reward, settlement, public leaderboard, or external ranking. The current anti-forgery floor protects against "outside-the-secret forgery" only; it does not defend against internal key leakage, in-24h replay, or self-installs inflating one's own count. The day we introduce an incentive layer, we'll first add a stateful nonce table, per-installer rate limits, and bot pattern filters — and update this page accordingly.

What we don't collect

• We do not read anything in ~/.aikey beyond identity (your Vault, configs, logs all stay local; the main-site has zero knowledge of them).
• No Provider API Keys, OAuth tokens, conversation content, or token-usage details — the main-site servers neither receive nor store any of it; the ingest endpoint accepts only the install / page event fields enumerated above.
  Where that data actually lives depends on how you deploy AiKey — see the next section.
• No browser fingerprinting, no third-party trackers.
• The main-site itself has no login cookie. The /local-api/* CSRF cookie only travels between your browser and your local aikey web server; it never leaves your machine.

Where your data lives: the main-site is not your deployment

The section above is about aikeylabs.com — the servers we operate do not receive your keys, your conversation content, or your usage details. But "the main-site doesn't collect it" and "it never leaves your machine" are two different statements: AiKey can be deployed in several shapes, and where the data lands is decided by you or your company, not by us.

• Personal edition — there is no team server. Your Vault, conversations, and usage all stay on your machine and are uploaded nowhere.
• Production / Cluster editions — a server your company self-hosts receives usage data, and, when conversation audit is enabled, conversation content. Those servers are owned and operated by that company; AiKey neither runs them nor can access them.

Conversation Audit deserves its own paragraph. When a company turns it on, the full verbatim text of conversations routed through AiKey (your prompts and the AI's replies) is uploaded to and retained on that company's own team server. Administrators can view and export it per seat, and viewing or exporting the content writes an access-audit record. The product's built-in cleanup policy keeps roughly 12 months, but how long the data is actually retained is determined by that company's deployment and operations. It is on by default when the Cluster edition is installed; the Personal edition does not have the feature, and the Production edition defaults to off. If you are an employee, whether it is on is your company's decision — ask your administrator.

The detection step of compliance detection (sensitive-data masking) always runs on your own machine: the full conversation text does not leave your computer because of the inspection. The two channels are independent and each decides separately what it uploads.

What compliance detection uploads (Team / Cluster)

Personal edition: the matched original text stays on your machine and is not uploaded.

Team / Cluster editions: when your organization's compliance privacy policy allows it, a short window of the original text around the match (at most 512 bytes) is uploaded with the compliance event to the team server your company self-hosts, where administrators can see it, and is cleared automatically after 90 days. The compliance event itself (category, severity, counts) is retained beyond that.

About the default — note the distinction between two cases: a fresh install of the Team or Cluster edition has this on out of the box, so a new deployment uploads matched original snippets from day one; an upgrade of an existing deployment changes nothing and stays off until an administrator explicitly enables it. The switch is controlled solely by the organization policy on the server — there is no local setting on an employee machine that can turn it on.

What holds for both channels: whether it is a matched original snippet or the full conversation text, it lands only on your own company's servers and never reaches any AiKey server — AiKey (the vendor) neither operates those servers nor can access the data. If you are an employee and want to know whether your company has this on, ask your administrator.

Contact

If you observe collection behavior that diverges from this page, or you'd like us to delete events tied to a specific installer_id, please open an issue on the aikeylabs GitHub repo — sharing only the first 6 chars of your MD5 hash is enough; we don't need the raw UUID. We aim to respond within 5 business days.