💻 computer science

PromptMark: A Prompt-Guided Iterative-Feedback Framework for Source Code Watermarking

PromptMark ist ein Black-Box-, Prompt-gesteuertes Framework, das durch strukturierte Eingabeanweisungen und iteratives Feedback detektierbare Wasserzeichen in KI-generierten Quellcode einbettet und dabei eine starke Attribuierung erreicht, ohne die Funktionalität des Codes zu beeinträchtigen oder Zugriff auf die Modellinterna zu benötigen.

Ursprüngliche Autoren: Istiaq Ahmed Fahad, Mridha Md. Nafis Fuad, Kazi Sakib

Veröffentlicht 2026-06-23

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Istiaq Ahmed Fahad, Mridha Md. Nafis Fuad, Kazi Sakib

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Bäcker, der einen sehr talentierten, aber unsichtbaren Roboter-Koch anstellt, um jeden Tag tausende Laibe Brot zu backen. Sie möchten wissen, welches Brot von Ihrem Roboter und welches von einem menschlichen Konkurrenten gebacken wurde, aber der Roboter hinterlässt kein Markenzeichen und das Brot sieht von außen exakt gleich aus.

Dies ist das Problem, das PromptMark löst, aber anstelle von Brot geht es hier um Computercode, der von Künstlicher Intelligenz (KI) geschrieben wurde.

Hier ist die Erklärung der Lösung, aufgeschlüsselt in einfache Konzepte:

1. Das Problem: Der „Black Box“-Koch

In der realen Welt besitzen die meisten Entwickler nicht die KI-Modelle, die sie verwenden; sie mieten diese über einen „Black Box“-Dienst (wie ein Restaurant, in dem man die Küche nicht sehen kann).

Die Herausforderung: Sie können nicht in das Gehirn des Roboters hineinspähen, um die Art und Weise zu ändern, wie er denkt (das wird als „White-Box“-Zugriff bezeichnet). Sie können ihm lediglich ein Rezept (einen Prompt) geben und dann auf das Gericht (den Code) warten.
Das Risiko: Wenn die KI Code schreibt, der Fehler enthält oder die Urheberschaft stiehlt, ist es schwer zu beweisen, dass es die KI war. Außerdem: Wenn Sie versuchen, die KI dazu zu zwingen, den Code auf eine seltsame Weise zu schreiben, um ihn zu markieren, könnte der Code aufhören zu funktionieren (wie ein Roboter, der versucht, Brot mit einem Hammer zu backen).

2. Die Lösung: Das „Green List“-Rezept

Die Forscher haben eine Methode namens PromptMark entwickelt. Anstatt zu versuchen, das Gehirn des Roboters zu hacken, ändern sie einfach die Anweisungen, die sie ihm geben.

Stellen Sie sich das wie eine spezielle Regel für den Roboter-Koch vor: „Für jeden neuen Namen, den du für eine Zutat erfindest, musst du den Namen mit einem Buchstaben aus dieser speziellen ‚Green List‘ beginnen (wie A, B oder C).“

Die Green List: Dies ist eine geheime Liste von Buchstaben (z. B. A, B, C), die basierend auf einem geheimen Schlüssel ausgewählt wurde.
Die Red List: Dies sind Buchstaben, denen der Roboter gesagt wird, dass er beim Starten von Namen vermeiden soll.
Der Trick: Der Roboter folgt diesen Regeln so gut, dass er beginnt, seine Variablen (wie apple_count oder banana_loop) viel häufiger mit „Green Letters“ zu benennen, als ein Mensch es natürlich tun würde.

3. Die „Iterative Feedback“-Schleife: Der Geschmackstest

Manchmal vergisst der Roboter die Regel oder schreibt Code, der nicht funktioniert, weil er zu sehr versucht, die Regel zu befolgen. Um dies zu beheben, nutzt PromptMark eine Feedback-Schleife:

Runde 1: Der Roboter schreibt den Code.
Die Prüfung: Ein Mensch (oder ein anderer Computer) prüft zwei Dinge:
- Funktioniert der Code tatsächlich? (Ist das Brot aufgegangen?)
- Hat der Roboter die „Green List“-Regel genug befolgt? (Gibt es genug A-, B-, C-Namen?)
Das Feedback: Wenn der Code fehlerhaft ist, wird dem Roboter gesagt: „Korrigiere die Logik.“ Wenn der Code funktioniert, aber die „Green List“-Regel schwach ist, wird ihm gesagt: „Gute Arbeit, aber verwende beim nächsten Mal mehr ‚A‘-Namen.“
Runde 2: Der Roboter versucht es erneut mit den neuen Anweisungen.

Dies wird so lange fortgesetzt, bis der Code perfekt und das Wasserzeichen stark ist.

4. Die Detektion: Der „Statistische Detektiv“

Woher wissen Sie, ob ein Stück Code von der KI erstellt wurde? Sie müssen nicht den geheimen Schlüssel kennen. Sie schauen einfach auf die Namen.

Natürlicher Code: Menschen benennen Dinge zufällig. Wenn man 100 Variablen betrachtet, beginnen vielleicht 10 mit „A“, 10 mit „B“ usw. Es ist eine ausgewogene Mischung.
Wassermark-Code: Da die KI gezwungen wurde, die „Green List“ zu verwenden, werden Sie ein seltsames Muster sehen. Vielleicht beginnen 60 % der Namen mit „A“, „B“ oder „C“.
Der Test: Ein statistischer Test (wie ein mathematischer Detektor) zählt diese Buchstaben. Wenn das Muster zu stark ist, um ein Zufall zu sein, ruft er: „Das wurde von der KI geschrieben!“

5. Warum es besonders ist

Die Forscher behaupten, dass diese Methode aus drei Gründen besonders ist:

Es ist unsichtbar: Der Code sieht immer noch normal aus und funktioniert perfekt. Das „Wasserzeichen“ ist nur ein subtiles Muster in den Namen, wie eine versteckte Botschaft in den Songtexten eines Liedes, die man nur bemerkt, wenn man das Muster kennt.
Es funktioniert bei Black Boxes: Sie müssen nicht die KI besitzen oder deren internen Code sehen. Sie kommunizieren einfach wie ein normaler Nutzer mit ihr.
Es ist sicher: Die „Green List“ wird mithilfe eines geheimen Schlüssels (wie einem Passwort) generiert. Nur jemand mit diesem Schlüssel weiß, nach welchen Buchstaben man suchen muss, was es schwierig macht, das Wasserzeichen zu fälschen.

Die Ergebnisse

Die Forscher haben dies an zwei berühmten Sätzen von Programmieraufgaben (MBPP und HumanEval) unter Verwendung von zwei verschiedenen KI-Modellen (Gemini und Claude) getestet.

Erfolgsrate: Die Methode hat den Code etwa 90 % bis 98 % der Zeit erfolgreich markiert, ohne den Code zu beschädigen.
Qualität: Der Code blieb genauso gut wie Code, der ohne das Wasserzeichen geschrieben wurde.

Die Einschränkungen (Was das Paper zugibt)

Umbenennungs-Angriffe (Renaming Attacks): Wenn jemand den wassermarkierten Code nimmt und manuell alle Variablennamen in etwas anderes ändert, verschwindet das Wasserzeichen. Das Paper stellt fest, dass die Methode zwar gut, aber nicht magisch ist; ein entschlossener Mensch könnte das Signal durch das Umschreiben des Codes löschen.
Sprachspezifisch: Die Studie wurde für Python-Code durchgeführt. Das Paper warnt, dass Sprachen mit anderen Benennungsregeln anders reagieren könnten.

Kurz gesagt, PromptMark ist eine Art, dem KI-Koch eine geheime Anweisung zuzuflüstern: „Benenne deine Zutaten mit diesen spezifischen Buchstaben“, was es Ihnen ermöglicht, später mit Mathematik zu beweisen, dass die KI das Gericht zubereitet hat, ohne dabei den Geschmack des Essens zu ruinieren.

Technisches Resümee: PromptMark

Problemdefinition

Die Proliferation von Large Language Models (LLMs) in der Softwareentwicklung hat einen kritischen Bedarf an Code-Provenienz geschaffen – der Fähigkeit, den Ursprung und die Urheberschaft von KI-generiertem Quellcode zu verifizieren. Während Wasserzeichen eine Standardtechnik für digitale Inhalte sind, stellt die Anwendung auf Quellcode besondere Herausforderungen dar:

Strukturelle Rigidität: Im Gegensatz zu natürlicher Sprache ist Quellcode syntaktisch streng; geringfügige Modifikationen können die Kompilierung unterbrechen oder die Programmlogik verändern.
Black-Box-Beschränkungen: Die meisten Entwickler interagieren mit kommerziellen LLMs über APIs, bei denen die Modellinterna (Logits, Dekodierungsstrategien) nicht zugänglich sind. Bestehende Wasserzeichenmethoden erfordern oft „White-Box“-Zugriff, um Token-Wahrscheinlichkeiten zu manipulieren, was sie für den realen Einsatz unpraktikabel macht.
Abwägungsprozess: Effektive Wasserzeichen müssen detektierbare Signale einbetten, ohne die funktionale Korrektheit oder Lesbarkeit des Codes zu beeinträchtigen.

Das Kernproblem, das mit diesem Paper adressiert wird, ist das Design eines Black-Box, prompt-gesteuerten Wasserzeichen-Frameworks, das unsichtbare, statistisch detektierbare Signale in Quellcode einbetten kann, ohne Zugriff auf Modellinterna zu benötigen, während gleichzeitig die Funktionalität des Codes erhalten bleibt.

Methodik: PromptMark

Die Autoren schlagen PromptMark vor, ein dreiphasiges Framework, das die Instruktionsfolgebefähigkeiten von LLMs nutzt, um die Generierung in Richtung spezifischer Muster zu steuern.

1. Kryptografische Konstruktion der Green List

Anstatt die Logits des Modells zu manipulieren, beeinflusst PromptMark das Modell über System-Prompts.

Green/Red Lists: Das Framework definiert eine „Green List“ (erlaubte Anfangszeichen für Identifikatoren/Kommentare) und eine „Red List“ (verbotene Zeichen).
Frequenzbasierte Stratifizierung: Um die Natürlichkeit zu gewährleisten, wird die Green List aus der Häufigkeitsverteilung von Identifikator-Anfangszeichen in menschengeschriebenem Code (unter Verwendung der Datensätze MBPP und HumanEval) abgeleitet. Das System wählt die Top- $K$ häufigsten Buchstaben ( $K \in [10, 12]$ ), um einen Kandidatenpool zu bilden.
Kryptografische Ableitung: Um die Vorhersehbarkeit zu verhindern, werden die spezifische Größe und Zusammensetzung der Green List deterministisch aus einem 128-Bit-Geheimschlüssel mittels SHA-256-Hashing und Fisher-Yates-Shuffling abgeleitet. Dies gewährleistet die Reproduzierbarkeit für die Detektion bei gleichzeitiger Aufrechterhaltung der Sicherheit.

2. Iterative Feedback-Schleife

In der Erkenntnis, dass ein einzelner Prompt möglicherweise keinen Code liefert, der sowohl funktional korrekt als auch ausreichend wasserzeichenbehaftet ist, verwendet PromptMark einen iterativen Prozess:

Generierung: Das LLM generiert Code basierend auf einem System-Prompt, der es anweist, Green-List-Zeichen für Identifikatoren und Kommentare zu verwenden.
Evaluierung: Der Output wird anhand zweier Metriken bewertet:
- Funktionale Korrektheit ( $c_i$ ): Bestimmt durch die Ausführung von Unit-Tests (Pass/Fail).
- Wasserzeichen-Fidelität ( $p_i$ ): Ein statistischer p-Wert, der die Abweichung der Green-List-Zeichenfrequenz gegenüber der erwarteten Baseline misst.
Feedback: Wenn der Code die Tests nicht besteht, werden Fehlermeldungen zurückgeführt. Wenn der Code besteht, aber das Wasserzeichen schwach ist, wird der Prompt aktualisiert, um eine striktere Einhaltung der Green List zu erzwingen. Diese Schleife setzt sich fort, bis beide Kriterien erfüllt sind oder ein maximales Iterationslimit erreicht wird.

3. Statistische Detektion

Die Detektion wird als einseitiger Hypothesentest behandelt:

Nullhypothese ( $H_0$ ): Der Code wurde ohne Kenntnis des Schlüssels generiert (Green-List-Frequenz $\le$ Baseline).
Alternativhypothese ( $H_1$ ): Der Code wurde wasserzeichenbehaftet (Green-List-Frequenz $>$ Baseline).
Adaptiver P-Wert: Der Detektor berechnet einen adaptiven p-Wert und wechselt zwischen einem exakten Binomialtest (für kurzen Code, $N < 30$ ) und einer Normalverteilungsapproximation (für längeren Code, $N \ge 30$ ). Ein Code gilt nur dann als wasserzeichenbehaftet, wenn er funktional korrekt ist und der p-Wert unter einen Signifikanzschwellenwert fällt.

Zentrale Beiträge

Black-Box Wassermarking Framework: PromptMark ist das erste Framework, das zuverlässiges Zero-Bit-Wasserzeichen für Quellcode unter Verwendung von reinem Prompt Engineering demonstriert und somit die Notwendigkeit von Modellinterna eliminiert.
Iterativer Feedback-Mechanismus: Das Paper führt eine Selbstverfeinerungsschleife ein, die die Wasserzeichenstärke dynamisch mit der Codekorrektheit ausbalanciert und so den Trade-off adressiert, der oft bei Single-Pass-Prompting auftritt.
Adaptive Green List Strategie (AGL): Durch die Ableitung der Wasserzeichen-Token aus hochfrequenten menschlichen Identifikator-Anfangszeichen bewahrt die Methode die semantische Natürlichkeit des Codes und vermeidet den „erzwungenen“ Look, der oft die Detektion durch Entwickler auslöst oder die Lesbarkeit reduziert.
Kryptografische Sicherheit: Die Verwendung eines Geheimschlüssels zur deterministischen Generierung der Green List stellt sicher, dass das Wasserzeichen für die Verifizierung reproduzierbar, aber ohne den Schlüssel nicht vorhersagbar ist.

Experimentelle Ergebnisse

Das Framework wurde auf den Datensätzen MBPP und HumanEval unter Verwendung von Gemini 2.5 Flash und Claude Sonnet 4 evaluiert.

Effektivität (RQ1):
- PromptMark erreichte eine starke Detektierbarkeit mit AUROC-Scores zwischen 0,90 und 0,99 über verschiedene Konfigurationen hinweg.
- Die Variante Iterative-AGL (Adaptive Green List) performte am besten mit einem AUROC von 0,994 auf Gemini/MBPP und 0,987 auf Claude/MBPP.
- Bei einer niedrigen Falsch-Positiv-Rate (1 %–5 %) lagen die Richtig-Positiv-Raten über 90 % und erreichten in günstigen Settings über 95 %.
- Baseline-Methoden wie SWEET (White-Box) verschlechterten die Codekorrektheit signifikant, während In-Context Watermarking (ICW) ohne Iteration eine schwache Detektierbarkeit zeigte (AUROC ~0,51).
Codequalität (RQ2):
- Funktionale Korrektheit: PromptMark bewahrte hohe Pass%-Raten und erreichte ~97 % auf HumanEval und ~99 % auf MBPP, vergleichbar mit nicht-wasserzeichenbehafteten Baselines.
- Strukturelle Ähnlichkeit: Die CodeBLEU-Scores blieben stabil und konsistent mit nicht-wasserzeichenbehaftetem Code, was darauf hindeutet, dass der Wasserzeichenprozess den Kontrollfluss oder die Datenabhängigkeiten nicht verzerrt.
Robustheit:
- Das Wasserzeichen zeigte Resilienz gegenüber der Entfernung von Kommentaren (AUROC sank nur um ~3,8 %).
- Jedoch verursachte automatisches Paraphrasieren (Umbenennen von Variablen) eine signifikante Degradierung (AUROC sank auf ~0,71), was den Trade-off zwischen Natürlichkeit und Robustheit gegenüber aggressiven semantisch-erhaltenden Angriffen verdeutlicht.

Bedeutung und Ansprüche

Das Paper behauptet, dass PromptMark das Wasserzeichen für Quellcode erfolgreich als eine prompt-gesteuerte Aufgabe neu rahmt, was es für kommerzielle Black-Box-LLMs praktikabel macht.

Praktikabilität: Es bietet eine lebensfähige Lösung für die Attribution in Umgebungen, in denen Modellinterna nicht zugänglich sind, und schließt damit eine Lücke, die durch White-Box-orientierte Forschung entstanden ist.
Balance: Der iterative Feedback-Mechanismus beweist, dass hohe Wasserzeichenstärke und hohe Codequalität keine Gegensätze sind; das Framework kann beides durch dynamische Verfeinerung erreichen.
Attribution: Während die aktuelle Implementierung die Zero-Bit-Detektion (Vorhandensein/Abwesenheit) unterstützt, merken die Autoren an, dass die kryptografische Schlüsselseparation die Möglichkeit für modellspezifische Attribution eröffnet, falls unterschiedliche Schlüssel verschiedenen Modellen zugewiesen werden.

Die Autoren kommen zu dem Schluss, dass dieser Ansatz zwar ein Fundament für Zero-Bit-Wasserzeichen legt, zukünftige Arbeit jedoch notwendig ist, um Multi-Bit-kodierbare Wasserzeichen für Black-Box-Settings zu entwickeln und die Robustheit gegenüber systematischen Umbenennungs-Angriffen durch Multi-Channel-Embedding-Strategien zu erhöhen.