xAI will enable invisible statistical watermarking by default for Grok API text outputs starting November 7, 2026. This update applies to seven specific model IDs, including the Grok 4.7 and 4.20 families, across both global and regional endpoints.
The watermark, which influences token selection without altering visible text, is verified via the x-watermark response header. Administrators can opt out of this setting per model, though changes affect all team API keys and may require legal attestation regarding compliance exceptions.
xAI will enable invisible statistical watermarks by default for supported Grok API text output on November 7, 2026. The change covers global and regional endpoints, including ordinary responses, structured outputs and tool-call arguments, according to the company’s Output Watermarking documentation.
The rollout, reported by TeslaNorth on October 31, requires no new request parameter. Existing integrations can continue sending the same requests. Teams do, however, have a decision to make: retain the default or have an administrator pursue a per-model opt-out.
I’d treat this as an observability and governance change first. Applications need a reliable record of whether each response was generated with watermarking, while administrators need to understand that their setting affects every API key on the team.
Which Models and Outputs Are Covered?
The official documentation lists seven model IDs for the November 7 rollout:
Coverage extends across text-generation APIs, explicitly including the Responses API and Chat Completions API. It applies on the global https://api.x.ai endpoint and regional endpoints. Changing regions therefore provides no documented route around the default. The same model-level team setting governs watermarking. Source: xAI documentation
The affected output includes:
Ordinary generated text.
Structured outputs.
Generated tool-call arguments.
That last pair matters for application developers. This is broader than marking prose shown in a chat window: generated content consumed by software is also within scope.
The watermark works during generation by slightly influencing token selection. It adds no visible characters, markup or hidden text. There is consequently no watermark string for a JSON parser to remove, and no extra field that applications need to strip from tool-call arguments.
That mechanism also sets a sensible testing priority. I’d keep normal schema-validation and tool-selection checks in the rollout plan because the generated content is covered, while avoiding an unnecessary “watermark cleanup” stage. The documentation describes a statistical generation process, not an appended payload.
Statistical Detection Is Different From Header Inspection
xAI describes detection as scoring a piece of text against its watermark. The detector can return three classifications:
Classification
Meaning in the documented detection scheme
Watermarked
The detector classifies the text as carrying the watermark.
Not watermarked
The detector classifies the text as not carrying the watermark.
Uncertain
The detector cannot give a confident classification.
Longer text provides a stronger signal. Short responses therefore deserve particular care in any verification workflow. A few generated tool arguments or a brief structured value provide less material for statistical analysis than several paragraphs. Source: xAI documentation
The available evidence provides no detection accuracy rates, minimum reliable text length or workload-specific measurements. It also provides no basis for assuming that detection remains equally reliable after editing or other transformations.
My practical reading is that “uncertain” must remain a real application state. If a downstream system converts it into “human-written” or “not AI-generated,” that system adds a conclusion the detector did not supply. Even “not watermarked” should be understood as a watermark classification, not a general proof of human authorship.
Detection access is also application-gated, according to TeslaNorth’s account of the documentation. Teams should not build a rollout dependency on immediate detector access.
For responses your own application receives directly, the response header is the more straightforward operational signal. It reports whether watermarking was used for that request, without requiring a later statistical assessment of the text.
Read and Preserve the x-watermark Header
The documented rule is explicit:
x-watermark: true means the output for that request was generated with the watermark.
Any other value, or no header, means it was not.
This header is available on Responses API and Chat Completions API responses. No watermark request parameter is required. Source: xAI documentation
The documentation supplies a Python example using the OpenAI SDK’s raw-response interface. With that package installed and XAI_API_KEY set, the following request exposes both the HTTP headers and parsed response:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["XAI_API_KEY"],
base_url="https://api.x.ai/v1",
)
raw = client.responses.with_raw_response.create(
model="grok-4.7",
input="Write a haiku about the ocean.",
)
response = raw.parse()
print(raw.headers.get("x-watermark"))
print(response.output_text)
The example reads the watermark header before printing the generated text. It illustrates the documented integration pattern; it is not a reported test result.
For production logging, I’d record the model ID, endpoint, timestamp and original header value alongside the application’s request identifier. Preserve an absent header as an explicit state instead of silently converting everything into a Boolean.
That distinction helps diagnose integration problems. Under xAI’s documented semantics, absence means the response was not watermarked. But if an internal gateway or SDK wrapper drops the header before your application sees it, your logs no longer establish what the original upstream response contained. Capture it at the earliest practical boundary.
The header is also transport metadata. Copying only the generated text into a database, document or another service will not automatically preserve it. Store the provenance record alongside the content if later auditing matters.
Administrator Opt-Out Has Team-Wide Consequences
xAI documents watermarking as a per-model setting controlled by team administrators in its console. A change applies to every API key on that team, so it is not a separate choice each application makes in its request body. Source: xAI documentation
Additional details come from published summaries. Azeem Hassni’s November 1 report says opting out requires confirming that a legal exception applies and that changes enter the audit log. TeslaNorth reports that settings take effect within about five minutes and that some models may be locked on, preventing console opt-out.
Those details make the administrator workflow worth preparing before rollout:
Inventory affected traffic. Identify applications using the seven listed model IDs, including regional deployments.
Assign an administrator. The console setting has team-wide scope; individual API-key owners cannot treat it as an isolated preference.
Choose settings per model. Check which controls are available and whether any model is locked on.
Review the exception requirement. If opting out, establish the applicable legal basis before making the confirmation.
Verify the resulting state. Allow for the reported propagation delay, then inspect x-watermark on subsequent responses.
xAI gives EU AI Act compliance as the reason for watermarking. That is the company’s stated rationale, not an independent legal assessment. Hassni’s report also notes that the documentation does not spell out which uses qualify for the opt-out exception.
My view is that the legal-attestation step changes the nature of this control: it belongs in a documented administrative decision, not an undocumented troubleshooting toggle. Teams using several providers can also compare the change with Zeniteq’s coverage of Anthropic’s reported November 3 watermark rollout.
The reported five-minute propagation window and team-wide scope make advance coordination useful. Decide the intended setting, document who approved it, and verify the headers before relying on that state in production.
Frequently Asked Questions
3 questions
1
Do Developers Need to Change Their Requests?
No. xAI says watermarking requires no new request parameter. Applications that want to track it should read and preserve the x-watermark response header.
2
Can Each API Key Choose Its Own Setting?
No. Administrators control watermarking per model for the whole team, and the setting applies to every team API key.
3
Can Anyone Immediately Use the Text Detector?
Detection access is application-gated, according to the published reporting. Receiving the x-watermark header on your own API responses is separate from obtaining access to statistical text detection.
