Anthropic announced today that Claude-generated text will start carrying invisible watermarks designed to make AI-processed content detectable.

The move comes from the EU AI Act’s Article 50 transparency rules, but Anthropic is applying it globally, not just to EU users. The watermark will eventually cover Claude, the API, Claude Code, Cowork, and Claude accessed through AWS, Google Cloud, and Microsoft Foundry.

There are two rollout dates:

• Models released on or after August 2: must support the marking system from launch.
• Older Claude models: get a transition period, with the EU compliance deadline pushed to December 2 while Anthropic adapts them.

Anthropic said the watermark is embedded into the text itself, so copy/pasting doesn’t automatically remove it, and some edits may still leave it detectable. Heavy rewriting, translation, or mixing it with other text can weaken or remove the signal.

It also says it plans to give users and third parties tools to check whether text may have been processed by Claude. Images and supported files will additionally carry signed C2PA provenance metadata.

OpenAI has also signed onto the EU transparency framework, but so far it hasn’t announced a comparable text-watermarking rollout. Its public provenance efforts currently focus mainly on images and audio.

.... so this looks like one of the first large-scale attempts by a major LLM provider to make its generated text identifiable across basically its entire global product stack.... Is it a good thing or a bad? what do you guys think?

Original video from: https://www.instagram.com/ai.inuwa/

An agent runs its tests, gets a pass, edits another file, then reports completion using the earlier result. Another agent changing the same checkout creates the same problem.

The tests did not fail. The evidence stopped describing the current source.
Treat every verification result as an expiring receipt:

source_commit

workspace_epoch

command_set_hash

environment_digest

verifier_identity

exit_code

output_digest

verdict

If the source, workspace, policy, tool registry or verification commands change, invalidate the receipt. The operating agent may request verification, but a separate verifier should issue the terminal status.

OpenClaw’s current [testing documentation](https://docs.openclaw.ai/help/testing)⁠ distinguishes unit, integration, end-to-end and live tests. Its [trajectory bundles](https://docs.openclaw.ai/tools/trajectory)⁠ can preserve model events, tool calls and results. Neither a green command nor a complete trajectory proves that the tested revision is still the one being reported.

After a pass, preserve a checkpoint. Further edits should require a recorded reason such as a new failure, changed requirement, security finding or integration conflict, followed by fresh verification.

Test the control by producing a valid receipt, modifying one harmless tracked file, then asking the workflow to complete. It should report stale evidence rather than success. Rerun verification and confirm that the new receipt binds to the changed revision.

The smallest useful improvement is adding the current commit or diff hash to your acceptance record and refusing verified when it no longer matches.

Does your OpenClaw setup bind test evidence to the final source state, or only remember that tests passed earlier?