OpenAI Is Watermarking AI Text: On by Default in the EU, 80% Detection at 200 Tokens — But No Public Detector
On October 5, OpenAI announced textGrain watermarking: EU ChatGPT and Codex get it by default within weeks, API developers worldwide can opt in (off by default), and the detector stays with approved researchers only. Detection hits 80% at 200 tokens and 95% at 400, but falls to 17% after 25% synonym swaps. It catches copy-pasters, not rewriters.

One boundary to draw up front: this site already published two EU AI Act pieces in cycle59 (mid-October), and both are different events from this one — the first enforcement action under the AI Act, with OpenAI and Anthropic under investigation covered the law's first enforcement; Anthropic's first major usage-policy overhaul in a year covered a policy document. This article is a third, distinct event: a concrete product move by OpenAI in response to the AI Act's text-provenance rules — an invisible watermark on AI-generated text, under the technology name textGrain. Not an enforcement story, not a policy text, but something already (or about to be) living inside products you use every day.
The short version: on October 5, 2026 (the blog page itself carries no date stamp; that date is cross-confirmed from three independent sources — see the evidence chain at the end), OpenAI published Our approach to EU text provenance rules on its official blog, announcing three things: ChatGPT and Codex users in the EU will get text watermarking by default over the coming weeks; API developers worldwide can opt in (off by default); and the watermark detector will not be public — only approved researchers and expert organizations get access. Alongside came an unusually candid set of numbers: about 80% detection on 200-token passages, about 95% on 400-token passages, collapsing to 17% once a quarter of the words are swapped for synonyms.
What OpenAI announced: three policies, one technology name
The policies cover three audiences:
- ChatGPT / Codex users in the EU: watermarking on by default, over the coming weeks. Eligible text output will carry an invisible watermark, across all plans, EU only. OpenAI is explicit that this is not a global default at launch — the regional approach, it says, leaves room to learn from real-world use and feedback.
- API developers worldwide: opt-in starting now, off by default. API customers can switch on text watermarking for select models, deciding for themselves how it fits their transparency obligations and the experience they offer users. The post also notes OpenAI is working with cloud partners so watermarking can cover model outputs served through their platforms.
- The detector: applications open, but only for insiders. Approved researchers and expert organizations can apply for access, granted case by case. The detector reports only whether it finds an OpenAI watermark — it does not identify the user or reveal prompts and conversations. No public release at launch, citing the risk of missed watermarks and false positives.
Who gets watermarked by default, and who gets the detector (compiled from OpenAI's official blog)
The technology is called textGrain. In one sentence: it adds an invisible statistical signal to the model's word choices, and a detector holding the key looks for that signal. The key property is that the signal lives in the wording, not the formatting — copy and paste won't wash it out, but rewriting will. OpenAI published a 20-page technical report alongside the post (reportedly co-written with researchers from the University of Pennsylvania and Yale), to be updated in the coming weeks, and says it plans to release the technology as open source.
The trigger is the EU AI Act, which requires generative AI providers to make generated text identifiable in a machine-readable way. OpenAI opens the post by conceding that text watermarking and detection "remain early technologies with significant limitations," and that views on their benefits and responsible uses "are still developing" — hence a phased approach that reflects both the regulatory requirements and the technology's limits.
How textGrain works — and what OpenAI isn't saying yet
The blog is light on mechanism and points to the technical report for details, with a fuller update promised in the coming weeks. What the post does say: textGrain adds an invisible statistical signal to the model's word choices. In practice, this family of techniques works by using a secret key to pseudo-randomly divide the vocabulary into "preferred" and "avoided" tokens at each generation step, then gently biasing sampling toward the preferred set. A detector holding the same key tests whether a passage follows that pattern more often than chance would allow. Because the signal lives in which words were chosen rather than in hidden characters or metadata, it survives copy-paste, format conversion, and text extracted from screenshots — precisely the operations that kill metadata-based provenance the moment someone copies text out of a file.
What it does not survive is exactly what OpenAI's own charts show: editing, translation, and constrained genres. That asymmetry defines the technology's honest use cases. It is a tripwire for verbatim reuse at scale — mass-generated fake reviews, spam networks, synthetic news flooding — not a forensic instrument for attributing any single passage. OpenAI's June discussion of the technology, referenced in the post, reportedly wrestled with exactly this gap: between "detectable in principle" and "reliable enough to act on."
Two open technical questions the post defers. First, eligibility: the API opt-in covers "select models" without naming them, and the EU rollout covers "eligible" text without defining the term. Second, the open-source plan has no date. Once textGrain's code and key-management design are public, independent researchers can finally probe the 80/95/17 figures, test non-English languages (the published evaluations are English-only, on psychology passages and ELI5 Q&A), and find failure modes OpenAI hasn't disclosed. Until then, every number in this article is single-source — impressive, but unverifiable.
The official numbers: 80%, 95%, 17%
The numbers section is the part of the post most worth reading closely, and OpenAI is strikingly frank about them:
- Detection rates (at a 1% target false-positive rate): on psychology-style content, about 80% of 200-token passages and about 95% of 400-token passages. For mathematics, detection was "substantially lower" — the less flexibility in word choice, the weaker the signal.
- Robustness (400-token English Q&A passages): replacing 10% of words with synonyms cut detection from about 92% to 66%; replacing 25% took it down to 17%.
- Quality impact: the official line is that across the benchmarks used to assess Astra, its latest frontier model, there are "no meaningful performance differences" with and without watermarking. Note this is a vendor claim, not independent reproduction. Examples given: Artificial Analysis Intelligence Index 49.57 vs. 49.76; GPQA Diamond 94.44% vs. 93.94%.
- Two kinds of errors: false positives (reporting a watermark where none exists) and false negatives (missing one that is there). Tuning a detector is fundamentally a tightrope walk between the two; the 1% false-positive target is the balance OpenAI chose this time.
The post also lists five things a text watermark doesn't tell you — worth memorizing one by one:
- It doesn't measure human contribution. It can indicate that an OpenAI system generated or processed part of a passage, but not how much human judgment, editing, or creativity went into it.
- It doesn't establish ownership or responsibility. It determines nothing about who owns the text, whether its use was lawful, whether disclosure was required, or who is responsible for it.
- It doesn't identify the user. It associates no person, organization, account, prompt, or conversation with the text.
- It doesn't verify accuracy. It says nothing about whether a passage is true, misleading, harmful, or presented in the right context.
- Absence of a detected watermark doesn't prove human authorship. The text may be too short, edited, translated, from an unsupported model, generated before watermarking launched, or written by another company's tools entirely.
One more note: verification tools for images and audio (openai.com/verify and the Content Provenance API) are unaffected and remain publicly accessible. Only the text detector is being kept under wraps — text is trivially rewritable, and OpenAI's confidence in it is visibly lower than for images and audio.
How textGrain detection varies with passage length and editing (data: OpenAI's official blog; dashed lines are illustrative connectors, not official data)
Reading the numbers: what 80%, 95%, and 17% each mean
80% (200 tokens): 200 tokens is roughly 150 English words — about the length of an ordinary ChatGPT answer. 80% means roughly one passage in five slips through undetected — and that is under lab conditions, on a cooperative genre like psychology, with the detector tuned to a 1% false-positive target. Real-world text distributions will only be messier. Treat this number as a ceiling, not a floor.
95% (400 tokens): 400 tokens is about 300 words, the length of a short essay. The number looks reassuring until you notice the denominator game: 95% is detection given a 1% false-positive target. A 1% false-positive rate means roughly one in every hundred purely human-written texts gets flagged as AI-generated. Deploy this as an "AI cheating detector" in exams, homework, hiring, or academic review, and that 1% is catastrophic: screening a class of 300 assignments would be expected to wrongly accuse three students. That is part of why OpenAI won't release the detector publicly — the numbers hold up in a lab, but they do not hold up in a courtroom, literal or otherwise.
17% (25% synonym replacement): this is the most honest number in the entire post. Swap a quarter of the words for synonyms — the level of effort of one serious editing pass — and detection falls from 92% to 17%, effectively dead. In plain terms: this watermark catches copy-pasters, not rewriters. Any workflow that relies on watermarking to catch "AI ghostwriting" only works if the other side can't be bothered to edit.
"Substantially lower" for mathematics: the less room there is in how something can be worded, the weaker the watermark signal. Codex users should be frowning by now — code has even less wording flexibility than a math proof; what you can write next is locked down by syntax. EU Codex users will be watermarked by default, but how detectable a code snippet actually is? OpenAI gives no number. That is an open question, and the one developers should be pressing hardest.
One third-party data point belongs next to these: per TechRepublic, citing EU guidance, code snippets and responses under 200 tokens were never in scope for text-watermarking expectations. In other words, what the EU actually wants to track is "long text that looks human-written" — a convincingly fake press release, a supposedly original paper — not the 20-line function Codex completed for you. The watermark was never aimed at code.
Our take: facts and judgments labeled separately
Analysis zone below — facts and judgments are labeled separately.
Judgment 1: "verifiability" is becoming a new infrastructure layer for AI text. (Opinion) Both ends are tightening at once. The input side answers "who can see my prompt" — privacy, end-to-end encryption; another draft in this same cycle covers Brave's Leo moving exactly in that direction. The output side answers "who wrote this text" — provenance, watermarking, which is this article. Squeezed from both ends, AI text is going from "no identity" to "having provenance." This is not a feature update; it is an infrastructure-layer shift: before long, "does this text have verifiable provenance" will be a default trust assumption the way "does this site have HTTPS" is today. People who see that layer early will design provenance into their products earlier.
Judgment 2: for vibe developers, the API opt-in switch is a real product decision, not compliance boilerplate. (Opinion) If your product serves EU users, this switch deserves genuine thought. Turn watermarking on, and your AI output becomes detectable by third parties — a plus for contexts that need to prove their innocence (education, publishing, government, news): a trust asset you can point to. But for products that sell AI output as "feeling human," it may be a liability. OpenAI handed developers both the switch and the burden of justification, without making the value judgment for you. One caution: the official "no meaningful performance differences" is a vendor claim — run your own evals on your own workloads before deciding.
A practical checklist if you're deciding this week: (1) Do you serve EU users, or plan to? If yes, the opt-in is the cheapest way to get ahead of the transparency obligation before the December compliance window closes. (2) Is your output long-form prose, where detection actually works, or short snippets and code, where it barely does? Watermarking the latter buys you compliance theater, not detection. (3) Who is your reader? If it's a regulator, an educator, or an enterprise buyer doing diligence, a watermarked pipeline is evidence of good faith. If it's a consumer who just wants a good answer, the watermark is invisible to them either way — the decision is about your paper trail, not their experience. (4) Log which setting you used, per project. If provenance ever becomes auditable, "we turned it on everywhere on this date" is a much better answer than a shrug.
Judgment 3: two compliance philosophies are diverging, and it's worth watching. (Opinion, includes third-party reporting) Per press reports, Anthropic has applied text watermarking globally to its models since August (Dealroom, citing Ars Technica); OpenAI chose "EU default + global opt-in." One treats compliance as a unified product, the other as regional configuration. How far does the Brussels effect actually reach — will everyone converge on the EU standard globally, or does the "EU-only edition" become the industry norm? The next few labs' choices will answer it. This post is a key data point: if a year from now the major models only watermark in the EU, the industry has decided compliance can be regionalized; if they go global, the Brussels effect won.
Judgment 4: who the watermark stops can be summed up in one line — it stops the casual, not the determined. (Opinion) Copy-pasters get caught; serious rewriters, translators, and shorteners mostly don't; constrained genres like math and code are weak by construction. Stack the five "doesn't tell you" items on top: a watermark answers only "does this passage contain OpenAI's statistical signal" — not "who wrote it, whether it's true, or whose it is." Using it as an "AI lie detector" is misuse; using it as a large-scale, low-cost preliminary screening signal is the only honest job it has. Any workflow design that treats a watermark hit as proof of cheating is gambling someone's future on a 1% false-positive rate.
What remains unsaid
First, the date evidence chain — honest labeling requires it. The OpenAI blog page carries no date stamp. The "October 5" you see in the headline and body is our cross-confirmed dating: the chatgpt-timeline repository on GitHub files "EU text provenance" under "October 5, 2026"; Medium author @andy.a.g opens his analysis with "On Monday, October 5, OpenAI published…"; techstartups.com's report URL carries the path /2026/10/05/ (verified by our scout); and more than a dozen outlets — dig.watch, Digital Trends, Dealroom, Medianama among them — reported it on October 5 (or followed up on the 6th). Three-plus independent sources agree, so we date it October 5 — but the fact that the page itself is undated, and the date is inferred, is something you deserve to know.
The blog never explains why the API default is off. One reasonable reading (opinion): a watermark makes output identifiable — a compliance asset for some products, a trust liability for others. OpenAI declines to make that value judgment for developers and pushes both the choice and the compliance burden downstream. Also note the cloud-partner angle: large volumes of enterprise traffic flow through cloud vendors rather than OpenAI's own interfaces, so covering that traffic depends on the partners catching up — a calendar item for anyone on Azure and similar channels to watch.
"Eligible" is undefined. What counts as eligible output? Are short texts, code snippets, or structured outputs in scope? The post doesn't say — a deliberate loose end. Read alongside the EU guidance cited above, short text and code are probably outside the bullseye, but OpenAI's own wording commits to nothing. EU users will only see the real boundary once the rollout lands.
The non-public detector is the most contested point of the whole announcement. OpenAI's case: false-positive and false-negative risks mean it should only go to people who can interpret results responsibly. The counter-case (opinion): the regulation demands machine-readable identifiability, yet the identification tool sits in a drawer — which substantially discounts the watermark's compliance value. Without a public detector, the watermark is currently more promise than verifiable fact. Open-sourcing is a future variable, but no date is attached; until then, third parties have no way to independently reproduce the 80/95/17 figures at all.
The Code of Practice layer (fact, with context). Detector access isn't arbitrary gatekeeping alone: OpenAI says access will be granted case by case "in accordance with the Code of Practice" — the EU's Code of Practice on transparency of AI-generated content, which OpenAI and other major providers signed. That framing matters because it turns the detector from a purely corporate decision into a regulated-regime instrument: the same document that obliges providers to make outputs identifiable also shapes who gets to do the identifying, at least in the first phase. Whether that satisfies the regulation's spirit — machine-readable identifiability whose readers are hand-picked — is precisely the dispute worth having, and it will likely be relitigated when the open-source release lands.
The compliance window (third-party interpretation, for reference). Medium's @andy.a.g, citing the AI Omnibus transition rules, notes that systems already on the market before August 2 had until December 2 to comply — "over the coming weeks" lands neatly inside that window. That's interpretation, not OpenAI's official line, but it explains why the timeline is "coming weeks" rather than "today": compliance has a deadline, and the product ships against it.
Related reading: our cycle59 piece on the AI Act's first enforcement action — the other face of the same law, enforcement already underway; our cycle59 piece on Anthropic's usage-policy overhaul. For third-party depth, Medium's @andy.a.g wrote the most thorough teardown of the statute, the grace period, and the technical details we've seen.
In one sentence: OpenAI has given AI text an invisible fingerprint — on by default in the EU, opt-in worldwide via the API; the official numbers are admirably honest (long text detects well, light editing kills it); and with the detector closed to the public, this "verifiability" is still more promise than reality. For vibe developers, the real exam isn't the technology — it's the product judgment behind that opt-in switch.
Comments (0)
Sources
Related articles

An OpenAI customer story (dated Oct 14 via third-party cross-check; the official page carries no timestamp) profiles Third Moment Research: 10,000 agents running at once, single autonomous research sessions of 36–48 hours, held on track by a three-layer harness around Codex and the GPT-6 family. One case study: caching plus memory packing cut a one-year US equities order-level backtest from about 3 hours to 3–5 minutes. Jeffrey Yan: GPT-6.1 Sol is the team's most-used model.

On October 15, Brave's official blog announced end-to-end encryption plus verifiable confidential computing for Leo: select the open-weight GLM 5.3 Flash and your prompt is encrypted on-device with Oblivious HTTP, relayed through Brave's open-source AI Gateway (hiding your IP from NEAR AI), and decrypted only inside a hardware-attested Nvidia enclave. Brave, NEAR AI, and the cloud hoster all cannot see the plaintext.

PostgreSQL 19's GA is delayed to around November 19 and 8–10 major features are cut to PG20 — because LLM-assisted code review surfaced more defects than humans could fix. Core committer Peter Eisentraut: the cut features had architectural defects unfixable in the beta window, plus ~40 edge-case reports landed at once. The lesson for vibe coders: bug-finding capacity now exceeds bug-fixing capacity — wire AI review into your process.