xAI will watermark Grok API text by default starting November 7

Developers using supported Grok models will soon receive text carrying an invisible origin signal—even without changing their requests. xAI’s output watermarking documentation sets November 7, 2026, as the start of watermarking by default. The change reaches beyond written answers to structured responses and tool-call arguments, with opt-out controls held by team administrators.

The default follows the model across endpoints

The scheduled change covers grok-4.7, grok-4.6, grok-4.5, grok-4.3, grok-4.20-reasoning, grok-4.20-non-reasoning and grok-4.20-multi-agent. The documentation places watermarking on every xAI API endpoint, including its global endpoint and regional endpoints. It applies through both the Responses API and Chat Completions API, the two interfaces named in the instructions.

For a model with watermarking enabled, the scope includes three kinds of generated text:

• Ordinary text responses.
• Structured outputs.
• Tool-call arguments—the generated inputs supplied for a tool call.

There is no request parameter to add. Existing integrations keep the same response format apart from an added header, and the company says watermarking does not change response quality or speed. It describes the measure as a way to comply with the EU AI Act; that is its stated compliance rationale, not a separate legal assessment.

The signal sits in word choices, not hidden characters

The watermark takes shape while the model generates its response. It slightly steers the selection of tokens—the units of text a model chooses as it writes. It does not append a label or insert characters, markup or hidden text. The generated wording itself carries the signal that the company can later check.

That later check is statistical. The detector scores a passage and returns one of three results: watermarked, not watermarked or uncertain. Longer passages provide a stronger signal, according to the documentation. Access to the detection API requires an application, so receiving watermarked output and obtaining the ability to test a passage are separate forms of access.

Developers have a more direct way to check the status of a particular API response: read its x-watermark header. A value of true means that request’s output was generated with the watermark. Any other value, or an absent header, means it was not. This checks the response’s watermark status rather than statistically testing a separate piece of text.

Turning it off carries conditions

Team administrators can manage the default through the Model output watermarking row in the console’s Team settings. Only admins see that row. Its status shows whether watermarking is on for all models, off for all models or customized. The settings dialog lets an admin clear individual model checkboxes or select all models together, then save and confirm an opt-out.

Opting out requires confirmation that an exception under applicable law covers the team’s use. The team must also accept sole responsibility for any marking, disclosure or other legal requirement. Changes take effect for new requests within five minutes: disabling a model stops watermarking those requests, while enabling it restores the signal.

Some models may be locked on for a particular team. They remain visible in the dialog but cannot be disabled through the console. The documentation directs questions about locked models to the team administrator, then support if needed. Every opt-in and opt-out is recorded in the team’s audit log, where administrators can review the changes.