AI data use

What Bucker sends to a language model, when, what it never sends, and how to turn it off. This page is written from what the code sends (domain/src/modules/rca/ and workers/src/remediation/), not from what we would like to be true, and it names the file behind each statement so a reviewer can check it. Where something is not built, it says so.

The short version

• By default, nothing is sent to any model. The default provider is deterministic and rule-based: it runs inside the Bucker process, makes no network call and needs no key. Root-cause analysis works without a model. A deployment sends data to a model only if its operator has configured a hosted provider (BUCKER_LLM_PROVIDER) and a key.
• When a hosted provider is configured, four features call it: root-cause analysis (a few short sentences of already-validated facts), the issue summary's first line (the same kind of facts), fix authoring (which includes your source code; see below), and the optional evaluation judge for agent observability.
• One switch turns all of it off, per organization: AI features enabled under Settings → General (the aiEnabled setting). Off, nothing new starts, and a model is never called for that organization.
• Bucker does not train, fine-tune or evaluate any model on your content. Bucker has no model of its own and no training pipeline. The model provider's own retention and training terms apply to what reaches it, and we have no zero-data-retention agreement with any provider. We say so rather than imply one.

What is sent, per feature

Root-cause analysis

Code: domain/src/modules/rca/service.ts (narrate), rca/llm.ts.

Hypotheses and evidence are produced from your stored rows by deterministic rules and validated against real entities. The model is asked only to rephrase the top three hypotheses, one sentence each, and its output is re-validated: a sentence that names a file, function, release or commit that is not in the validated set is discarded and the deterministic wording is kept.

Each call carries:

What that means in practice: file paths, function names, a line number, a release or commit identifier, the minutes between a change and the first error, and a similarity percentage. The effect is the wording of the rule that matched; the exception's own message is deliberately not spliced in, because it is customer-controlled text.

Not sent: the exception message, request data, user data, breadcrumbs, event payloads, log lines, replay, or the issue's full error essence.

Issue summary (the header's first line)

Code: domain/src/modules/rca/summary.ts.

The issue header shows two lines: what failed, and the likely cause. The cause line is the latest root-cause analysis's top hypothesis, word for word, with "from RCA run #n"; no model writes it. The first line is built from stored facts by a fixed template, and only when a hosted provider is in use (and AI features are on) is the model asked to rephrase those facts as one sentence.

Not sent: the exception message, stack contents beyond the top frame, request or user data, breadcrumbs, logs, replay. The answer is shown only if it names no file, commit or number that is not in those facts and asserts no cause; otherwise the template is shown. One answer is reused per issue, analysis run and event count, so a page view does not make a call.

Fix authoring (the remediation loop)

Code: workers/src/remediation/author-llm.ts, prepare-remediation-run.ts.

Fix authoring writes a reproduction test and a patch, so it needs the code. When a hosted provider is configured and a remediation run starts, the prompt contains:

Source code is not redacted, on purpose. The patch is applied by an exact matcher that needs the model to reproduce the repository's bytes character for character; scrubbing the code would break the applier rather than protect anything. Two things bound the exposure instead: the instruction tells the model that everything in the prompt is data and never to follow instructions inside it, and the sandbox refuses any change outside the allowed files regardless of what the model wrote. If your source code must not leave your environment, turn AI features off for the organization (below), or do not connect a repository.

Anything the model writes is run in an isolated sandbox against your tests before it is shown as a verified fix; the model never decides whether a fix is correct, and a human approves every merge (agent governance).

Not sent: other issues, other projects, other organizations' data, credentials, or environment variables. Secret-shaped strings are removed by the storage-tier scrub before anything is persisted, so they are not in the rows these prompts are built from.

Evaluation judge (agent observability, optional)

Code: domain/src/modules/agent-observability/evals-case-shape.ts.

Only when you run an evaluation whose cases escalate to a model judge. The call carries your judge's own prompt (which you wrote), a score computed locally, a pass/fail and at most ten reason strings drawn from the fixed rubric. The agent's output and the reference answer are not sent. With the default provider the judge is deterministic and nothing leaves the process.

Similar issues and grouping suggestions (embeddings)

Code: domain/src/modules/codebase/embeddings.ts, codebase/issue-embeddings.ts, codebase/memory.ts (issueEmbeddingText).

Not a language model: an embeddings provider turns text into a vector of numbers that Bucker stores beside the issue and compares with other issues in the same project. Only when the deployment has configured a hosted embeddings provider and your organization has AI features enabled. Each issue sends four fields — exception type, exception message, title and culprit — when it is created and when its vector is rebuilt. They have had the storage-tier scrub (credentials removed), not the stricter agent-tier pass, so an email address inside an exception message is sent as stored. Your source code is not sent: Bucker's hosted service does not enable source-code embeddings. With AI features off, or no provider configured, issues are compared by shared words inside Bucker and nothing leaves. Details: similar issues and grouping.

Which provider, and whose key

• On Bucker's hosted service, the deployment's key is held only by the service that runs remediation. It is used there for fix authoring and for the root-cause analysis that service runs on its own: the analysis an alert rule's "investigate" action starts, and the one the autofix sweep runs on an issue it stops at analysis. Root-cause analysis you or your agent request (from the dashboard or the API), the issue summary and the evaluation judge run in the API, which holds no deployment key, so for an organization without its own key they use the deterministic provider and nothing is sent.

• Two hosted providers have working adapters (rca/llm.ts): Anthropic (the vendor SDK) and OpenAI (the Chat Completions endpoint; OPENAI_BASE_URL points it at a compatible gateway, a deployment setting only).

• Each organization can bring its own key (SG-069): Agents → Model key, or PUT /orgs/:orgSlug/llm-credential with a provider, a key and an optional model. The key is sealed at rest under the deployment's AUTH_SECRET with a purpose and an org binding (rca/org-llm-credential.ts), is never returned by any route or written to an audit row (the audit row carries the provider, the model and the last four characters), and revoking it wipes the ciphertext. While one is stored, that organization's root-cause analysis, issue summary and fix authoring run on it, and the provider relationship for those calls is the customer's. The evaluation judge below still uses the deployment's provider.

• Without an org key, the deployment's key applies (BUCKER_LLM_PROVIDER, BUCKER_LLM_API_KEY). That provider relationship is Bucker's.

• An org key that cannot be used never falls back to the deployment's key. Analysis falls back to the deterministic wording and records why it degraded (org-llm-key-unusable); a remediation run fails with a named reason. A deployment provider that is selected but unusable likewise leaves analysis on the deterministic wording, and for fix authoring there is no silent fallback: with no key, the run fails with a named reason rather than producing an empty patch.

Retention and training

• Bucker stores results, not a transcript. What is kept is the analysis row (verdict, ranked hypotheses, the evidence it assembled, a clipped summary), the proposal, and its evidence bundle. Bucker keeps no log of what it sent to a model.
• The provider's retention applies to what reaches it. We have not negotiated a zero-data-retention agreement with any provider and do not claim one. See the privacy notice and the trust page.
• Training. Bucker does not use your content to train or fine-tune a model, and has no cross-tenant model or memory. (Cross-tenant fix memory is not built.) Whether the provider trains on API traffic is governed by the provider's own commercial terms; Bucker cannot change those and does not speak for them. If this is a procurement requirement, ask for the terms that apply to the deployment you will use, or store your organization's own key (above), which puts those calls under your own provider contract.

Every call is metered and budgeted

Each model call goes through one metering wrapper (MeteredLlmProvider): a token budget is reserved before the call and charged after it, and a spend entry records the tokens and cost with the agent principal, the user it acted for and the incident, where there are any. There is no path to the provider that skips it. Budgets and the kill switch are in agent governance.

Turning it off

Any organization administrator or owner can change the switch; the change is written to the audit log with the before and after value.

What we have not built

So that nothing here reads as a promise: a zero-data-retention agreement, a per-field opt-out inside fix authoring (the choice today is all of it or none of it), the organization's own key for the evaluation judge, and a contract with any provider on training. Each is a tracked gap, not a claim.