Cloud AI Analysis

clonit analyze uses AI to read a target’s schema, flag columns that look sensitive (PII, credentials, financial data, and so on), and generate a versioned sanitization SQL query you can review and run. When Clonit Cloud is connected, that analysis runs server-side, per organization instead of on your machine — a single shared analysis and generated query are available to your whole team, and the Anthropic key that pays for it is resolved along a fixed precedence ladder (your personal key, if you set one, then the organization keys, then the deployment key).

The command and its results are identical either way. What changes is where the LLM runs and whose Anthropic key pays for it.

Local analysis still available

With no cloud connection, clonit analyze runs locally using your own Anthropic key (analysis.api_key) — see the Sanitization Analysis guide for that flow. This page covers what changes once the cloud is connected.

What leaves your machine — and what never does

This is the most important thing to understand about cloud analysis:

• What is sent: your target’s schema metadata (table, column, and data type names) and, unless you turn sampling off, a few sample rows per table to improve detection accuracy. The agent introspects your source database locally and ships only this metadata to the cloud.
• What is never sent: your database connection URLs and credentials. The agent connects to your database itself, on your machine. The cloud runs the LLM with its own Anthropic key and never sees how to reach your database.

Sample rows contain real data

Sample rows are taken from the live source database, so they can contain real, sensitive values. They are sent to the cloud (and on to the LLM provider) to sharpen detection. If you would rather analyze structure only, run with --no-samples to send the schema and nothing else. See Sampling and privacy below.

How Clonit chooses cloud vs. local

The routing is automatic and follows one rule:

• Cloud is connected (you’ve run clonit login or set a cloud.api_key) → analysis runs in the cloud. The CLI tells you so:

  Cloud connected: analysis will run server-side (use --local to force local).

• Cloud is not connected → analysis runs locally with your own analysis.api_key.

• Cloud is connected but you pass --local → analysis is forced to run locally with your own key, skipping the cloud entirely.

If the cloud is connected but momentarily unreachable, Clonit falls back to a local analysis — provided you have a local analysis.api_key configured. With no local key and no reachable cloud, the command stops with:

analysis API key not configured; set analysis.api_key (or CLONIT_ANALYSIS_API_KEY),
or connect a cloud that runs analysis (clonit login)

The web UI’s Analyze button reflects this automatically — it is disabled, with the reason shown, when neither a local key nor cloud analysis is available.

Running a cloud analysis

The command is the same one you already know:

clonit analyze mydb

From clonit analyze --help:

Analyzes the target database schema using AI to identify sensitive columns
(PII, credentials, financial data, etc.) and generates a sanitization SQL query.

Usage:
  clonit analyze <target> [flags]

Flags:
  -h, --help              help for analyze
      --local             force local LLM analysis even when cloud is configured
      --model string      override Claude model
      --no-samples        skip data sampling (schema only)
      --sample-rows int   rows per table for sampling (default from config)

Flag	What it does in the cloud flow
--local	Bypass the cloud and run the analysis on this machine with your own analysis.api_key.
--no-samples	Send schema metadata only — no sample rows leave your machine.
--sample-rows <n>	Number of rows per table to sample (default 3 from config).
--model <name>	Suggest a Claude model for this run.

–local for a quick privacy check

--local is handy when you want to keep one specific analysis entirely on your own machine and your own key, even though the cloud is configured. Everything else about the command is unchanged.

Async: submit, then poll

Cloud analysis is asynchronous. From your point of view at the keyboard, the command:

1. Introspects the schema (and samples rows, unless --no-samples) locally.
2. Submits the metadata to the cloud, which accepts it and queues the work.
3. Polls the cloud until the analysis reaches a terminal state — completed or failed — then prints the results.

You run one command and wait; the submit-and-poll handshake happens for you. A typical analysis completes in roughly 30–120 seconds depending on schema size and how many sample rows you send. Because the work is queued server-side, multiple analyses across your organization can be in flight at once without interfering with each other.

What you get back

A successful analysis produces the same two outputs as the standalone flow, now shared at the organization level:

• A column sensitivity report — each flagged column with its table, data type, sensitivity category, confidence, the reason it was flagged, and a suggested sanitization approach.
• A generated, versioned sanitization query — saved as the active query version for the target, ready to review, edit, or run.

Manage those query versions exactly as you would locally:

clonit analyze queries mydb        # list every generated/imported version
clonit analyze show mydb           # show the active query (or: show mydb 2)
clonit analyze activate mydb 2     # choose which version is active
clonit analyze import mydb fix.sql # bring in your own SQL as a new version

See the analyze command reference for full details on these subcommands.

Which Anthropic key pays: the four-tier ladder

The cloud resolves which Anthropic key runs each analysis through a fixed precedence ladder — the same four names you will see everywhere (CLI, web UI, this page). Top wins:

#	Key	Wire name	Who sets it	Where
1	Personal key	user	You, for yourself	Your account settings (“My settings” page in the auth service)
2	Organization key (Clonit)	org	An org admin/owner	clonit cloud analysis-key set or the web AI Analysis card
3	Organization key (account settings)	auth	An org admin	The auth service’s org app-settings page
4	Deployment key	deployment	The cloud operator	The deployment’s own shared key (a deployment may disable this tier)

How the tiers behave:

1. Personal key. If you set a personal Anthropic key in your account settings, analyses you trigger use it — beating every organization key and the deployment key. Analyses triggered by CI/automation (org-level API keys, service accounts) never use anyone’s personal key; the personal tier only fires for a real signed-in user (web UI, clonit login session, or a user-scoped key).
2. Organization key (Clonit). The org’s own key, stored encrypted (AES-GCM at rest) in the cloud, used only server-side, and never returned by any API or shown back to you.
3. Organization key (account settings). An org-scoped Anthropic key an org admin set in the auth service’s app-settings UI. It counts as an organization key — it satisfies a deployment that requires one — and uses the deployment’s default model.
4. Deployment key. The deployment’s shared key, unless the deployment is configured to require a non-deployment key (require_org_key), in which case this tier is disabled — a personal key or either organization key still works.

The auth-backed tiers (1 and 3) are best-effort: if the auth service is unreachable or your org/user isn’t linked to it, resolution silently falls through to the next tier — an auth outage never fails an analysis. If nothing is set at all, analysis stops with an error.

Never guess which key is in use — ask:

• clonit cloud analysis-key status prints the ladder as a table, with each tier’s configured state and an “in use for you” marker;
• the web AI Analysis card (Settings → Organization) shows the same precedence list;
• each finished analysis records the key that actually served it — the CLI prints it (“Analyzed in the cloud using: Personal key”), and the target’s analysis history in the web UI shows it as a badge.

Usage attribution

Whichever tier pays, token usage is metered per organization, and each analysis additionally records which key served it and who requested it. clonit cloud analysis-key status (and the web card) therefore show, besides the org totals:

• usage by key — analyses and tokens grouped by the four ladder tiers;
• your usage — the analyses you personally triggered and their token cost.

The per-key and per-user breakdowns cover analyses run after the cloud gained attribution; the org totals remain the authoritative all-time figures. Analyses enqueued by org-level automation are counted in the org totals and the by-key breakdown, but belong to no user.

Setting your personal key

Set your personal key on the auth service’s My settings page for Clonit — the web UI links it from the AI Analysis card’s “Personal key” row (“Set your personal key”), from the Organization card (“My settings”), and from the top-bar user menu; clonit cloud analysis-key status prints the same URL. The key is user-scoped: only analyses you trigger use it, and no one else (including org admins) can read it back.

Setting the org key

Setting the organization key (Clonit) requires an org admin or owner role, and acts as you (from your clonit login session), not as the agent. Two ways to do it:

• CLI — manage the key with clonit cloud analysis-key:

  clonit cloud analysis-key set        # prompt for the key without echo
  clonit cloud analysis-key set sk-ant-...          # pass it inline
  op read "op://Vault/item/credential" | clonit cloud analysis-key set  # pipe it in
  clonit cloud analysis-key status     # the key ladder, which key is in use for you, and usage by key
  clonit cloud analysis-key clear      # remove the org key (the ladder falls through)

  set takes an optional --model flag to pin a model for this org (empty = the deployment default).

• Web UI — open Settings → Organization in the web UI and use the AI Analysis card to set, replace, or clear the key (also admin/owner only). See serve.

The organization key (account settings) variant is set on the auth service’s org settings page instead — the AI Analysis card and analysis-key status link straight to it.

Where keys live

Members never type an Anthropic key into Clonit to run a cloud analysis — the organization keys live in the cloud or the auth service, and a personal key lives in your own account settings. The local analysis.api_key in your config matters only for the standalone/--local path.

Sampling and privacy

By default Clonit samples a few rows per table and includes them in the analysis to improve accuracy. You control this per run:

# Schema only — no row data leaves your machine
clonit analyze mydb --no-samples

# Send more rows per table for harder-to-spot columns
clonit analyze mydb --sample-rows 25

Setting	Default	Effect
--no-samples	off (sampling on)	Send schema metadata only; no sample rows transmitted.
--sample-rows <n>	3	Rows per table to sample and send when sampling is on.

Pick the level of sharing that fits your data. --no-samples is the most conservative: the cloud and the LLM provider see only table, column, and data type names — never any row values. More sample rows generally means better detection, at the cost of sending more real data off the machine.

Quick reference

Situation	Where it runs	Whose Anthropic key	Sample rows sent?
Cloud connected, default	Cloud (async)	Personal key → organization key (Clonit) → organization key (account settings) → deployment key	Yes, unless --no-samples
Cloud connected, --local	This machine	Your analysis.api_key	Yes, unless --no-samples
No cloud connection	This machine	Your analysis.api_key	Yes, unless --no-samples
Cloud connected but unreachable	Falls back to this machine (needs analysis.api_key)	Your analysis.api_key	Yes, unless --no-samples

See also

• analyze command — full flag and subcommand reference.
• Sanitization Analysis guide — the standalone analysis flow and how generated queries feed sanitization.
• Clonit Cloud — what the cloud extension adds overall.
• Sign In & Login — connect this machine so analysis runs server-side.
• sanitize command — run the sanitization pipeline using the generated query.