Grok API Watermark Starts 7 November: What Builders Must Do

Key Takeaways

• From 7 November 2026, text from seven Grok API models carries an invisible watermark by default, according to xAI developer documentation reported by multiple outlets.
• The seven models are 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, on every API endpoint.
• The mark shapes token selection during generation and adds no characters, markup, or visible text.
• The x-watermark response header shows true when a response was watermarked.
• Team admins can opt out per model in the SpaceXSI Console, but only after confirming a legal exception applies, and the team then bears responsibility. Some models may be locked on.
• Detection is statistical, with three outcomes, watermarked, not watermarked, or uncertain, and access is by application only.
• The stated reason is EU AI Act compliance, under Article 50 transparency rules, with a 2 December 2026 deadline for pre-existing systems.
• The change covers API text only. It does not, as far as the documentation reported so far shows, cover grok.com, the Grok apps, or Grok on X.

An invisible mark, switched on by default

If you build with Grok through its API, a quiet change arrives on Saturday 7 November 2026. From that date, text returned by seven Grok models will carry an invisible watermark by default. You do not need to change your code to receive it. You do not need to send a new parameter. And your users will not see anything different, because the watermark adds nothing visible to the text at all. That combination, automatic, invisible, and consequential, is why the change deserves a careful explanation rather than a one-line announcement.

The source for the change is xAI’s developer documentation, where the company appears under the name SpaceXSI. Multiple outlets reporting on the documentation agree on the core facts: the date, the seven models, the default-on setting, the header, the opt-out process, and the EU AI Act reason. Where outlets differ or where the documentation itself is silent, this article says so, rather than filling the gap with a guess. That matters, because a watermark is only useful if people understand exactly what it does and does not prove.

Which models, and which channels

The seven models covered are 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 marking applies on every xAI API endpoint, including the global api.x.ai endpoint and regional endpoints, so it is not a setting reserved for European developers. It covers both the Responses API and the Chat Completions API, and inside a response it touches plain text, structured outputs, and the arguments of tool calls, which are the commands the model hands to another program.

The scope is, in practice, the API. For the Grok app, the website grok.com, and the subscription inside X, no date has been announced, according to the reporting on the documentation. One outlet notes that Superpower Daily points out the change targets developer products, not consumer ones. That distinction is important for ordinary Grok users. If you chat with Grok in the app or on X, nothing in the reported documentation says your text will be watermarked from 7 November. If the same text passes through an API, an automation, or a third-party service that uses the API, it can come out marked without anyone noticing, because the mark is invisible by design.

This is also why the change matters more to builders than to readers. A reader will never see the watermark. A builder who puts Grok inside a product, a customer support tool, a content pipeline, or a student-facing service will have to decide, model by model, whether to keep the mark, and to record the reason. That decision, and the paperwork around it, is the real work of 7 November.

How a watermark that adds nothing actually works

A text watermark sounds like a hidden stamp, but the Grok watermark described in the documentation works differently. While the model writes, it slightly shifts the probabilities it uses to choose words. At each step, the model has a range of plausible next words. The watermarking process nudges that choice in a statistically detectable direction, without inserting hidden characters, tags, or markup. A reader notices nothing. Copying and pasting leaves no visible trace, because there is no visible trace to copy.

Checking, therefore, is not a matter of looking for a hidden character. It is a matter of statistics. A detector, holding the right key, examines a piece of text and asks whether its pattern of word choices looks like the pattern the watermarking process would produce. The detector gives three possible outcomes: watermarked, not watermarked, or uncertain. The signal gets stronger as the text gets longer. On a paragraph, the signal is weak. On a full page, it becomes readable. On a short or heavily edited text, the most likely answer is uncertain, and the documentation, as reported, does not say how well the mark survives a rewrite or paraphrasing. That limitation should be kept in mind by anyone tempted to treat a watermark result as a final verdict.

The detector itself is not public. Access goes through an application form, so today no journalist, teacher, or company can check a suspicious Grok text on their own, unless they have been granted access by xAI. An ordinary AI text detector, which measures writing style, does not read this signal, and is not an equivalent alternative. That gap between a mark that is on by default and a detector that is available only by application is one of the most important practical facts about the system. It means the watermark is currently more useful as a record for those who already have access than as a general tool for the public to verify authorship.

Developers do have one direct tool. Every response from the two APIs carries the HTTP header x-watermark, and the value true means that request was generated with the mark. Any other value, or no header at all, means the mark was not there. For a company that has to prove what it marked, that header is a small but handy record, and it is worth logging if your compliance depends on it.

How to turn it off, and who answers for it

Team admins find a row called “Model output watermarking” in the xAI console, which shows whether the mark is on for all models, off for all, or customised. You untick the models you want to exclude, save, and confirm. Changes reach new requests within five minutes, apply to every API key on the team, and land in the audit log, according to the reporting on the documentation.

The part that weighs most is the confirmation. Turning the watermark off means declaring that a legal exception applies to that use and that the team takes on every marking or disclosure obligation by itself. Responsibility, in practice, moves from the provider to the user. That is not a casual toggle. It is a legal statement, and it should be made only after someone who understands the applicable law has reviewed the use case. Some models may also show up locked on for a given team, in which case the checkbox does not even appear. If you find a model locked on, that is not a bug to work around. It is a constraint to plan around, and it should be recorded as such.

For anyone with products already in production, the deadline is short. It makes sense to read the console row right away, decide model by model whether to keep the mark, and write down the reason. If the text ends up with customers, students, or readers, the simplest route is still to disclose the use of AI in plain language. The watermark helps whoever wants to check, but it does not replace a clear sentence in the document. Transparency that only a detector can read is not transparency for a human reader.

Why xAI is doing it now: the EU AI Act

The stated reason for the change is compliance with the EU AI Act. Article 50 of the regulation asks providers of systems that generate synthetic text, images, audio, or video to mark outputs in a machine-readable format that can be detected as artificial. The transparency obligations run from 2 August 2026, and for systems already on the European market before that date, analysis cited in the reporting points to a transition window until 2 December 2026. The 7 November date falls inside that window, so xAI is moving ahead of the deadline rather than waiting until the last day.

That timing also places xAI in a wider industry shift. The reporting notes that Anthropic began marking Claude text in August, and that OpenAI took a narrower route with its own system, limited to EU text in the reporting cited. For API-generated text, the line is shifting from “some yes, some no” to “almost all yes, with a legal exit”. One outlet also notes, citing City AM, that xAI had not signed the code of practice on transparency, and that the new default-on mark puts it in a different position. Whether that characterisation is fair is a matter of interpretation, but the direction of travel is clear: regulators in Europe want machine-readable marks on synthetic text, and the largest labs are responding, each in a slightly different way.

It is important to be precise about what the EU AI Act does and does not do here. It requires marking in a machine-readable format that can be detected as artificial. It does not require that every human reader can see the mark, nor does it make a watermark a guarantee of authorship in a courtroom. A watermark is a tool for detection, not a certificate of origin that settles every dispute. Treating it as more than that would overstate its power and create false confidence.

How Grok compares with OpenAI on watermarking

One contrast in the brief for this story deserves emphasis, because it is easy to get wrong. OpenAI’s API watermarking stays opt-in, while Grok’s API watermarking becomes opt-out from 7 November. That is a real difference in default, and it matters for builders who use both systems. With OpenAI’s API, you choose to turn watermarking on. With Grok’s API, watermarking is on unless you actively turn it off, model by model, with a legal confirmation.

That contrast should not be stretched into a claim that one approach is lawful and the other is not, or that one company cares about transparency and the other does not. Both companies are navigating the same regulation, and they have chosen different defaults and different scopes. The practical point for builders is narrower: if you switch between providers, or if you use both in the same product, do not assume the watermark settings carry over. Check each provider’s console, each model’s setting, and each response header, and record what you find. A product that assumes a uniform watermark policy across providers will be wrong for at least one of them.

For readers who want to compare watermarking across assistants, our existing explainer, Claude AI Watermark: How It Works & How to Detect It, covers Anthropic’s approach in detail. It is a useful companion piece, because it shows how a different lab implemented a similar idea, and where the limits of detection are similar. A second useful companion is AI Agent Security Checklist: Before You Connect Any Tool, which covers the broader discipline of checking what a tool does with your data before you connect it, a discipline that applies just as much to watermark settings as to permissions. A third is 1Password AI Agent Login: How Agents Sign In Without Ever Seeing Your Password, which explains why credentials and approval codes should be kept out of agent-accessible channels, a theme that returns in our coverage of agent spending controls.

What builders should do before 7 November

First, open the SpaceXSI Console and read the “Model output watermarking” row for your team. Note which models are on, off, or customised, and whether any are locked on. Second, decide, model by model, whether to keep the mark. The default answer, for most teams, will be to keep it, because turning it off requires a legal exception and shifts responsibility to you. Third, if you do turn any model off, get that decision reviewed, record the legal basis, and keep the audit log entry. Fourth, start logging the x-watermark header for responses where compliance matters, so you have a contemporaneous record of what was marked. Fifth, tell your users in plain language when AI-generated text reaches them, because the watermark alone does not do that job.

There are also three things not to do. Do not assume the watermark proves authorship on its own, especially for short or edited text, where the detector is likely to return uncertain. Do not assume that paraphrasing removes the watermark, because the documentation, as reported, does not say how well the mark survives a rewrite, and nobody has published measurements on Grok. And do not assume that the app, website, or X experience carries the same mark, because no date has been announced for those channels. Each of those assumptions would turn a useful tool into a false assurance.

Limitations to keep in mind

The promise that the watermark changes neither quality nor speed comes from xAI and has no independent testing reported so far. Anyone running Grok in production would do well to compare their own benchmarks before and after 7 November, rather than taking that promise on trust. Quality in this context means more than whether the text reads well. It means whether the model’s choices on structured outputs, tool call arguments, and edge cases remain the same when the watermarking nudge is applied. A small statistical shift could, in principle, affect a narrow set of outputs, and only production testing will reveal whether it does in your use case.

A second limitation is the detector’s availability. Until access is broader, the watermark is a promise of future checkability rather than a tool that any reader can use today. That may change, and xAI may open detection more widely, but as of the reporting for this story, access is by application only. Builders should plan on that basis, and should not promise customers or readers that they can verify a Grok text themselves.

A third limitation is scope. The documentation covers API text. It does not, as reported, cover images, audio, or video from Grok, and it does not cover consumer channels. If your product uses Grok for more than API text, you need a separate transparency plan for those outputs, and you should not assume the text watermark covers them.

The bottom line

The Grok API watermark is a small technical change with a large administrative consequence. From 7 November 2026, seven Grok models will mark their API text by default, invisibly, on every endpoint, with a header to prove it and a detector that only some people can use. Builders can opt out per model, but only by confirming a legal exception and taking responsibility themselves. The reason is EU AI Act compliance, ahead of the 2 December 2026 deadline for pre-existing systems. For ordinary Grok users on the app, website, or X, nothing is announced to change. For builders, the task is clear: check the console, decide model by model, record the reason, log the header, and tell your users in plain words. A watermark that nobody can see is only useful if the people who build with it take it seriously, and 7 November is the date when that seriousness becomes the default.

Sources: Pasquale Pillitteri, Grok watermark arrives on xAI API text on November 7; TeslaNorth, Grok API watermark November; FourWeekMBA, AI SpaceX AI will watermark Grok text by default for EU AI Act.