Data & Security

How your data is handled

Effective 2026-05-07

This page describes, at the implementation level, what the Plugin sends, what our servers store, and what controls you have. It is the technical companion to the Privacy Policy; if anything here conflicts with that policy, the Privacy Policy wins.

1.The two data paths

The Plugin’s data leaves your machine on two independent paths:

  • You ↔ AI provider (currently Anthropic). The Plugin makes the API call directly using your API key. Your key, your prompt, and any Blueprint contents the agent reads or writes go to the provider on this path. Nothing on this path is proxied through Kismet servers, and we cannot see it.
  • Plugin → Kismet. The Plugin separately sends usage telemetry, errors, and crash reports to your Kismet account. This path is described in the rest of this page.

2.What we store, in detail

2.1 Your API key

Never sent to us. The Plugin stores it locally in your operating-system credential store (Keychain on macOS, Credential Manager on Windows, libsecret on Linux). It is read at agent-run time and used to sign the request to the AI provider; it never appears in our network traffic, our logs, or our database.

2.2 Your Blueprints

Redacted before storage.The agent reads and writes Blueprints by exchanging T3D text with your editor. That text is part of the agent’s message stream, which the Plugin streams to our telemetry endpoint. Before it is written to the database, our endpoint walks the message’s content blocks and replaces the body of any tool_result for read_blueprint, write_blueprint, or edit_blueprint with a redaction marker. The agent’s tool-call intent (which tool, with which arguments) is preserved so we can still investigate failures, but the Blueprint bytes are dropped at the boundary.

2.3 Account data

Email, optional display name, password hash, OAuth identity, and a per-account profile row with your telemetry preferences and account-deletion state.

2.4 Plugin auth (device-code flow)

When you authorise the Plugin from a browser, we generate a short device code (e.g. A7K2-QX9P) that the Plugin polls for. On claim, a long-lived bearer token is issued. We store only its SHA-256 hash; the plaintext exists on the server briefly (until the Plugin polls and receives it, then it is deleted) and is never written to logs.

2.5 Machine row

One row per Plugin install: a random machine_id (UUID; not your hostname or hardware serial), OS family, Unreal Engine version, Plugin version, first-seen and last-seen timestamps, optional display name you set in the dashboard.

2.6 Run records

One row per agent run: timestamps, the model used, your initial prompt, the project name and Blueprint asset path you targeted, status, stop reason, token counts (input, output, cache read, cache create), step and tool-call counts, and the computed USD cost.

2.7 Run messages

The full Anthropic message exchange for the run, with the redaction in §2.2 applied. Roles are user, assistant, tool_result, or system; payload is JSON.

2.8 Tool-call events

Per-tool granular events: tool name, success or failure category, duration. Used to debug agent behaviour at scale.

2.9 Error logs

Plugin-side warnings, errors, and fatals: log category, message, source file and line, stack trace, optional run-correlation ID, and a small JSON context object.

2.10 Crash reports

If the editor crashes while the Plugin is loaded: signal type (e.g. SIGSEGV), the editor’s crash-context XML, a parsed call stack, the last ~32 KB of the editor log, and basic environment metadata (OS, UE version, Plugin version). These payloads may incidentally contain file paths, asset names, or fragments of serialised data; we do not parse them for content and read them only when investigating a specific crash you have asked us to look at.

2.11 Bug reports

Description you write, optional session ID, and any telemetry snippet you choose to attach (≤ 1 MB). Bug reports do not respect the per-category telemetry toggles — sending a bug report is implicit consent to share the content you wrote. Avoid pasting secrets into bug descriptions.

2.12 Local-only telemetry log

For your own debugging, the Plugin writes a JSONL file at <Project>/Saved/Logs/KismetAI-telemetry.jsonl. This file stays on your disk. It is not transmitted unless you attach it to a bug report; even with telemetry fully disabled, that local file still grows. Delete it manually if you don’t want it.

3.Telemetry controls

Four independent toggles, available at Settings → Telemetry:

  • Runs — gates start/end records and the run message stream described in §2.6 and §2.7.
  • Tool calls — gates per-tool events in §2.8.
  • Errors— gates the error-log stream in §2.9 and related “api_error,” “t3d_inject_error,” and “compile_error” events.
  • Crashes — gates crash reports in §2.10.

When a category is off, the corresponding endpoint accepts the POST and returns 204 without writing to the database. Turning off all four is the strongest stance the dashboard exposes today; only essential heartbeat events (plugin loaded / unloaded, last-seen on the machine row) continue to flow so the dashboard knows the Plugin is connected.

4.No model training on your data

We do not train, fine-tune, distil, or evaluate AI models on your prompts, the assistant’s replies, your Blueprints, or your telemetry. We do not allow third parties to do so. Narrow exceptions for explicit feedback, security review, and opt-in are described in §6 of the Privacy Policy.

5.Authentication and authorisation

  • Web sessions are issued by Supabase Auth as HTTP-only cookies and expire after one hour, refreshed automatically by the SDK.
  • Plugin tokens are 32-byte random tokens. Only the SHA-256 hash is stored; comparison happens with a constant-time check on every Plugin request.
  • Row-level security (RLS)is enabled on every user-data table. A user’s queries can only return rows their account owns; cross-account access from the standard client is impossible. Policy details: Supabase RLS docs.
  • Service-role queries from our Next.js routes bypass RLS by design. Each route is the trust boundary: it authenticates the caller (bearer token for Plugin endpoints, cookie for web endpoints) before it touches the service-role client.

6.Administrative access

Kismet is currently operated by a sole proprietor. Administrative database access is held by the operator alone. We are upfront about this:

  • The operator can technically read any row in any user-data table, including run records.
  • The redaction in §2.2 applies regardless — the operator also cannot see your Blueprint contents, because they are not stored.
  • The operator accesses stored data only when it’s necessary to provide support, investigate abuse, respond to a security incident, or comply with the law.
  • We are working on per-query audit logging for that access; until it is in place, this disclosure is the honest description of our current setup.

7.Encryption and infrastructure

  • In transit: TLS 1.2+ for all traffic between the Plugin, browser, and our endpoints.
  • At rest: our Postgres database and Plugin-release storage are encrypted at rest by the underlying providers (Supabase, Cloudflare R2).
  • Hosting: Site on Vercel; database and edge functions on Supabase; rate-limiting via Upstash Redis (sees your IP briefly as a rate-limit key, no persistent personal data); Plugin release archives on Cloudflare R2. None of these are sub-processors of the AI provider, and none of them receive your prompts or Blueprint contents.
  • Performance monitoring: Vercel Speed Insights collects page load timing, route, country, and anonymised IP for our own performance monitoring. It sets no cookies and uses no cross-site identifiers. It does not see your prompts, Blueprints, or telemetry payloads.

8.Retention

See §10 of the Privacy Policy. Summary:

  • Account data, runs, telemetry, errors, crashes, bug reports: retained for the life of the account. No automatic TTL.
  • Demo and contact-form submissions: deleted no later than 12 months after submission unless they have led to an ongoing customer relationship.
  • On account deletion request: Plugin tokens are revoked immediately; hard deletion runs monthly, so the actual purge happens within 30–60 days.
  • Plugin auth codes / plaintext tokens: ephemeral — codes expire after 10 minutes; the plaintext token row is deleted on first poll (seconds at rest).

9.Vulnerability disclosure

Send security reports to legal@kismetai.io with subject “security”. Please include enough detail to reproduce the issue. We acknowledge reports within five business days. Do not test against the live Service in a way that could affect other users; if you need to do destructive testing for a specific finding, contact us first and we will coordinate.

10.Things we don't do (and don't plan to)

  • We do not run marketing pixels, ad trackers, or session-replay tools on the Site. The only performance telemetry we collect is anonymised web-vitals via Vercel Speed Insights (no cookies, no cross-site identifiers — see §7).
  • We do not sell personal data and do not allow it to be used for cross-context behavioural advertising.
  • We do not proxy your AI-provider traffic. Your key, your prompt, your provider — direct.
  • We do not use your data to train models, ours or anyone else’s.
Want a control we don’t expose yet? Email legal@kismetai.io. Reasonable requests (project-level redaction, bulk export, run-level deletion) are on the roadmap; faster if there’s pull.