Google schickt einen Theorembeweiser gegen KI-geschriebene Sicherheitsregeln

Google lässt den Z3-Theorembeweiser über KI-geschriebene Zugriffsregeln wachen

Am 18. August 2026 kündigte Sean Huh vom Common Expression Language Team bei Google im Google Open Source Blog das CEL Formal Verification Framework an. Die Common Expression Language, kurz CEL, steuert bei Google und in zahlreichen Cloud-Systemen Autorisierungs- und Sicherheitsregeln — und genau diese Regeln schreiben inzwischen zunehmend KI-Agenten selbst. „We are rapidly entering an era where AI agents can autonomously draft, refactor, and deploy policies that protect our users and our systems“, schreibt Huh, bevor er die eigentliche Sorge benennt: „How do we trust AI-generated policies?“

Genau an dieser Frage setzt CEL formale Verifikation an. Statt sich auf Stichprobentests zu verlassen, verspricht Google mathematische Beweise für jede Regel, die ein Agent schreibt, ändert oder ausrollt. Das klingt zunächst nach einem internen Werkzeug für Infrastrukturteams. Für jedes Unternehmen, das CEL — etwa in Kubernetes-Richtlinien, API-Gateways oder eigenen Autorisierungsschichten — produktiv einsetzt, ist es aber ein direkter Hinweis darauf, wie ernst Google das Risiko von KI-geschriebenem Regelwerk mittlerweile nimmt.

Substanz hat die Ankündigung, weil sie sich auf ein bekanntes Werkzeug stützt: den Z3-Theorembeweiser, einen SMT-Solver, den Microsoft Research seit Jahren für automatisierte Softwareverifikation pflegt. Google nutzt ihn, um CEL-Ausdrücke gegen den gesamten Eingaberaum zu prüfen, nicht nur gegen die Beispiele, die ein Entwicklerteam sich beim Schreiben von Tests ausgedacht hat. Diese Verschiebung — von Stichprobe zu vollständigem Beweis — ist der eigentliche Kern der Ankündigung und unterscheidet formale Verifikation grundlegend von klassischem Testen. Zur Veranschaulichung veröffentlichte Google zusätzlich ein Video, das zeigt, wie ein interaktives REPL-Werkzeug für den Verifier subtile Logikfehler binnen Sekunden aufdeckt, statt sie einer manuellen Codereview zu überlassen.

Unit-Tests reichen nicht mehr, wenn Agenten selbst Regeln umbauen

Der Ausgangspunkt der Ankündigung ist eine nüchterne technische Beobachtung: „Unit tests may fail to cover the infinite set of possible inputs that occur in production; thus, an AI agent that overfits its policy to existing tests may fail spectacularly in production“, schreibt Huh. Ein Agent, der eine Regel so lange anpasst, bis alle vorhandenen Tests grün sind, hat damit noch nicht bewiesen, dass die Regel für jede denkbare Eingabe korrekt bleibt.

Diese Lücke ist nicht neu, sie wird aber durch die Geschwindigkeit von Agenten dringlicher. Pflegt ein Mensch eine Autorisierungsregel über Monate, wachsen Testabdeckung und Erfahrungswissen langsam mit. Ein Agent kann dieselbe Regel innerhalb einer einzigen Session mehrfach umschreiben, und jede Version müsste eigentlich erneut vollständig geprüft werden, bevor sie live geht. Manuelle Review-Zyklen halten dieses Tempo kaum durch, zumal Reviewer selten die Zeit haben, jede neue Fassung gegen sämtliche Randfälle im Kopf durchzuspielen.

Googles Antwort ist die Kombination aus heuristischem Testen und mathematischem Beweis: „To secure automated policy authoring, we must combine heuristic testing with mathematical proofs“, heißt es im Blogbeitrag. Für CEL formale Verifikation bedeutet das konkret, dass ein Ausdruck nicht mehr nur gegen eine Handvoll Beispiele läuft, sondern gegen den kompletten, mathematisch beschreibbaren Eingaberaum. Getestet wird also nicht mehr, ob eine Regel in bekannten Situationen funktioniert, sondern ob sie in jeder überhaupt möglichen Situation hält.

Beweise ergänzen gewöhnliche Tests

Ein zweites Beispiel verlässt die Ebene einzelner Ausdrücke und wendet sich Kubernetes Validating Admission Policies zu. Ein Techniker formuliert eine Schutzregel, die davon ausgeht, jede Anfrage liege entweder unter Port 80 oder über Port 1024: request.port > 1024 || request.port <= 80.

Bei einer Validitätsprüfung durchsucht der Verifier den gesamten ganzzahligen Eingaberaum, nicht nur ein paar Stichproben, und liefert das Gegenbeispiel request.port = 81 — ein Wert, der weder unter 80 noch über 1024 liegt und die Annahme damit widerlegt. Kein Testsuite-Autor hätte vermutlich gezielt genau diesen einen Port geprüft, weil er auf den ersten Blick unauffällig wirkt und in keiner Beispiel-Liste besonders hervorsticht.

Genau das ist gemeint, wenn Beweise gewöhnliche Tests ergänzen: Tests bestätigen, dass ein paar gewählte Fälle funktionieren. Ein Beweis bestätigt, dass kein einziger Fall aus einem unendlichen Raum die Regel bricht. Für CEL formale Verifikation ist dieser Unterschied keine akademische Spitzfindigkeit, sondern der Grund, warum Google das Werkzeug überhaupt gebaut hat — Admission-Policies in Kubernetes-Clustern laufen schließlich gegen echten Produktionsverkehr, nicht gegen eine kuratierte Testdatenbank.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellflux_2; model=pro; resolution=1k; aspect_ratio=16:9; web derivative 1200x675PromptIn a quiet university seminar room under soft daylight, three researchers compare unmarked policy cards against a geometric proof path drawn only with colored lines. A documentary composition emphasizes practical consequences; every surface is blank and unbranded, with no readable text, words, numbers, labels, logos, screens, user interfaces, dashboards, or signs. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

Ein einziges Klammernproblem hätte Port 443 außerhalb der Produktion freigegeben

Wie konkret das aussieht, zeigt ein Beispiel aus der Ankündigung. Eine Policy soll in der Produktionsumgebung nur die Ports 80 und 443 erlauben. Ein Agent refaktoriert die Bedingung (is_prod && port == 80) || (is_prod && port == 443) zu is_prod && port == 80 || port == 443 — scheinbar äquivalent, aber durch die höhere Bindungsstärke von UND gegenüber ODER tatsächlich eine andere Regel.

Der Verifier markiert diese Umformung sofort als „Violated“ und liefert das exakte Gegenbeispiel: Außerhalb der Produktionsumgebung, wenn is_prod auf false steht, lässt die neue Formulierung Port 443 trotzdem durch. Ein Unit-Test mit den üblichen Beispielwerten hätte diesen Fehler mit hoher Wahrscheinlichkeit übersehen, weil die Kombination aus is_prod=false und port=443 selten gezielt getestet wird — sie sieht auf den ersten Blick schlicht nicht nach einem naheliegenden Testfall aus.

Erst nach Korrektur der Klammerung meldet das Werkzeug „Verified“. Das ist der Kern des Versprechens hinter CEL formale Verifikation: Eine Regel wird nicht geglaubt, weil sie plausibel aussieht, sondern bewiesen, weil kein Gegenbeispiel mehr existiert. Wie gravierend ein übersehener Logikfehler in der Praxis ausfallen kann, zeigt unsere Analyse zur kritischen Sicherheitslücke, die Gmail und Google-Konten über einen KI-Browser-Agenten gefährdete. Für Teams, die Refactorings routinemäßig an Agenten delegieren, ist ein bewiesenes Gegenbeispiel kein Detail, sondern die eigentliche Absicherung gegen genau jene Fehler, die durch schnelles, iteratives Umschreiben entstehen.

CEL-Policy-Blöcke prüfen, ob ein Agent heimlich privilegierte Workloads durchwinkt

Für komplexere Systeme, in denen mehrere Regeln und Variablen zusammenspielen, nutzt Google das CEL-Policy-Format mit assume- und assert-Blöcken. Im Beispiel workload_admission formuliert eine Bedingung fälschlich: request.is_privileged && request.is_prod ergibt output true — ganz ohne Prüfung von Freigabe oder Admin-Status.

Die Invariante universal_no_unapproved_privileged_prod nimmt an, dass has_approval auf false steht und is_admin ebenfalls false ist, und behauptet, das Regelergebnis müsse dann false sein. Der Verifier widerlegt genau das mit einem konkreten Gegenbeispiel: request.is_privileged = true, request.is_prod = true, request.has_approval = false, request.auth.claims.groups = []. Ein privilegierter Workload würde damit ohne jede Freigabe in die Produktion gelangen — ein Fehler, der in einer klassischen Testsuite leicht als Randfall durchrutscht.

Assume- und assert-Blöcke definieren laut Google die Grenzen akzeptablen Agentenverhaltens und lassen sich in CI/CD-Pipelines einbauen, um KI-generierte Änderungen automatisiert gegenzuprüfen, bevor sie ausgerollt werden. Für Teams, die Agenten produktive Regeln schreiben lassen, ist das der Unterschied zwischen einem echten Sicherheitsnetz und einem bloßen Vertrauensvorschuss gegenüber der Maschine. Wer diesen Schritt auslässt, verlässt sich letztlich auf das Versprechen des Agenten selbst.

Drei-Pass-Taint-Tracking soll Fehlalarme aus dem Verifikationsprozess verbannen

Formale Verifikation hat ein bekanntes Akzeptanzproblem: Werkzeuge, die zu oft falschen Alarm schlagen, werden von Entwicklungsteams schnell ignoriert oder aus der Pipeline entfernt. Google adressiert das mit dreistufigem Taint-Tracking. Stößt der Verifier auf eine benutzerdefinierte Funktion oder externe Variable, die er nicht vollständig versteht, markiert er das Ergebnis als „Inconclusive“, statt eine CI-Pipeline mit einer falschen Verletzungsmeldung zu blockieren.

Google formuliert den Anspruch entsprechend hart: Jede gemeldete „Violation“ soll zu 100 Prozent real und reproduzierbar sein. Für Sicherheitsteams ist dieses Detail wichtiger, als es zunächst klingt. Ein Verifikationstool, dem niemand mehr vertraut, weil es zu oft falsch liegt, verliert seinen praktischen Nutzen — unabhängig davon, wie elegant die zugrunde liegende Mathematik ist. Akzeptanz entscheidet am Ende mehr über den Erfolg eines solchen Werkzeugs als seine theoretische Eleganz.

Ergänzt wird das durch konfigurierbares bounded-model checking, das unendliche Schleifen innerhalb der SMT-Quantoren verhindert und die Kosten der Verifikation bei tiefen Strukturvergleichen wie verschachtelte Listen wie [eins] und [zwei] gegeneinander begrenzt. Wie Systeme mit vergleichbaren Sicherheitsversprechen überhaupt geprüft werden, bevor sie produktiv gehen, beschreibt unser Beitrag zur Sicherheitszertifizierung von Systemen und der Frage, wer vor dem Rollout eigentlich prüft. Beide Mechanismen zusammen entscheiden darüber, ob CEL formale Verifikation im Alltag eines Entwicklungsteams tatsächlich genutzt wird oder nach der ersten Fehlalarmwelle in der Schublade verschwindet.

Der Beweis wird zur Pflicht, sobald Code sich selbst schreibt

Google fasst die eigene Motivation so zusammen: Mathematischer Beweis sei kein nettes Extra, sondern die notwendige Vertrauensbrücke, damit Entwicklerteams KI-Agenten überhaupt in ihren sensibelsten Systemen autonom handeln lassen. Diese Formulierung ist auch als Antwort an skeptische Sicherheitsteams zu lesen, die Agenten grundsätzlich keine Schreibrechte auf produktive Regeln geben wollen.

Wie berechtigt diese Skepsis sein kann, zeigt sich am Muster des Angriffs selbst: Autonome Systeme mit zu weit gefassten Rechten sind in der Praxis wiederholt zum Einfallstor geworden, bevor jemand die zugrunde liegende Regel überhaupt hinterfragt hat. Ein Beweisverfahren wie das CEL Formal Verification Framework verschiebt genau diese Art von Risiko von der Produktionsumgebung zurück in die Entwicklungsphase, bevor ein Schaden überhaupt entstehen kann.

Ob Unternehmen das Werkzeug tatsächlich einsetzen, hängt davon ab, ob sie CEL bereits für Autorisierungsentscheidungen nutzen und ob ihre Sicherheitsteams die Zeit investieren, assume- und assert-Blöcke für die eigenen kritischen Regeln zu formulieren. Ein fertiges Framework allein schreibt niemandem automatisch sichere Policies, und ohne formulierte Invarianten bleibt selbst der beste Solver wirkungslos. CEL formale Verifikation ist ein Baustein in einer längeren Kette aus Testabdeckung, Codereview und Audit-Protokollen, kein Ersatz für sie.