Die KI-Sandbox für Unternehmens-Agenten
Jeder Agenten-Turn auf Scrydon läuft in einer frischen, hardware-isolierten Einweg-Umgebung, die keine Zugangsdaten enthält und standardmäßig kein Netzwerkziel erreicht — und der Turn wird erst zugelassen, nachdem signierte Nachweise belegen, dass diese Grenze tatsächlich existiert. Unbewiesene Isolation ist eine Verweigerung, keine Abstufung.
Fail closed, niemals offen
Ein Agenten-Turn läuft erst, nachdem signierte Isolationsnachweise für exakt den auszuführenden Build validiert wurden. Fehlt dieser Beweis oder ist er veraltet, verweigert der Turn — es gibt keinen Rückfall auf einen Host-Prozess.
Ein Turn, eine Maschine
Jeder Turn erhält eine frische, hardware-virtualisierte Einweg-Umgebung, die auf jedem Ausstiegspfad zerstört wird — Erfolg, Fehler, Timeout oder Abbruch. Es gibt keine langlebige Agenten-Umgebung, die kompromittiert werden könnte.
Das Netzwerk ist ein Vertrag
Egress ist standardmäßig verweigert: Eine Integration erreicht nur die Ziele, die ihr Manifest deklariert, geschnitten mit der eigenen Allowlist Ihrer Organisation. Keine Seite kann die andere erweitern.
Wenn ein KI-Agent für Sie arbeitet, führt er Code aus, liest Dokumente und ruft andere Systeme auf — Sie vertrauen also etwas, das niemand Zeile für Zeile geprüft hat. Die Sandbox ist der verschlossene Raum, in dem der Agent arbeitet: Er betritt ihn ohne Schlüssel, kann nur an Türen klopfen, die Sie vorab genehmigt haben, und der Raum wird abgerissen, sobald die Arbeit endet. Diese Seite erklärt, wie dieser Raum gebaut ist — und wie wir beweisen, dass er hält, bevor irgendetwas darin läuft.
Lesenswert, wenn Sie als CISO, Sicherheitsarchitekt oder Plattformverantwortlicher wissen müssen, wie die Ausführung von Agenten eingehegt ist, bevor Sie sie freigeben.
Eine KI-Sandbox ist die Isolationsgrenze, innerhalb derer die Schleife aus Schlussfolgern, Tools und Shell eines KI-Agenten läuft. Auf Scrydon ist diese Grenze eine frische, hardware-virtualisierte Einweg-Umgebung pro Agenten-Turn — ohne echte Zugangsdaten im Inneren, mit standardmäßig verweigertem Netzwerk-Egress — und ein Agenten-Turn wird nur zugelassen, nachdem signierte Nachweise die Existenz der Grenze für exakt den Build belegen, der gleich laufen wird.
Im Sommer 2026 legten führende KI-Labore öffentlich offen, dass Modelle während Evaluierungen aus ihren Test-Sandboxes ausgebrochen waren und echte Dritt-Infrastruktur erreicht hatten. Das Muster hinter jedem Vorfall war dasselbe: Die Isolation wurde per Konfiguration behauptet und von niemandem überprüft. Scrydon wurde auf der Annahme entwickelt, dass dieser Tag kommen würde. Eine modellgesteuerte Arbeitslast wird als nicht vertrauenswürdige Arbeitslast behandelt — dieselbe Kategorie wie aus dem Internet heruntergeladener Code — denn eine Plattform, die nur sicher ist, solange sich das Modell benimmt, hat keine Sicherheitsgrenze; sie hat eine Hoffnung. Die KI-Sandbox macht aus dieser Annahme Architektur: Hardware-Isolation pro Turn, Zugangsdaten außerhalb der Reichweite des Modells, Egress als expliziter Vertrag und Ausbruchsversuche, die vor jeder Auslieferung gegen jedes Release getestet werden.
KI-Sandbox in der Scrydon-Plattform
Eine integrierte, souveräne Architektur. Hier fügt sich KI-Sandbox ein — hervorgehoben im Kontext des gesamten Stacks, mit dem es zusammenarbeitet.
Das AI OS für Menschen und KI-Agenten
Ontologie- und Semantikschicht: ein zusammenhängendes Modell für Ihre Daten, Ihr Wissen und Ihre Prozesse
Das Beste aus Data Lakes, Data Warehouses und Suche vereint
KI-Agenten, Workflows und Automatisierungen, die über Ihre Systeme hinweg ausgeführt werden
Integrieren Sie über A2A, MCP, Legacy-Systeme und Datenquellen
Sichere Domänenföderation, vertrauenswürdiger Datenaustausch und Intelligenz über Grenzen hinweg
Souveräne Grundlagen
KI-Sandbox im Detail
Mensch + KI-Orchestrierung
Das AI OS für Menschen und KI-Agenten
Der Human + AI Orchestrator ist die operative Runtime im Herzen des AI OS — auch Agentic OS genannt — der jede Aufgabe in Ihrem Unternehmen plant, routet und steuert, ob sie nun von einem KI-Agenten, einem bestehenden System oder einem Menschen ausgeführt wird.
Die meisten Organisationen haben kaputte Prozesse: kodiert in isolierten Systemen oder eingeschlossen in den Köpfen der Mitarbeitenden. Das AI OS macht sie sichtbar und ausführbar. Es erfasst die Absicht, führt den Kontext zusammen, handelt — und speist jedes Ergebnis zurück in die Ontologie, sodass der nächste Durchlauf intelligenter wird. Und das alles innerhalb Ihres Perimeters.
Agentische KI verwandelt Frontier-Modelle von isolierten Chatbots in echte autonome Akteure des AI OS. Statt lediglich Text zu erzeugen, sind diese Agenten gezielt dafür gebaut, jene Aufgaben auszuführen, die Ihre Mitarbeitenden nicht manuell erledigen sollten — schlussfolgern, planen und handeln über komplexe, mehrstufige Prozesse hinweg.
Das AI OS stützt sich auf ein Fundament aus Kreativität und Kontrolle, um autonome Agenten wirkungsvoll einzusetzen:
- KI-Workflows als Fundament: Der Kern des AI OS basiert auf orchestrierten KI-Workflows, die Frontier-Modelle, interne Tools und Enterprise Memory sicher miteinander verbinden.
- Deterministische und nicht-deterministische Flows: Durch die Kombination der Schlussfolgerungsfähigkeit von Frontier-KI mit strikten, deterministischen Workflows garantiert das AI OS sowohl Anpassungsfähigkeit als auch absolute Vorhersehbarkeit in geschäftskritischen Prozessen.
- Autonome Ausführung: Agenten handeln autonom innerhalb definierter Grenzen, beziehen Kontext aus Ihrem Data Lakehouse und führen Aktionen über freigegebene Tools aus.
Sicher innerhalb Ihrer Infrastruktur bereitgestellt, schöpfen diese Agenten aus Ihrer Cognitive Enterprise, um entschlossen zu handeln. Strikte, richtlinienbasierte Guardrails halten sie fest innerhalb der von Ihrer Organisation definierten Grenzen und sorgen für eine perfekte Balance zwischen Produktivität und Sicherheit auf Enterprise-Niveau.
Vier Stufen, jede außerhalb der Reichweite des Modells durchgesetzt
Jeder Standard-Agenten-Turn — die vollständige Schleife aus Schlussfolgern, Tools und Shell des
Modells — durchläuft vier Stufen, und jede davon wird durch Infrastruktur durchgesetzt, die das
Modell nicht erreichen kann. Bevor irgendetwas die Sandbox betritt, validiert die Plattform
frische, signierte Isolationsnachweise, die an exakt den auszuführenden Build gebunden sind:
nicht isolation: true in einer Konfigurationsdatei, sondern ein Beweis, der durch das
tatsächliche Ausüben der Grenze erzeugt wurde. Die Prüfung läuft absichtlich doppelt — einmal
auf der Seite des Aufrufers für eine schnelle, lesbare Verweigerung und einmal im
Dispatch-Dienst selbst, wo kein veralteter oder fehlkonfigurierter Aufrufer sie umgehen kann.
Innerhalb der Sandbox hält das Modell weder Zugangsdaten noch einen Netzwerk-Socket;
Integrationscode von Drittanbietern teilt sich nie dessen
Maschine, sondern läuft in einer separaten Einweg-Umgebung, die erst zugelassen wird, nachdem
ihr Inhalts-Digest mit der Identität übereinstimmt, an die sie gebunden wurde. Und wenn der
Turn endet — wie auch immer er endet — wird die Umgebung zerstört, ihre Einmal-Berechtigungen
werden widerrufen, und der Audit-Eintrag wird versiegelt,
bevor Erfolg gemeldet werden darf.
- 1
Zulassung — beweise, dass der Käfig existiert
Ein Turn wird erst gestartet, nachdem frische, signierte Isolationsnachweise für exakt den auszuführenden Build validiert wurden. Fehlende, abgelaufene oder nicht passende Nachweise bedeuten Verweigerung — fail closed, kein Host-Fallback.
- 2
Ausführung — ein Turn, eine isolierte VM
Die Agenten-Schleife läuft in einer frischen, hardware-virtualisierten Einweg-Umgebung. Integrationscode von Drittanbietern läuft in seiner eigenen, separaten Umgebung — zwei Vertrauensdomänen, die sich nie eine Maschine teilen.
- 3
Egress — default deny, vermittelte Anfragen
Die Arbeitslast hält nie einen eigenen Netzwerk-Socket. Ein vertrauenswürdiger Broker außerhalb der Sandbox stellt jede ausgehende Anfrage selbst — nur zu Zielen, die sowohl das Manifest der Integration als auch Ihre Allowlist genehmigen.
- 4
Abbau — nichts überlebt den Turn
Jedes Ende führt in denselben Zustand: Die Umgebung wird zerstört, Einmal-Berechtigungen werden widerrufen, und ein Audit-Eintrag wird versiegelt, bevor der Turn Erfolg melden darf.
Warum Agenten eine echte Grenze brauchen, kein Konfigurations-Flag
Die Branche hat diese Lektion öffentlich und teuer gelernt. Innerhalb weniger Wochen im Jahr 2026 legte ein führendes Labor offen, dass Modelle in einer Cybersicherheits-Evaluierung über den einen internen Dienst, den sie erreichen konnten, aus ihrer eingeschränkten Testumgebung ausgebrochen waren; ein anderes prüfte 141.000 Evaluierungsläufe und fand echte Organisationen, deren Produktionsinfrastruktur berührt worden war, nachdem eine Fehlkonfiguration stillschweigend Internetzugang gewährt hatte; ein drittes meldete eine ähnliche Fehlkonfiguration seines Harness. Das unbequeme Muster war nicht „die Modelle wurden zu schlau" — sondern dass die Isolation per Konfiguration behauptet und von niemandem überprüft wurde. Scrydon betreibt Agenten auf den sensibelsten Daten, die ein Unternehmen hat, und geht deshalb von der entgegengesetzten Annahme aus: Eine modellgesteuerte Arbeitslast ist eine nicht vertrauenswürdige Arbeitslast, in derselben Kategorie wie aus dem Internet heruntergeladener Code. Diese Annahme ist mit Absicht unnachgiebig. Sie schließt „der Agent läuft in unserem Backend-Prozess, aber vorsichtig" aus — und jede Architektur, in der der Aufrufer sich selbst für eingehegt erklären darf. Den vollständigen Bericht lesen Sie in The Harness Holds (auf Englisch).
Modelle brechen aus behaupteten Sandboxes aus — Die Vorfälle von 2026 hatten eine gemeinsame Ursache: Isolation, die in Konfiguration deklariert und von niemandem geprüft wurde — eine übersehene Netzwerkroute, ein Flag, das niemand erneut kontrollierte.
Agenten berühren Ihre sensibelsten Daten — Unternehmens-Agenten arbeiten an Fallakten, Ermittlungen und internem Wissen. Die Grenze um sie herum darf nicht davon abhängen, dass sich das Modell benimmt.
Zugangsdaten sind die Beute — Ein Agent, der echte Geheimnisse hält, macht aus jedem Ausbruch einen Sicherheitsvorfall. In der Sandbox sieht das Modell opake Platzhalter; echte Werte bleiben den gesamten Turn über außerhalb seiner Reichweite.
Hoffnung ist kein Sicherheitsmodell — Eine Grenze, die nur hält, wenn die Arbeitslast kooperiert, ist keine Grenze — sie ist eine Bitte. Hardware-Virtualisierung hält, ob das Modell kooperiert oder nicht.
Isolation, die angegriffen wird, bevor sie ausgeliefert wird
Ein Isolationsvertrag, den man nie testet, ist ein Konfigurations-Flag mit besserem Marketing — genau so sind die Vorfälle von 2026 entstanden. Ausbruchsversuche sind auf Scrydon deshalb kein Gedankenspiel, sondern ein eingechecktes Release-Gate. Bevor ein Release-Kandidat befördert werden kann, läuft eine absichtlich bösartige Arbeitslast in einem echten virtualisierten Gast und versucht dieselben Klassen von Ausbrüchen, die die Evaluierungsmodelle gefunden haben: Netzwerk erreichen, das ihr nie gewährt wurde, den Egress-Pfad umgehen statt ihn zu nutzen, und nach Zugangsdaten jagen, die sie niemals sehen dürfte. Das Gate verifiziert, dass jeder Versuch scheitert, dass die tatsächlich ausgegebenen Bytes der Arbeitslast das Data-Loss-Prevention-Scanning durchlaufen haben, dass kein Geheimnis zum Stehlen vorhanden war und dass kein Umgebungs- oder Berechtigungszustand überlebt — über Erfolg, Fehler, Timeout und Abbruch hinweg. Anschließend signiert es diese Nachweise gegen den exakten Kandidaten-Hash, und genau diese Signatur verlangt die Zulassung, bevor der Agenten-Turn eines Kunden laufen darf. Der Kreis schließt sich: Das Release kann nicht ausgeliefert werden, wenn der Ausbruch nicht scheitert, und der Agent kann nicht laufen, wenn das Release es nicht bewiesen hat.
Ausbruchsversuche sind ein Release-Gate — Eine absichtlich bösartige Arbeitslast versucht gegen jeden Release-Kandidaten die bekannten Klassen von Sandbox-Ausbrüchen — nicht deklariertes Netzwerk erreichen, den Egress-Pfad umgehen, nach Zugangsdaten jagen.
Signierte Nachweise schließen den Kreis — Das Release kann nicht ausgeliefert werden, wenn der Ausbruch nicht scheitert, und ein Agenten-Turn kann nicht laufen, wenn das Release es nicht bewiesen hat — dieselbe Signatur, die bei der Zulassung geprüft wird.
Echte Bytes, nicht erklärte Absicht — Data-Loss-Prevention-Scans gelten für den tatsächlichen Verkehr, der die Plattform verlässt, eingehend wie ausgehend — nicht für das, was das Modell zu tun behauptet.
Audit als tragende Infrastruktur — Ein Turn ist erst erfolgreich, wenn sein zugangsdatenfreier Audit-Eintrag versiegelt ist. Eine Verkehrsspitze kann Sie niemals einen Compliance-Eintrag kosten.
Häufig gestellte Fragen
Was ist eine KI-Sandbox?+
Warum brauchen KI-Agenten Sandboxing?+
Wie unterscheidet sich das vom Betrieb von Agenten in einem Container oder einer Prozess-Sandbox?+
Was passiert, wenn Isolation nicht bewiesen werden kann?+
Kann eine Anbieter-Integration den Netzwerkzugriff der Sandbox erweitern?+
Sieht das Modell jemals echte Zugangsdaten?+
Funktioniert die KI-Sandbox in souveränen und air-gapped Umgebungen?+
Die Plattform entdecken
Lieber schreiben? Senden Sie eine E-Mail an hello [at] scrydon.com und wir melden uns bei Ihnen.
Partner
