# Generative Watermark Removal Tooling (SynthID / StableSignature / TreeRing / StegaStamp)

- **Severity:** Medium
- **Signature ID:** `11380ca9-e2a9-49a9-a15b-78297a8cb6ba`
- **MITRE ATLAS:** AML.T0054 (LLM Jailbreak)
- **OWASP:** ASI08 (Supply Chain Attacks on Agent Ecosystems), LLM09 (Misinformation)

## Summary

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.

## 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).

## References

- https://agentthreatrule.org/en/rules/ATR-2026-02412
- https://deepmind.google/technologies/synthid/
- https://github.com/adobe/trustmark
- https://arxiv.org/abs/2503.18156

---
Source: https://www.netzilo.com/threats/atr-generative-watermark-removal-tooling-synthid-stablesignature