← Alle Ressourcen
DiskussionspapierVersion 0.1

Grundlagen adversarieller Isolation

Ein Diskussionspapier vor der Session zu Systemgrenzen, Bedrohungsannahmen, Kontrollschichten und offenen Fragen bei der Isolation leistungsfähiger autonomer Agenten.

Veröffentlicht am 24. Juli 2026

Zweck und Status

Dieses Papier schafft eine technische Grundlage für PESAEAS Marokko #1 in Rabat. Es ist ein Diskussionspapier, keine fertige Spezifikation, Sicherheitszusage oder Dokumentation eines fachlichen Konsenses.

Der Gegenstand ist Isolation: die Begrenzung dessen, was ein autonomes System beobachten, verändern, aufrufen und übertragen darf, wenn kooperatives Verhalten nicht vorausgesetzt werden kann. Modellausrichtung, Fähigkeitsbewertung und allgemeine Anwendungssicherheit sind wichtig, ersetzen aber keine belastbare Isolationsgrenze.

Das Isolationsproblem

Eine herkömmliche Sandbox behandelt eine Arbeitslast häufig als nicht vertrauenswürdig, aber mechanisch vorhersehbar. Ein autonomer Agent verändert diese Annahme: Er kann alternative Pfade suchen, harmlose Fähigkeiten zu einer schädlichen Folge verbinden, Bediener beeinflussen oder sich anpassen, nachdem ein erster Versuch blockiert wurde.

Isolation muss daher als Systemeigenschaft behandelt werden. Modell, Werkzeuge, Zugangsdaten, Laufzeit, Netzwerk, Datenspeicher, Bediener, Überwachung und Abschaltmechanismus gehören gemeinsam zur Grenze. Eine starke Kontrolle auf einer Ebene gleicht einen unbeschränkten Pfad auf einer anderen nicht aus.

Bedrohungsannahmen

Die Diskussion beginnt mit den folgenden Annahmen. Sie sind bewusst vorsichtig und sollten für eine konkrete Bereitstellung eingegrenzt werden, statt als universell zu gelten.

  • Das isolierte System kann Strategien entdecken, die seine Entwickler nicht vorausgesehen haben.
  • Werkzeugaufrufe, externe Dienste, Plugins und menschliche Bediener können indirekte Ausbruchspfade bilden.
  • Zugangsdaten und Berechtigungen können weiter reichen, als die Aufgabe tatsächlich erfordert.
  • Telemetrie kann während eines Vorfalls unvollständig, verzögert, deaktiviert oder manipuliert sein.
  • Der Ausfall einer Komponente darf die Autorität oder externe Reichweite des Systems nicht automatisch erweitern.

Minimale Kontrollstruktur

Ein glaubwürdiger Enclave-Entwurf sollte erklären, wie die folgenden Kontrollen zusammenwirken und welche Komponente vertrauenswürdig bleibt, wenn eine andere ausfällt.

  • Explizite Schutzgüter und Vertrauensgrenzen: festlegen, was geschützt werden muss und was die Arbeitslast erreichen kann.
  • Standardmäßig verweigerte Autorität: enge Fähigkeiten für eine bestimmte Aufgabe, Dauer und ein Ziel vergeben.
  • Vollständige Vermittlung: relevante Übergänge für Werkzeuge, Daten, Netzwerk, Dateien und Ausführung prüfen.
  • Ressourcenbudgets: Zeit, Rechenleistung, Speicher, Prozesserzeugung, Wiederholungen und externe Aufrufe begrenzen.
  • Unabhängige Nachweise: Richtlinienentscheidungen und Grenzereignisse außerhalb der Kontrolle der Arbeitslast erfassen.
  • Wiederherstellung außerhalb des Kontrollpfads: einen Abschalt- und Wiederanlaufpfad erhalten, den das isolierte System nicht autorisieren kann.

Zu untersuchende Fehlerklassen

Das Papier schreibt keine einzelne Implementierung vor. Jede Implementierung soll wiederkehrende Fehlerklassen berücksichtigen.

  • Direkter Ausbruch durch eine Schwachstelle in Laufzeit, Kernel, Hypervisor oder Hardware.
  • Confused-Deputy-Verhalten, bei dem ein erlaubtes Werkzeug eine Handlung ausführt, die dem Agenten direkt verwehrt ist.
  • Datenabfluss über erlaubte Ausgaben, Metadaten, Zeitverhalten oder codierte Inhalte.
  • Ressourcenerschöpfung, die Überwachung abbaut, unsichere Rückfälle erzwingt oder Bedienerkontrolle verhindert.
  • Kompromittierung der Richtlinien-, Telemetrie-, Aktualisierungs- oder Notfallsteuerung.

Fragen für die Session in Rabat

Mit diesen Fragen wird die Grundlage an praktischen Systemen geprüft.

  • Welche Handlungen müssen in einer minimalen Bereitstellung autonomer Agenten vermittelt werden?
  • Wo muss die Richtlinie liegen, damit der Agent sie weder umdeuten noch verändern kann?
  • Welche Nachweise unterscheiden einen blockierten von einem unentdeckten Versuch?
  • Welche Fehler müssen geschlossen ausfallen, und wo ist ein kontrollierter Degradationsmodus sicherer?
  • Was ist das kleinste nützliche Isolationsprofil, das ein Ingenieur implementieren und prüfen kann?

Überarbeitung

Nach der Session in Rabat wird das Papier anhand konkreter Einwände, Beispiele und offener Fragen aus der Diskussion überarbeitet. Änderungen an Bedrohungsannahmen werden von Änderungen an der vorgeschlagenen Kontrollstruktur getrennt ausgewiesen.