Grok Build sends your third-party model API key to api.x.ai with telemetry on, and its binary carries upload code the published source does not.

What we found.

"With a DeepSeek endpoint configured, no xAI login, and telemetry enabled, 1.0.41 sends three POSTs to https://api.x.ai/v1/tokenize-text at session start. The Authorization bearer was the DeepSeek API key: SHA-256 hashes of the header value and of the key file match on all three requests. The bodies carried the system prompt and tool definitions." "In this mode telemetry is off by default; the issue appears only when a user enables it (features.telemetry=true or GROK_TELEMETRY_ENABLED=1)." The harness sends this, not the model: "Our proxy blocked these requests, so the key did not reach xAI in our tests."

The second point is about the program you run versus the program you can read. The binary contains a "workspace teleport" / snapshot upload family that does not appear anywhere in the published repository, with strings such as "Workspace teleport completed successfully" and "snapshot upload enqueued" sitting beside the kill switch harness.disable_workspace_teleport. And with debug logging enabled and an otherwise default configuration, the debug log shows the path running on every prompt, logging "workspace: snapshot upload skipped" with the reason "no upload queue".

We re-checked the key path on 19 October 2026 against Grok Build 1.0.62. Nothing has changed: with telemetry off by default, no tokenize requests left the machine; with telemetry on, three POSTs again, each bearer hash-matching the configured model key, all blocked by our proxy. The note states behaviour and documentation, not intent.

Where the model key went.

What we tested, and what we saw.

The binary: "The binary we tested (grok 1.0.41, 4220f3b224a6, SHA-256 9ce03ed23e16ea01072b4496263d6213a27899e1e3e107f008d36edf82e70407, downloaded from x.ai/cli; stable and alpha channels both 1.0.41, rechecked 26 September 2026) reports source commit 4220f3b224a6. That commit does not exist in the history of github.com/xai-org/grok-build (checked at f0e3be1, 23 September 2026)." "Tracing metadata in the binary references line numbers beyond the end of the published files (xai-grok-workspace/src/handle.rs to 5533 against 5072 published; upload/mod.rs to 993 against 698; xai-grok-shell/src/upload/trace.rs to 2966 against 2795)."

Method, as sent to xAI: "Finding 1 (static): string and metadata comparison of the official binary against a clone of the published repository. Runtime evidence from the debug log in isolated test runs." "Finding 2: isolated HOME directories on a test server, canary repositories with fake secrets, a TLS-intercepting proxy that blocked everything except model calls, and strace of all connections. Hashes only; the key was never printed." "The headline findings were reproduced by a person from the raw captures."

• The logged-in observation, sent at the time: "In our logged-in test on an individual SuperGrok account, the server returned trace_upload_enabled: true and disable_codebase_upload: true, and the session trace upload was skipped with reason zdr_team. We observed no upload attempt."
• Also sent at the time: "Mixpanel events, grok.com events and trace telemetry events (OTLP spans to cli-chat-proxy.grok.com/v1/traces) carried metadata, including the names of files the agent touched (for example .env and notes/private-notes.md), but not file contents or prompts."
• Re-check, 19 October 2026, batch RETEST-XAI1-20261019T112302Z: five units on the same rig, four on Grok Build 1.0.62 and one 1.0.44 control. In the default units, "tokenize_flows": 0. In the telemetry-on units (the documented switch [features] telemetry = true in config, or GROK_TELEMETRY_ENABLED=1 in the environment), "tokenize_flows": 3 to api.x.ai "/v1/tokenize-text", with "tokenize_bearer_is_model_key": 3 and "bearer_is_model_key": true, every request "blocked": true with "status": 503. The 1.0.44 control behaved the same.

Where they differ.

Our stated point, as sent to xAI: "We are not raising a licence issue. Our concern is transparency: the published source could reasonably be read as evidence that repository uploads were removed after July, while the binary users run contains upload code that the published source does not." On the key path, our suggestion was: "The fix appears simple: do not fall back to a non-xAI credential for xAI endpoints."

What a reader can do with this.

Telemetry and uploads: the local switches held in our logged-in runs. "With a login, the documented local opt-outs (features.telemetry=false, telemetry.trace_upload=false, feedback=false, harness.disable_codebase_upload=true, harness.disable_workspace_teleport=true) overrode the server flags, and all telemetry stopped." And without a login: "In the default configuration without login, only model calls left the machine."

The third-party key: until the fallback changes, a non-xAI credential configured as the model key is what Grok Build will attach to xAI endpoints in this mode. Our question to xAI was: "Will you stop the tokenize-text fallback to third-party credentials, and will any keys already received this way be discarded?"

We also asked: "Will you publish the source for the shipped builds, including the upload path?" and "For consumer accounts without zero data retention, does trace_upload_enabled: true result in a workspace snapshot or teleport upload? Why was an individual SuperGrok account treated as zdr_team?"

What we are not claiming.

• "Our proxy blocked these requests, so the key did not reach xAI in our tests."
• "We did not expect this account to be treated as a zero data retention team, and we cannot tell how the path behaves for accounts that are not."
• "We did not find our canary secrets in any telemetry payload."
• The report states: "We are not raising a licence issue."
• "These trace telemetry events are separate from the session trace upload described in point 1, which was skipped."
• The re-check was five units on one day, on Linux x64, against Grok Build 1.0.62 with a 1.0.44 control. It covers the tokenize-text key path and nothing else; we did not re-run the static binary-versus-source comparison.

Disclosure of interest: "Agentic Thinking also owns AgentProtect, commercial AI agent governance software."

Disclosure timeline.

• 26 Sep 2026: reported to vulnerabilities@x.ai under our disclosure policy, "Please acknowledge within 5 working days." (Date header "Sat, 26 Sep 2026 08:00:40 +0100"; Message-ID <179040604050.2073123.6116362737648962901@agenticthinking.uk>).
• Vendor response: No reply. Our mailbox check in the follow-up thread records: "There is no reply, acknowledgement or bounce from x.ai to the 26 Sep disclosure or the clarification." No reply has arrived since; this note is the publication the email promised, with the responses as above.
• 26 Sep 2026, 11:21: a clarification sent in the same thread to vulnerabilities@x.ai (Subject "Re: Responsible Disclosure", Message-ID <179041808748.2291758.3230887124986347848@agenticthinking.uk>). No reply to either message.
• 19 Oct 2026: re-checked the key path on Grok Build 1.0.62 (batch RETEST-XAI1-20261019T112302Z). Unchanged; nothing is fixed, so there is nothing to credit.
• 26 October 2026: this note published, stating the versions tested and this timeline.

Any response will be added here. Evidence and reproduction steps are available to xAI and to researchers on request: research@agenticthinking.uk.