Stellen Sie sich vor: Es ist Dienstag, 23:40 Uhr. Ein Coding-Agent läuft im Nachtlauf, gekapselt in einer Sandbox. Die Allowlist erlaubt drei Domains, mehr nicht. Das Dashboard zeigt alles grün. Dieses Szenario ist ausdrücklich fiktiv, eine Gedankenstütze und kein Fallbericht. Die Fragen dahinter sind es nicht: Wo liegt der Deploy-Schlüssel? Welche Secrets kennt der Agent? Und wer schaut zu, wenn eine der drei Domains etwas tut, das nicht auf Ihrem Zettel steht?

Grün heißt nicht sicher. Grün heißt: Die aufgeschriebenen Regeln wurden eingehalten. Ob die Regeln reichen, ist eine andere Frage, und sie wird selten gestellt, solange die Anzeige beruhigt.

Spoiler: Im Fall, um den es hier geht, hat die Allowlist nicht versagt. Genau das macht ihn lehrreich. Am Montag, 12. Oktober, hat ein Anbieter von Sicherheitswerkzeugen für KI-Agenten einen Bericht über die domainbasierte Ausgangsfilterung einer Sandbox veröffentlicht. Wir ordnen ihn ein, ohne Technikanleitung, dafür mit Blick auf das, was Verteidigende daraus mitnehmen können.

Der Bogen spannt sich von dem, was der Anbieter berichtet, über das, was Vercel selbst über Netzgrenzen schreibt, bis zu einer Checkliste, die Sie ohne Angriffsdetails abarbeiten können. Die Details brauchen Sie nicht, um Ihre Hausaufgaben zu machen. Sie brauchen eine ehrliche Inventur und ein bisschen Kaffee.

Was AIR Security am 12. Oktober veröffentlicht hat

AIR Security hat am Montag, 12. Oktober 2026, im eigenen Blog den Bericht „VerCellBreak: How we escaped Vercel’s hardened sandbox“ veröffentlicht. Die Forschenden heißen Matan Elgabsi und Or Nevo. Das Wort „escaped“ stammt aus AIRs Titel und gehört AIR, nicht uns. Wir übernehmen es nur als Zitat.

Gefunden wurde der Fall laut AIR im Rahmen von Vercels Bug-Bounty für die Sandbox. Die Sandbox beschreibt AIR als „one of the most secure out there“. Das ist AIRs Einschätzung, keine unabhängige Bewertung, und wir geben sie nur so weiter.

Eine Einordnung in eigener Sache: AIR Security verkauft Sicherheitswerkzeuge für KI-Agenten, darunter Scanner für Agenten und Add-ons. Der Bericht endet mit einem Demo-Angebot. Das macht die Funde nicht falsch. Es erklärt aber, warum der Text so endet, wie er endet. Eine Produktempfehlung sprechen wir nicht aus.

Wichtig für die Gewichtung: Es handelt sich um eine Forschungsdemonstration. AIR nennt keine realen Opfer und keine aktive Ausnutzung. Wer eine Schlagzeile mit großen Zahlen erwartet, wird enttäuscht. Wer sich für Architekturfragen interessiert, eher nicht. Beides gilt gleichzeitig: Der Befund verdient Aufmerksamkeit, und die Quelle hat ein Geschäftsinteresse. Lesen Sie den Originalbericht deshalb im AIR-Blog mit dem Wissen, wer ihn geschrieben hat.

Das Prinzip in einem Satz – und eine Allowlist, die funktioniert

Ein erlaubter Zielserver kann über ein TLS-Standardfeature dazu gebracht werden, selbst eine weitere Adresse abzurufen, wodurch Daten aus der Sandbox abfließen können, obwohl die Sandbox die direkte Verbindung zum fremden Server korrekt blockiert.

Mehr Mechanik gibt es hier nicht. Das ist Absicht.

Plot Twist: Die Allowlist hat funktioniert. Sie hat getan, was sie tun sollte. Die verbotene Verbindung wurde verhindert, die erlaubte durchgelassen. Trotzdem konnte etwas abfließen.

Laut AIR wurde dabei kein Fehler im Server ausgenutzt. Es ist ein Standardfeature, das genau so arbeitet, wie es gedacht ist. Betroffen ist laut AIR die domainbasierte Ausgangsfilterung der Vercel Sandbox, nicht die VM-Isolation. Die Trennung zwischen Gast und Host steht in diesem Bericht also nicht zur Debatte.

Meiner Einschätzung nach ist das der eigentliche Kern. Nicht die einzelne Technik, sondern die Denkfigur: Eine Allowlist prüft das Ziel, das Sie sehen. Sie prüft nicht, was dieses Ziel anschließend selbst tut. Jeder Eintrag auf der Liste ist damit eine Vertrauensentscheidung und nicht bloß eine Adresse.

Hand aufs Herz: Wie viele Freigabelisten in Ihrem Umfeld wurden mit der Frage geschrieben, was der freigegebene Dienst als Nächstes anfasst? Die Antwort ist selten schmeichelhaft. Und sie ist kein Grund, die Liste zu verwerfen. Sie ist ein Grund, sie anders zu lesen.

Out of scope – laut AIR

Laut AIR stufte Vercel den Fund als außerhalb des Programmrahmens ein („out of scope“) und nahm den Report nicht an. Der Grund laut AIR: Die Technik hängt von einem externen Server ab, den Vercel nicht betreibt.

Eine eigene Stellungnahme von Vercel zu VerCellBreak liegt uns nicht vor, Stand 13. Oktober, 06:22 Uhr MESZ. Wir geben deshalb nur AIRs Darstellung wieder und werten sie nicht.

Fair bleibt: Ein Bug-Bounty-Scope regelt, was ein Anbieter bezahlt. Er regelt nicht, welches Risiko bei Ihnen landet. Das sind zwei Kategorien, und sie werden gern verwechselt. Ein Programm braucht Grenzen, sonst ist es nicht zu betreiben, und ein Anbieter muss entscheiden, was er vergütet. Ihr Bedrohungsmodell kennt diese Grenzen nicht. Wenn Ihre Agenten erlaubte Dienste ansprechen, die ihrerseits Anfragen stellen, ist das Ihre Baustelle, egal ob für den Fund irgendwo ein Preisgeld ausgelobt ist. Ein „out of scope“ im Bericht eines Dritten ist deshalb kein Entwarnungssignal. Es ist ein Hinweis, dass die Frage bei Ihnen liegt.

AIR zieht aus dem Fall drei Lehren, die wir laut AIR wiedergeben:

Sandboxing senkt das Risiko, ist allein aber keine Sicherheitsgrenze („not a security boundary on its own“), weil sie nur die Verbindungen blockieren kann, die sie sieht.
Jeder erlaubte Endpunkt kann zum indirekten Abflussweg werden, wenn er angreiferkontrollierte Eingaben verarbeitet und selbst ausgehende Anfragen stellt.
Bedrohungen sollten gestoppt werden, bevor sie den Agenten erreichen: filtern, was der Agent aufnimmt, und Kompromittierung verhindern.

Schutzschichten scheitern oft schon daran, dass sie gar nicht eingeschaltet sind. Wir bei digital-magazin.de haben etwa beschrieben, warum die Copilot-Sandbox standardmäßig aus ist und was das für Netzregeln bedeutet. Wer eine Sandbox nicht aktiviert, hat die Debatte über ihre Grenzen gar nicht erst.

Was Vercel selbst am 10. August über Netzgrenzen schreibt

Ein Zeitstrahl-Hinweis vorweg: Der Vercel-Beitrag „A sandbox without a network boundary is only half a sandbox“ erschien laut Vercel am Montag, 10. August 2026. Das war vor VerCellBreak. Er ist keine Reaktion darauf, und wir lesen ihn auch nicht so.

Lesenswert ist er trotzdem, weil er das Verteidigungsdenken des Anbieters offenlegt. Laut Vercel läuft die Firewall auf dem Host außerhalb der microVM. Domain-Regeln greifen über den Hostnamen im TLS-Handshake, dazu kommen Adressbereiche und Deny-by-default. Wer nichts erlaubt, bekommt nichts. Das ist eine Allowlist mit Rückgrat.

Credential-Injection: Der Schlüssel bleibt draußen

Vercel beschreibt Credential-Injection am Host: „The credential never enters the microVM“. Der Schlüssel wird laut Vercel nur an das konfigurierte Ziel gesendet. Zugangsdaten in Umgebungsvariablen oder Dateien sind dagegen übertragbare Zugangsdaten, die jeder nutzen kann, der sie hat, so Vercel.

Unsere Einordnung dazu: Der Reiz liegt in der Arbeitsteilung. Die Sandbox arbeitet, der Host verwahrt das Secret. Der Agent kann nicht weitergeben, was er nie gesehen hat, weder freiwillig noch unter fremdem Einfluss. Das nimmt dem Fall, in dem ein Agent von untergeschobenen Inhalten gesteuert wird, einen Teil seiner Wirkung. Es ersetzt die übrigen Schichten nicht, aber es verkleinert, was auf dem Spiel steht.

Zeitlich begrenzte Konnektivität: Freigaben nur auf Zeit

Dazu kommt zeitlich begrenzte Konnektivität. Als Beispiel nennt Vercel Paketquellen, die nur in einer vertrauenswürdigen Setup-Phase erreichbar sind. Danach ist Schluss. Unsere Lesart: Die Zeit, in der die Allowlist weit ist, wird kurz und bekannt. Wer Paketquellen dauerhaft freigibt, weil es bequem ist, trägt dieses Risiko durch jeden Nachtlauf.

Weitere Bausteine laut Vercel sind Least Privilege für alles, was der Agent anfassen darf, und ein optionaler eigener Proxy im Weg, der sensible Felder schwärzt, Autorisierung vornimmt und ein Audit-Log führt.

Das Pikante daran: Vercel nennt selbst „a trusted package service turned into a relay“ als bekanntes Muster und zählt „every intentionally permitted destination“ zur Sicherheitsgrenze. Jedes bewusst freigegebene Ziel gehört also mit in die Rechnung. Als mögliche Träger von Prompt Injection nennt Vercel Issues, Logs, Webseiten, Abhängigkeiten und Dokumente. Das ist eine lange Liste für einen Agenten, der nachts allein arbeitet.

Mal ehrlich: Das liest sich wie ein Anbieter, der die Denkfigur kennt. Wie sie sich zu AIRs Befund verhält, beurteilen wir nicht, dafür fehlt die Stellungnahme. Den Beitrag finden Sie im Vercel-Blog.

Die Challenge in Zahlen

Kurz, weil Zahlen schnell mehr behaupten, als sie hergeben. Laut Vercel, in einem Beitrag vom Dienstag, 18. August 2026, lief eine öffentliche Challenge für die Vercel Sandbox als HackerOne-Programm vom 18. August bis 1. September 2026. Der Pool lag bei bis zu 1.000.000 US-Dollar, maximal 50.000 US-Dollar pro Report. Die Ausschreibung steht im Vercel-Blog.

Zum Ergebnis gibt es nur einen Zwischenstand aus zweiter Hand: Laut SecurityWeek (15. September), die Vercel zitiert, gingen 1.285 Reports ein. Bisher seien 1 Critical und 7 High validiert, rund 325.000 US-Dollar zugesagt, und es habe keinen Zugriff auf echte Kundendaten gegeben. Die Triage lief bis 1. Oktober.

Ein Report ist keine Lücke. Wer daraus eine Quote bastelt, liest Kaffeesatz. Wir lassen es. Für Ihre Planung genügt: Auch ein Anbieter, der öffentlich prüfen lässt, ändert nichts an Ihrer eigenen Verantwortung für die Allowlist.

Warum Secrets nicht in die Sandbox gehören

Sandbox als Glaskubus mit Serverrack und Kabel-Lücke nach außen — Wenn die Sandbox doch nach außen reicht (Symbolbild)

Der Gedanke ist unspektakulär und deshalb so brauchbar. Was nie in der Sandbox liegt, kann nicht aus der Sandbox abfließen. Egal über welchen Weg, direkt oder über einen Umweg.

Secrets in Umgebungsvariablen oder Dateien sind laut Vercel übertragbare Zugangsdaten, die jeder nutzen kann, der sie hat. Wer so einen Schlüssel besitzt, braucht keine weitere Erlaubnis. Er braucht nur den Schlüssel.

Wo Zugangsdaten herumliegen, liegen sie selten aus Nachlässigkeit dort. Sie liegen dort, weil es beim ersten Test bequem war und niemand das Provisorium wieder abgebaut hat. Sehen Sie sich Konfigurationsdateien, Umgebung und Build-Skripte an, mit der Frage, was davon ein Agent lesen kann.

Darum der Ansatz, Secrets am Host zu halten. Der Agent stellt eine Anfrage, der Host setzt den Schlüssel erst auf dem Weg zum konfigurierten Ziel ein. Das klingt nach Komfort. Es ist eine Architekturentscheidung. Meiner Einschätzung nach trägt sie weiter als jede Feinarbeit an der Allowlist, weil sie unabhängig davon funktioniert, wie klug die Liste geschrieben ist.

Wo Secrets in der VM unvermeidbar sind, bleiben kurzlebige, eng gescopte Tokens. Wir haben bereits beschrieben, warum Token-Diebstahl ein Dauerthema ist und Tokens kurzlebig sein sollten. Ein Token, das nach Minuten abläuft, ist ein schlechter Schatz.

Die Prüffrage dazu ist unbequem: Was könnte der Agent mitnehmen, wenn er nicht mehr Ihnen gehorcht? Schreiben Sie die Antwort auf. Wenn die Liste länger ist als erwartet, wissen Sie, wo Sie anfangen.

Ihre Checkliste: Secrets, Domains, Logs

Unsere Einordnung bei digital-magazin.de auf Basis der Empfehlungen von AIR und Vercel, zum Abarbeiten:

Secrets raus aus der VM. Nutzen Sie Credential-Injection am Host, wo Ihre Plattform sie anbietet, statt Secrets in der Umgebung der Sandbox abzulegen. Wo das nicht geht, setzen Sie kurzlebige, eng gescopte Tokens ein und rotieren Sie sie nach festem Plan. Prüfen Sie auch Altbestände: Ein Schlüssel aus dem ersten Testlauf ist selten kurzlebig. Stellen Sie sich zum Schluss die Frage: Was könnte der Agent mitnehmen, wenn er nicht mehr Ihnen gehorcht?
Jede erlaubte Domain als mögliches Relay bewerten. Fragen Sie je Eintrag: Verarbeitet der Dienst Eingaben, die der Agent kontrolliert, und stellt er danach selbst ausgehende Anfragen? Denken Sie an Nachladen, Weiterleitungen, Webhooks und Paketquellen. Halten Sie die Allowlist der Sandbox kurz, begrenzen Sie Freigaben zeitlich und lassen Sie Deny-by-default gelten. Streichen Sie, was seit Wochen niemand gebraucht hat.
Betreiberseite mTLS. Wer Dienste mit Client-Zertifikaten betreibt, klärt mit dem eigenen Team oder dem Hersteller des TLS-Stacks, ob bei der Prüfung fremd vorgelegter Zertifikate automatisch externe Adressen abgerufen werden. Falls ja, schränken Sie das per Konfiguration ein: vollständige Ketten verlangen, Nachladen nur von bekannten Quellen oder gar nicht. Halten Sie die Entscheidung schriftlich fest, damit sie bei der nächsten Änderung nicht stillschweigend kippt. Nutzende von Agenten können dieselbe Frage an ihre Dienstleistenden weiterreichen.
Eingaben filtern, bevor sie den Agenten erreichen. Das ist AIRs zentrale Empfehlung: Bedrohungen stoppen, bevor sie den Agenten erreichen. Kennzeichnen Sie nicht vertrauenswürdige Inhalte als solche, etwa Issues, Webseiten, Abhängigkeiten und Dokumente, die Vercel als mögliche Träger nennt. Lassen Sie folgenreiche Aktionen nur nach Freigabe zu. Ein Agent, der alles lesen und alles auslösen darf, ist ein Praktikant mit Generalvollmacht.
Egress-Logging einrichten. Erfassen Sie Ziel, Zeit und Umfang jeder ausgehenden Verbindung, bewahren Sie die Daten datenschutzkonform auf und richten Sie Meldungen bei ungewöhnlichen Mustern ein. Laut Vercel ist optional ein eigener Proxy mit Audit-Log und Schwärzung sensibler Felder möglich. Seien Sie ehrlich zu sich selbst: Das Log der Verbindung zum erlaubten Server zeigt nicht den Abruf, den dieser Server danach selbst ausführt. Ein ruhiges Log ist deshalb ein Indiz, kein Beweis.
Bug-Bounty-Scopes nicht mit Ihrem Risiko verwechseln. Ein Scope regelt, was ein Anbieter bezahlt, nicht, was bei Ihnen passieren kann. Bauen Sie eigene Bedrohungsmodelle, die auch Funde einschließen, die von außen als „out of scope“ gelten. Geben Sie solche Funde intern weiter, an Betrieb, Entwicklung und Datenschutz. Ein Bericht, der im Postfach der Sicherheitsabteilung versandet, hat sein Ziel verfehlt.

Dass Kontrolle außerhalb der Sandbox und außerhalb des Agenten besser trägt als Kontrolle durch den Agenten selbst, haben wir an anderer Stelle begründet. Die Checkliste ist im Kern dieselbe Idee, angewandt auf Netz und Zugangsdaten.

Falls Sie keine Plattformabteilung haben: Das gilt genauso für den Mittelstand und für Privatnutzende, die einen Agenten an ihre Projekte lassen. Gerade dort liegen Schlüssel gern in der Umgebung, weil es schnell gehen musste. Beginnen Sie mit drei Fragen: Wo liegt der Schlüssel, welche Adressen darf die Sandbox erreichen, und wer erfährt es, wenn etwas Ungewöhnliches passiert? Das kostet einen Nachmittag, keine Beschaffung.

Für Betreibende erlaubter Dienste

Bisher stand die Seite der Nutzenden im Mittelpunkt. Es gibt eine zweite: die der Betreibenden von Diensten, die auf fremden Allowlists landen.

Wenn Ihr Dienst Verbindungen mit Client-Zertifikaten annimmt, sind Sie Teil der Kette. Ob Sie wollen oder nicht. Ihr Server steht womöglich auf Freigabelisten, von denen Sie nichts wissen.

Die Frage, die Sie klären sollten, ist schlicht: Ruft Ihr System bei der Prüfung fremd vorgelegter Zertifikate von sich aus externe Adressen ab? Wenn ja, tut es das, weil Sie es so entschieden haben, oder weil es die Voreinstellung ist? Klären Sie das mit dem Team und mit dem Hersteller Ihres TLS-Stacks. Schränken Sie es ein, wo es geht, und dokumentieren Sie, wo es nicht geht.

Laut AIR wurde kein Fehler im Server ausgenutzt, sondern ein Standardfeature genutzt. Der Hebel liegt deshalb weniger in einem Fehler, der behoben wird, und mehr in der Konfiguration, die bei Ihnen liegt. Das ist keine Anklage. Es ist Geometrie.

Zurück zum Szenario: Mittwoch, 8:15 Uhr

Noch einmal in die fiktive Welt vom Anfang, ausdrücklich erfunden und ohne reale Vorlage. Mittwoch, 8:15 Uhr. Das Team sitzt bei Kaffee, der Nachtlauf ist durch, die Anzeige war grün. Und jemand stellt die Fragen, die um 23:40 Uhr niemand gestellt hat.

Es sind vier, und sie lassen sich in einer Viertelstunde klären. Erstens: Wo liegt der Deploy-Schlüssel? In der Umgebung der Sandbox, in einer Datei, in einem Build-Skript, oder verwahrt ihn der Host? Zweitens: Welche der drei Domains lädt selbst nach, leitet weiter, ruft Webhooks auf oder bedient Paketquellen? Drittens: Was zeigt das Egress-Log, und was zeigt es nicht? Viertens: Welche Eingaben hat der Agent in der Nacht gelesen, aus Issues, Logs, Webseiten, Abhängigkeiten oder Dokumenten, und wer hat sie vorher gesehen?

Aus den Antworten folgen drei Handgriffe, kein Großprojekt. Der Schlüssel wandert aus der VM, die Sandbox darf ihn nur noch über den Host nutzen lassen. Die Allowlist wird kürzer: Aus drei Domains werden zwei, die dritte gibt es nur noch in der Setup-Phase. Das Egress-Log wird eingeschaltet, mit Ziel, Zeit und Umfang, und jemand bekommt eine Meldung aufs Telefon, wenn das Muster ungewöhnlich wird.

Ist das spektakulär? Nein. Wirkt es? Meiner Einschätzung nach mehr als die meisten Produktfolien. Ein weiteres Beispiel, warum Agenten Grenzen brauchen, liegt im Archiv. Wir erzählen es hier nicht nach.

Nichts davon setzt voraus, dass jemand tatsächlich angreift. Es genügt, dass Sie nicht mehr darauf wetten, dass nichts passiert.

Was bleibt?

Ein Anbieter mit Eigeninteresse zeigt eine Denkfigur. Ein anderer Anbieter hat gut zwei Monate vorher beschrieben, dass jedes bewusst erlaubte Ziel zur Sicherheitsgrenze zählt. Eine eigene Vercel-Stellungnahme zum konkreten Fall liegt nicht vor. Reale Opfer nennt niemand.

Übrig bleibt die Architekturfrage, und sie ist unabhängig vom Streit über Zuständigkeiten. Eine Sandbox ist eine Schicht. Eine Allowlist ist eine Schicht. Keine von beiden ersetzt die Frage, was überhaupt in der Sandbox liegt und wer zusieht, wenn etwas sie verlässt.

Die Allowlist bleibt nützlich. Sie bleibt nur kein Freibrief. Schauen Sie nach, wo Ihre Secrets liegen. Dann reden wir über den Rest.