Generative Watermark Removal Tooling (SynthID / StableSignature / TreeRing / StegaStamp)
This rule flags an AI agent that installs or runs software specifically made to remove imperceptible watermarks embedded in AI-generated images, such as Google's SynthID or Meta's Stable Signature. These watermarks are baked into the pixel data itself, so removing them requires dedicated attack tools rather than a simple metadata edit.
How the attack works
An agent obtains and runs a purpose-built removal tool, a published research attack implementation, or a command that names a specific watermarking scheme (like SynthID or TreeRing) as its target. Because these watermarks live in the pixel values rather than file metadata, removing them needs regeneration, adversarial perturbation, or a dedicated attack algorithm — not a simple strip command. The rule watches for the installation or invocation of this class of tooling, treating it as a signal worth reviewing rather than blocking outright.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 11380ca9-e2a9-49a9-a15b-78297a8cb6ba
- Severity
- Medium
Why it matters
If successful, this lets someone pass off AI-generated content as unwatermarked or unattributed, undermining provenance and detection systems that rely on invisible watermarks to flag synthetic media.
What you can do
- →Review any agent activity that installs or calls watermark-removal libraries or CLIs, and ask why the workflow needs that capability.
- →Check whether the same code path could be legitimate research or robustness testing before treating it as malicious — the tooling is identical either way.
- →Keep this detection in a monitoring/hunt workflow rather than an auto-block, since it cannot distinguish attacker intent from legitimate research use.
- →Don't rely on watermark presence alone as proof of AI origin; combine it with other provenance signals since pixel watermarks can be defeated by dedicated tools.
Known benign look-alikes
- Watermark robustness researchers, standards evaluators and this project's own red team run the published attack implementations by design. Layer 2 cannot separate them from an attacker — the code is the same. This is the primary reason the rule alerts rather than blocks.
- Adobe TrustMark's `remove_watermark()` is a legitimate API for a content owner clearing an old payload before re-marking their own asset. No layer matches that function call; layer 4 matches natural-language intent only.
- Image restoration and super-resolution (Real-ESRGAN, GFPGAN, img2img denoising) destroy pixel watermarks as a physical side effect with no evasive intent. Not covered.
- Generic ComfyUI nodes (KSampler, LoadImage, SaveImage, denoise) are everyday workflow components. Only removal-specific custom node names match.
- Standard audio pipelines (`ffmpeg -ar 16000`, lowpass filtering, MP3 transcode) are known to weaken AudioSeal, but none of those flags are matched.
- `add_watermarker=False` in diffusers and `"addWatermark": false` in Vertex AI are deliberately NOT matched: the first is required when the watermark package is absent, and Google's own documentation states the second is required for deterministic seeded output.
- Educational, defensive and academic text that enumerates attack names will match layer 2. Layer 4 was narrowed specifically to reduce this: research verbs (break, defeat, evade) were removed after they matched defensive sentences, leaving only operational verbs (remove, strip, erase, scrub).