💻 computer science

The Security Budget of Code LLMs: An Information-Theoretic Capacity-Security Bound

Diese Arbeit etabliert und validiert empirisch eine informationstheoretische Schranke, die zeigt, dass Code-LLMs unter einem festen „Sicherheitsbudget“ operieren, bei dem die Summe aus funktionaler Kapazität und Perturbationsretention durch Aufgabenentropie und Prompt-Leakage begrenzt wird, wobei experimentelle Ergebnisse zeigen, dass diese theoretische Obergrenze über verschiedene Modelle, Datensätze und Präzisionsstufen hinweg Bestand hat.

Ursprüngliche Autoren: Jianwei Tai

Veröffentlicht 2026-06-03

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Jianwei Tai

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 stellen einen sehr talentierten, aber etwas nervösen Roboter-Programmierer ein. Sie geben ihm eine Reihe von Anweisungen (einen „Prompt“), um ein Stück Code zu schreiben. Manchmal ändern Sie versehentlich ein Wort in Ihren Anweisungen, oder ein Hacker versucht, diese leicht zu manipulieren, um den Roboter dazu zu bringen, etwas Gefährliches zu schreiben.

Dieses Paper stellt eine grundlegende Frage: Wie viel des „Gehirns“ des Roboters können wir uns leisten, damit er den Job korrekt erledigt, im Vergleich dazu, wie viel übrig bleibt, damit er versehentlich (oder böswillig) einem Trick folgt?

Die Autoren nennen dies das „Security Budget“ (Sicherheitsbudget). Sie behandeln die Fähigkeit des Roboters zu denken wie eine feste Menge an Energie oder Bandbreite, die zwischen zwei konkurrierenden Aufgaben aufgeteilt werden muss.

Die zwei konkurrierenden Bedürfnisse

Betrachten Sie die Aufmerksamkeit des Roboters wie einen Kuchen. Das Paper sagt, dass dieser Kuchen in zwei Stücke unterteilt ist:

Das „Job“-Stück (Kapazität): Dies ist die Frage, wie gut der Roboter Ihre ursprüngliche Absicht versteht. Hat er den Code geschrieben, den Sie tatsächlich verlangt haben?
Das „Echo“-Stück (Sicherheit/Retention): Dies ist, wie sehr das Ergebnis des Roboters noch die spezifischen Wörter „erinnert“, die Sie verwendet haben, selbst wenn Sie diese leicht verändert haben.
- Der Haken: Wenn das Ergebnis des Roboters zu empfindlich auf winzige Änderungen in Ihrem Prompt reagiert (hohes „Echo“), bedeutet das, dass ein Hacker leicht ein Wort wie „prüfen“ durch „ignorieren“ ersetzen könnte und der Roboter der neuen, gefährlichen Anweisung folgen würde.
- Das Ziel: Sie wollen, dass der Roboter gut bei der Arbeit ist, aber Sie wollen nicht, dass er zu empfindlich auf die spezifische Wortwahl des Prompts reagiert.

Die große Regel (Das Theorem)

Die Autoren haben eine mathematische Regel bewiesen, die wie ein Tempolimit für diesen Kuchen fungiert. Sie sagen:

Job-Stück + Echo-Stück ≤ Gesamtes Gehirnvolumen + Prompt-Leakage

Auf einfachem Deutsch: Der Roboter kann nicht gleichzeitig perfekt gut bei der Arbeit sein und perfekt empfindlich auf jede winzige Änderung in Ihrem Prompt reagieren. Es gibt eine harte Grenze.

Gesamtes Gehirnvolumen: Dies ist die Komplexität der Aufgabe. Wenn Sie ein einfaches „Hello World“ verlangen, hat der Roboter viel Platz. Wenn Sie ein komplexes Bankensystem verlangen, ist das „Gehirnvolumen“ riesig, was weniger Raum für Sicherheitsmargen lässt.
Prompt-Leakage: Dies ist die Menge an Information, die zwischen Ihrem ursprünglichen Prompt und dem „getricksten“ Prompt geteilt wird. Wenn der Trick darin besteht, ein Wort wie „Katze“ durch „Hund“ (Synonyme) zu ersetzen, ist das Leakage hoch. Wenn der Trick darin besteht, die Hälfte des Satzes zu löschen, ist das Leakage niedrig.

Das Paper beweist, dass wenn Sie versuchen, den Roboter zu empfindlich für den Prompt zu machen (um ihn sehr robust zu machen), Sie zwangsläufig den Raum verringern, der ihm für die eigentliche Arbeit zur Verfügung steht.

Wie sie es getestet haben

Die Forscher haben nicht nur geraten; sie haben Experimente mit echten KI-Modellen (wie CodeLlama und Qwen) bei echten Programmierproblemen durchgeführt.

Der „Black Box“-Test: Sie haben sich das Endergebnis des Roboters (den Code) angesehen, ohne einen Blick in seine internen Gedanken während des Prozesses zu werfen. Sie haben den Code wie einen Fingerabdruck behandelt.
Die Ergebnisse: In jedem Test hat die Mathematik standgehalten. Die Summe aus der „Job“-Leistung und der „Echo“-Empfindlichkeit hat das Tempolimit nie überschritten.
- Manchmal war der Roboter sehr gut bei der Arbeit, aber nicht sehr empfindlich gegenüber Tricks (was viel „Spielraum“ oder ungenutztes Budget hinterließ).
- Manchmal war er sehr empfindlich gegenüber Tricks, aber das bedeutete, dass er weniger Spielraum hatte, um perfekt bei der Arbeit zu sein.
- Entscheidend: Sie fanden heraus, dass bestimmte Arten von Tricks (wie das Umbenennen von Variablen oder das Austauschen von Synonymen) ein größeres „Echo“ hinterlassen als andere. Dies zeigt uns, welche Arten von Prompt-Änderungen am gefährlichsten sind, wenn man sie ungeschützt lässt.

Der „Stresstest“

Um sicherzustellen, dass ihre Regel robust ist, versuchten sie, sie zu brechen:

Der 23-Attacken-Pool: Sie probierten 23 verschiedene Wege aus, um den Prompt zu manipulieren. Die Regel hielt dennoch stand.
Der „Universelle Suffix“: Sie fügten jedem Prompt denselben gefährlichen Satz hinzu. Die Regel hielt dennoch stand.
Der „Gradienten-Angriff“: Sie verwendeten einen super-intelligenten mathematischen Angriff, um den perfekten Weg zu finden, den Roboter zu täuschen. Selbst dann hielt die Regel stand, obwohl die Code-Qualität des Roboters signifikant sank (er „kollabierte“, anstatt getäuscht zu werden).

Das Fazit für Menschen

Das Paper schließt mit einer praktischen Lektion für den Bau von KI-Assistenten:

Sie können nicht nur messen, ob eine KI einen Test besteht. Sie müssen auch messen, wie viel „Informationskanal“ Sie für einen Angreifer offen lassen.

Wenn Sie Ihre Prompts härten (sie starr und standardisiert machen), reduzieren Sie das „Echo“-Stück, was es für Hacker schwieriger macht, die KI zu täuschen.
Jedoch können Sie die KI nicht einfach nur „dumm“ machen, um sicher zu sein. Sie müssen das Gleichgewicht finden, bei dem die KI noch klug genug ist, um den Job zu erledigen, aber nicht so empfindlich auf Wortspiele reagiert, dass sie zu einem Sicherheitsrisiko wird.

Kurz gesagt: Es gibt eine harte, mathematische Grenze dafür, wie viel eine KI gleichzeitig ein perfekter Arbeiter und ein perfekter Zuhörer für jede winzige Änderung in Ihrer Stimme sein kann. Das Paper liefert uns das Lineal, um dieses Limit zu messen.

Technische Zusammenfassung: Das Sicherheitsbudget von Code-LLMs

Problemstellung
KI-Programmierassistenten verlassen sich zunehmend auf natürliche Sprach-Prompts als primäre Schnittstelle für die Softwareentwicklung. Dieser Wandel führt eine kritische Schwachstelle ein: Kleine Störungen eines Prompts (z. B. Synonymsubstitution, Umbenennung von Identifikatoren oder Kommentarinjektion) können den generierten Code verändern, während die Intention des Nutzers teilweise erkennbar bleibt. Bestehende Evaluierungen stützen sich oft auf die Ausführungs-Erfolgsraten (pass@1) vor und nach einer Störung. Die Autoren argumentieren jedoch, dass dies für interaktive Assistenten unzureichend ist, da es nicht zwischen einem Modell unterscheidet, das jegliche Aufgabeninformation verloren hat (was „Robustheit“ bedeutungslos macht), und einem Modell, das genügend Informationen behält, um erkennbar zu bleiben, aber die Implementierung verschiebt. Es besteht ein Bedarf an einer Sichtweise auf „Budget-Ebene“, die Aufgabeninformation, Prompt-Leakage und Generationsstabilität trennt, um die Trade-offs zwischen funktionaler Kapazität und Sicherheit unter Störung zu verstehen.

Methodik
Das Paper formalisiert diesen Trade-off mittels Informationstheorie und definiert zwei Schlüsselgrößen für ein Code-LLM $\pi$ :

Kapazität ($Cap$): Die gegenseitige Information zwischen der kanonischen Lösung $c^*$ und der Generierung des Modells $c_\pi$ , bezeichnet als $I(c^*; c_\pi)$ . Dies misst, wie viel der Aufgabe das Modell erfasst.
Sicherheit ($Sec$): Die gegenseitige Information zwischen der Generierung unter dem ursprünglichen Prompt $p$ ( $c_\pi$ ) und der Generierung unter einem adversariellen, gestörten Prompt $\tilde{p}$ ( $\tilde{c}_\pi$ ), bezeichnet als $I(c_\pi; \tilde{c}_\pi)$ . Dies fungiert als „Störungs-Retentions-Kanal“, der die gemeinsame Information zwischen sauberer und gestörter Ausgabe misst.

Theoretischer Rahmen
Der zentrale theoretische Beitrag ist Theorem 1, welches eine obere Schranke für die Summe dieser beiden Größen festlegt:
$Cap + Sec \leq H(c^*) + I(p; \tilde{p})$
Hierbei ist $H(c^*)$ die Entropie der kanonischen Lösung (Aufgabenentropie) und $I(p; \tilde{p})$ ist die gegenseitige Information zwischen dem ursprünglichen und dem gestörten Prompt (Prompt-Leakage). Der Beweis stützt sich auf Standard-informationstheoretische Ungleichungen:

$Cap \leq H(c^*)$ folgt aus der Definition der gegenseitigen Information.
$Sec \leq I(p; \tilde{p})$ folgt aus der Data Processing Inequality (DPI), unter der Annahme, dass die Generationen $c_\pi$ und $\tilde{c}_\pi$ bedingt unabhängig gegeben das Prompt-Paar $(p, \tilde{p})$ sind.

Um diese Schranke handhabbar zu machen, ohne Zugriff auf die internen Trainingsdaten des Modells zu benötigen, leiten die Autoren Theorem 2 ab, eine geschlossene, modellunabhängige Begleit-Schranke für $H(c^*)$ . Diese Schranke nutzt die Komprimierbarkeit von Quellcode:
$H(c^*) \leq \min(L_{max} \log V, |c^*|_{gz})$
wobei $L_{max}$ die maximale Token-Länge, $V$ die Vokabulargröße und $|c^*|_{gz}$ die erwartete gzip-komprimierte Länge der kanonischen Lösungen ist.

Empirische Validierung
Die Autoren validieren die Korollar 1 (Embedded-Variable-Bound) mittels eines Output-only-Embedding-Protokolls. Um die für den Beweis erforderliche Markov-Kette ( $z_\pi \to p \to \tilde{p} \to \tilde{z}_\pi$ ) zu bewahren, wird das Embedding $E$ nur auf den generierten Code angewendet, unter Ausschluss des Prompt-Kontexts.

Modelle & Datensätze: Experimente wurden mit CodeLlama-7B und Qwen2.5-Coder-7B auf HumanEval und MBPP-bereinigten Datensätzen durchgeführt.
Schätzer: Die gegenseitige Information wurde mittels MINE (Mutual Information Neural Estimation) und KSG (Kraskov-Stögbauer-Grassberger) Schätzern auf die Hidden States des letzten Tokens (reduziert durch PCA) geschätzt.
Störungen: Ein Pool von 23 Störungen wurde verwendet, einschließlich Synonymtausch, Negation, Kommentarinjektion (einschließlich Sicherheits-Anti-Kommentaren) und Umbenennung von Identifikatoren.

Wichtigste Ergebnisse

Erfüllung der Schranke: Über sechs einzelne Validierungskonfigurationen hinweg (variierende Modelle, Datensätze, Präzision und Embedding-Ablationen) erfüllte die eingebettete Prüfung die Ungleichung. Das Sättigungsverhältnis $(Cap + \max_T Sec) / (H(z^*) + \max_T I(p; \tilde{p}))$ lag zwischen 0,27 und 0,92, mit positivem Theorem-Slack (2,36 bis 26,94 Nats).
Stabilität: Eine Stabilitätsdiagnose mit drei Seeds zeigte eine mittlere Sättigung von 0,87.
Stresstests: Adaptive Stresstests, einschließlich eines 23-Störungen-Pools, eines fixen universellen Sicherheits-Anti-Suffix und eines gradientenbasierten PGD-Angriffs, führten alle zu positivem Slack, was bestätigt, dass die Schranke auch unter aggressiven Störungsstrategien hält.
Pro-Problem-Signal: Während die theoretische Schranke auf Output-only-Embeddings basiert, wurde festgestellt, dass ein separater Context-mixed-Embedding-Cosine (unter Berücksichtigung von sowohl Prompt als auch Code) mit der Ausführungs-Erfolgsrate pass@1 korreliert (z. B. $\rho=0,36$ für CodeLlama-HumanEval), was als praktisches Alignment-Signal dient, das sich vom Sicherheits-Bound unterscheidet.
Leakage-Analyse: Die Studie identifizierte, dass die Umbenennung von Identifikatoren und die Synonymsubstitution die größten gemeinsamen Informations-Obergrenzen hinterlassen (hohes $I(p; \tilde{p})$ ), während Sicherheits-Anti-Kommentare weniger Prompt-Informationen leaken, aber gefährlicher für die Sicherheit sind.

Bedeutung und Ansprüche
Das Paper beansprucht, ein quantitatives, informationstheoretisches Budget für die Stabilität der Codegenerierung bereitzustellen. Seine Bedeutung liegt in:

Dekomposition: Die Trennung des „Budgets“ in Aufgabenentropie und Prompt-Leakage ermöglicht es Entwicklern zu verstehen, dass die Reduzierung des Prompt-Leakage ( $I(p; \tilde{p})$ ) die maximal verfügbare Kapazität für einen Angreifer einschränkt, ohne notwendigerweise die funktionale Kapazität zu erhöhen.
Modellunabhängige Obergrenze: Die geschlossene Schranke für $H(c^*)$ erlaubt es, eine Sicherheits-Obergrenze für jedes neue Modell auf einem bekannten Aufgabensatz zu berechnen, ohne Zugriff auf das Modell oder dessen Trainingsdaten zu benötigen, indem lediglich auf den Tokenizer und die Verteilung der kanonischen Lösungen zurückgegriffen wird.
Praktische Leitplanken: Die Autoren argumentieren, dass Guardrails für Programmierassistenten nicht nur durch pass@1, sondern durch die Menge der durch Prompt-Störungen verfügbaren Information evaluiert werden sollten. Die Schranke bietet einen Test für Prompt-Härtung: Die Reduzierung von $I(p; \tilde{p})$ sollte das Sicherheitsbudget verengen.

Die Autoren bleiben bescheiden und merken an, dass der Beitrag die Instanziierung dieser Konzepte für die Codegenerierung ist (Definition des Budgets und der geschlossenen Obergrenze) und nicht ein neues Datenverarbeitungs-Theorem. Sie räumen Einschränkungen ein, einschließlich der Sensitivität von MI-Schätzern (wobei MINE in der Nähe von Grenzen überschätzen kann) und der Tatsache, dass die Schranke das verfügbare Stabilitätsbudget charakterisiert, anstatt zu beweisen, dass realistische Angreifer dieses immer sättigen werden.