DigitalOcean Managed Agents: Drei Konfigurationsebenen setzen KI-Agenten klare Grenzen
DigitalOcean zufolge begrenzt die Plattform Managed Agents, die sich derzeit in der öffentlichen Preview befindet, die Handlungsmöglichkeiten eines KI-Agenten über drei Konfigurationsebenen: verborgene Zugangsdaten, ein schreibgeschütztes Dateisystem und eine Netzwerk-Allowlist. Das Unternehmen beschreibt den Aufbau in einem Blogbeitrag, der sich um die reale Migration des Produktions-Backends von huffl von Supabase zu DigitalOcean dreht.
- DigitalOcean Managed Agents begrenzen in der öffentlichen Preview das Verhalten von Agenten über drei Konfigurationsebenen: Zugangsdaten, Dateisystem und Netzwerk.
- Ein Agent migrierte das Backend von huffl.ai (31 Tabellen, 145.432 Zeilen, rund 31.000 Vektor-Embeddings) von Supabase zu DigitalOcean.
- Action Gateway fügt Zugangsdaten erst beim Aufruf hinzu, sodass Tokens nie durch Modell, Prompt oder Transkript laufen.
- Das NVIDIA-OpenShell-Richtlinienprofil openshell-default macht das Dateisystem schreibgeschützt, außer für /workspace, /tmp und /dev/null.
- Der Netzwerkzugriff ist standardmäßig gesperrt, mit einer allow_hosts-Liste, die ein Proxy durchsetzt; Kunden bleiben für die Absicherung verbundener Workloads, Daten und Tools verantwortlich.
Eine Produktionsmigration, gesteuert vom Smartphone
Wie DigitalOcean berichtet, hat ein Managed Agent kürzlich den Umzug des Backends hinter huffl.ai übernommen, das das Unternehmen als echtes Produkt bezeichnet. Das Backend besteht aus 31 Tabellen, 145.432 Zeilen, drei Storage-Buckets und rund 31.000 Vektor-Embeddings. Der Agent richtete die Datenbank ein, spielte die Zugriffsrichtlinien ein, ordnete jede Supabase-Funktion ihrem Gegenstück bei DigitalOcean zu und prüfte die Daten Tabelle für Tabelle. Gesteuert wurde er per Smartphone in einem normalen Chat.
Der Autor Rohit Bhattacharjee argumentiert, dass dieser Komfort kein Sicherheitsmodell sei. Tagelang hatte der Agent Zugriff auf zwei Clouds und arbeitete durchgehend mit Produktionsdaten. Der Beitrag konzentriert sich darauf, wie der Agent innerhalb seiner Grenzen blieb.
DigitalOcean Managed Agents ist die Plattform des Unternehmens, um KI-Agenten in der Produktion zu betreiben. Die Harness Runtime gibt jeder Sitzung eine eigene Firecracker-microVM, und Sitzungen können weiterlaufen, pausieren, fortgesetzt und geforkt werden, auch nachdem ein Laptop geschlossen wurde. Action Gateway bietet einen einzigen verwalteten MCP-Endpunkt zu mehr als 16.000 Tools (Stand Oktober 2026), wobei Zugangsdaten erst im Moment des Aufrufs vermittelt werden und für sensible Aktionen eine menschliche Freigabe möglich ist. Die Plattform ist standardmäßig offen, sodass Nutzer ihr eigenes Harness, Modell oder ihren eigenen Schlüssel mitbringen können. Preview-Produkte werden laut DigitalOcean ohne Service-Level-Agreement angeboten, und Funktionen können sich vor der allgemeinen Verfügbarkeit ändern oder entfallen.
Ebene eins: Zugangsdaten, die der Agent nie besitzt
Die erste Grenze betrifft Geheimnisse. Statt Tokens in einen Prompt oder in Umgebungsvariablen einzufügen, band das Team das DigitalOcean-Token über Action Gateway als verwaltete OAuth-Verbindung an. In der Sitzung wurde kein Schlüssel getippt, eingefügt oder hochgeladen.
Entscheidet der Agent, die DigitalOcean-API aufzurufen, baut er den Aufruf zusammen, und Action Gateway fügt die Zugangsdaten im Moment der Anfrage hinzu. Anschließend kommt das Ergebnis zurück. Laut DigitalOcean läuft das Token zu keinem Zeitpunkt durch das Modell, den Prompt oder das Transkript. Der Agent kann die Zugangsdaten nutzen, erhält ihren Wert aber nicht.
Das Unternehmen gibt an, dies überprüft zu haben. In der Demo-Sitzung prüfte der Agent mitten in der Sitzung seine eigene Umgebung, und die Werte kamen geschwärzt zurück. Die Sandbox enthielt weder ein DigitalOcean-Token noch ein Supabase-Token.
Ebenen zwei und drei: Dateisystem und Netzwerk
Die zweite Ebene ist die Open-Source-Laufzeitumgebung NVIDIA OpenShell, die eine Standardhaltung für Agenten-Sandboxes definiert, die Dateisystem, Netzwerk und gesperrte Bereiche umfasst. In der Konsole klicken Nutzer auf Import environment.yaml, wählen die OpenShell-Vorlage, und das Manifest setzt policy_profile: openshell-default. Das Dateisystem ist schreibgeschützt, Schreibzugriffe sind nur auf /workspace, /tmp und /dev/null erlaubt.
DigitalOcean testete den Aufbau, indem es den Agenten bat, eine Datei in /bin anzulegen. Der Agent bat einen Menschen um Freigabe, versuchte es trotzdem und erhielt "Permission denied". Auch ein sudo-Test scheiterte. Anschließend erklärte der Agent die Grenze und bot an, die Datei stattdessen in /tmp abzulegen. Das Unternehmen betont, dass die Durchsetzung von der Harness Runtime mit dem OpenShell-Richtlinienprofil kommt und nicht davon abhängt, dass sich der Agent gut verhält.
Die dritte Ebene ist der ausgehende Netzwerkverkehr. Das Manifest beschränkt allow_hosts auf die Hosts, die der Job benötigt, und der Proxy lehnt jede andere Verbindung ab. Das entspricht der OpenShell-Standardhaltung, den Netzwerkzugriff grundsätzlich zu verweigern und nur eine ausdrückliche Allowlist zuzulassen. Die Liste wird vorab festgelegt und nicht von Menschen überwacht.
Was das für Nutzer bedeutet
DigitalOcean zufolge setzen Managed Agents die OpenShell-Haltung nativ über die Harness Runtime durch, ohne zusätzliche Werkzeuge oder aufgesetzte Richtlinien. Nutzer verbinden ihre Tools, wählen das OpenShell-Profil, und die Grenzen stehen, bevor der Agent die erste Zeile schreibt.
Das Unternehmen zieht außerdem eine Grenze für die eigene Rolle: Die Konfiguration dieser Grenzen sei Aufgabe der Plattform, die Absicherung der mit einem Agenten verbundenen Workloads, Daten und Tools bleibe dagegen in der Verantwortung des Kunden. Managed Agents ist in der öffentlichen Preview verfügbar.
