Claude Managed Agents mit OpenShell: Zugriffe gezielt begrenzen

Was Claude Managed Agents mit OpenShell verändert

Anthropic beschreibt die Kombination als mehrere voneinander getrennte Kontrollschichten. Managed Agents organisiert die Agentenarbeit und verwahrt benötigte Zugangsdaten in einem getrennten Vault. NVIDIA OpenShell begrenzt in der Ausführungsumgebung, was ein Agent erreichen und ausführen darf. Die Regeln werden außerhalb des Modells durchgesetzt. Unternehmen können eine Sandbox auf eigener Infrastruktur oder bei einem verwalteten Anbieter betreiben. Quelle: Ankündigung zur NVIDIA-Zusammenarbeit vom 28. September.

Das ist für Aufgaben interessant, die über das Schreiben einer Antwort hinausgehen: Ein Agent liest Dateien, erzeugt Berichte oder bereitet eine Änderung in einem internen System vor. Für solche Prozesse muss das Unternehmen genau bestimmen, welche Aktionen zulässig sind. Ein allgemeiner Hinweis im Prompt ersetzt diese technische Begrenzung nicht. Unsere Leistung zu Claude Managed Agents beginnt deshalb beim konkreten Arbeitsablauf.

Drei Ebenen: Modell, Agentensteuerung und Sandbox

Die Platform-Dokumentation unterscheidet Agent, Umgebung, Session und Ereignisse. Im Agenten werden Modell, Anweisungen und Werkzeuge festgelegt. Die Umgebung bestimmt, wo seine Arbeit ausgeführt wird. Eine Session bearbeitet eine konkrete Aufgabe; Ereignisse transportieren Nachrichten und Status. Managed Agents bleibt ein verwalteter Dienst für längere und asynchrone Abläufe. Quelle: Managed Agents overview.

Eigene Einordnung: Eine selbst betriebene Sandbox ist keine Installation des Claude-Modells im eigenen Rechenzentrum. Die Zusage bezieht sich auf die Umgebung, in der Werkzeuge arbeiten. Prüfe getrennt, welche Inhalte an Modell und Agentendienst übertragen werden. Aus „Datei liegt lokal“ folgt nicht „Dateiinhalt verlässt das Unternehmen nie“, sobald ein Agent sie für seine Aufgabe verarbeitet.

Zeichne für den Pilot einen einfachen Datenfluss: Eingabedatei, erlaubtes Werkzeug, Modellaufruf, erzeugtes Ergebnis und Ablage. Ergänze bei jeder Station den Betreiber und die vorgesehene Aufbewahrung. Diese Darstellung verhindert Missverständnisse zwischen IT, Fachabteilung und Einkauf. Für andere Ausführungswege bietet unser Ratgeber zu Claude Code auf eigener Infrastruktur eine gesonderte Einordnung.

Zugriffspolitik: kleine Freigaben statt pauschaler Rechte

NVIDIA beschreibt OpenShell als offene Laufzeit mit isolierten Sandboxes und deklarativen Regeln. Die dokumentierten Kontrollen betreffen Dateizugriff, Netzwerk, Prozesse und Zugangsdaten. Die Regeln können beispielsweise unerlaubte ausgehende Verbindungen sperren und Dateizugriffe auf vorgesehene Pfade beschränken. Welche Änderungen sofort wirksam werden und welche eine neue Sandbox benötigen, unterscheidet sich nach Kontrollbereich. Quelle: NVIDIA OpenShell – Überblick und Kontrollschichten.

Unser Vorschlag für den Anfang: Erlaube ein Eingabeverzeichnis, ein getrenntes Ausgabeverzeichnis und nur die ausdrücklich benötigten Ziele im Netzwerk. Schreibe für jede Freigabe einen Satz zum Zweck. „Berichte im freigegebenen Projektordner lesen“ ist überprüfbar; „Zugriff auf Firmenlaufwerke“ lässt zu viel offen. Für den ersten Versuch sollte es keinen Zugang zu produktiven Schreibaktionen geben.

Prüfe auch die indirekten Wege. Ein zugelassener Dienst kann seinerseits Zugriff auf weitere Daten besitzen. Ein korrekt begrenzter Dateipfad hilft wenig, wenn ein verbundenes Werkzeug beliebige Dokumente des Unternehmens abfragen darf. Die Rechte des Dienstkontos und die Regeln der Sandbox müssen zur selben Aufgabe passen. Dokumentiere Abweichungen, bevor du zusätzliche Verbindungen öffnest.

Pilotvorschlag: Wartungsunterlagen zu einem Bericht bündeln

Eigenes Unternehmensbeispiel: Ein technischer Dienstleister möchte wöchentlich freigegebene Wartungsprotokolle zusammenführen. Der Agent soll fehlende Angaben finden, offene Maßnahmen auflisten und einen Berichtsentwurf erzeugen. Dafür erhält er Kopien von Testprotokollen in einem begrenzten Ordner. Der Auftrag erlaubt ausschließlich das Lesen dieser Kopien und das Schreiben des Entwurfs in einen Ausgabeordner.

Vor dem ersten Lauf erstellt der Fachverantwortliche eine kleine Soll-Liste: Welche Anlagen kommen vor, welche Maßnahmen sind offen und welche Angaben fehlen? Er legt außerdem fest, dass unklare Befunde als Rückfragen erscheinen. Eine fehlende Messung darf nicht als bestandenes Prüfergebnis gelten. Der Bericht bleibt ein Entwurf; ein benannter Mitarbeiter kontrolliert ihn vor jeder Weitergabe.

Ein absichtlich eingebautes Testdokument fordert den Agenten auf, Dateien aus einem anderen Ordner einzulesen. Eine weitere Probe verlangt den Upload an ein nicht freigegebenes Ziel. Diese Anforderungen sollen an den technischen Grenzen scheitern. Das Team prüft die tatsächlichen Versuche und Sperren im Protokoll. Eine bloße Erklärung des Agenten, er habe Regeln beachtet, reicht als Nachweis nicht aus.

Einführung mit messbarer Abnahme

1. Aufgabe und Verantwortliche festlegen: Benenne das gewünschte Ergebnis, den fachlichen Prüfer und den technischen Betreiber. Bestimme eine maximale Laufzeit und ein Budget für den Versuch.
2. Umgebung vorbereiten: Verwende freigegebene Testdaten und getrennte Eingabe- und Ausgabeorte. Halte Modell, Werkzeuge und Versionen für die Wiederholung fest.
3. Regeln dokumentieren: Liste erlaubte Dateibereiche, Netzwerkziele und Aktionen. Prüfe die tatsächlichen Rechte der beteiligten Konten.
4. Normal- und Fehlerfälle ausführen: Teste vollständige Daten, leere Dateien, widersprüchliche Angaben, einen abgelaufenen Zugang und einen unterbrochenen Lauf.
5. Ergebnis und Verhalten bewerten: Vergleiche den Bericht mit der Soll-Liste. Prüfe zusätzlich, ob unerlaubte Zugriffe blockiert wurden und Kosten innerhalb des Rahmens blieben.
6. Betrieb freigeben: Erweitere den Umfang erst nach dokumentierter Abnahme. Jede neue Datenquelle braucht erneut passende Regeln und Testfälle.

Ein Abbruch muss ein verständliches Ergebnis hinterlassen: Was wurde bearbeitet, was ist unvollständig und welche Ausgabe darf verwendet werden? Für unseren Pilot lautet die Vorgabe, unvollständige Berichte klar zu kennzeichnen. Eine Wiederholung soll keinen bereits geprüften Bericht unbemerkt überschreiben.

Verfügbarkeit, Aufbewahrung und laufender Aufwand

Produktgrenze: Die offizielle Übersicht führt Managed Agents weiterhin als Beta. Wegen der gespeicherten Sessions, Zustände und Ausgaben ist der Dienst aktuell nicht für Zero Data Retention oder HIPAA-BAA-Abdeckung berechtigt. Eine eigene Sandbox hebt diese dokumentierte Grenze nicht auf. Quelle: Beta-Zugang und Datenaufbewahrung. Prüfe den konkreten Datenfluss und Vertrag für deinen Einsatz; die neue Architektur allein ist kein Nachweis für DSGVO-Konformität.

In der Wirtschaftlichkeitsrechnung stehen neben Modell- und Dienstkosten auch Infrastruktur, Updates, Protokollauswertung und die fachliche Abnahme. Unser Vorschlag: Vergleiche die Gesamtkosten pro akzeptiertem Bericht mit dem bisherigen Verfahren. Eine schnell erzeugte Datei spart nichts, wenn anschließend mehr Zeit für Fehlerkorrektur und Nachfragen anfällt.

Für den Regelbetrieb braucht ihr einen erreichbaren Verantwortlichen und einen erprobten Stoppweg. Legt fest, wer bei wiederholten Zugriffsfehlern, ungewöhnlichen Kosten oder unvollständigen Ergebnissen eingreift. Architektur und Pilot für Managed Agents besprechen: Beschreibe uns Aufgabe, Datenquellen und eure Infrastruktur. Wir helfen, Ausführungsumgebung und Freigaben an einem konkreten Prozess zu prüfen.