DigitalOcean hält Zugangsdaten von autonomen KI-Agenten fern

Warum Geheimnisse im Agenten ein Risiko sind

In einem Beitrag von Tyler Healy beginnt DigitalOcean mit einem Agenten, der eine doppelte Abbuchung untersucht. Er liest eine Kunden-E-Mail, prüft den Zahlungsverlauf, veranlasst eine Erstattung und aktualisiert ein Support-Ticket. Dieser Ablauf erfordert Zugriff auf vertrauliche Daten und die Berechtigung, Geschäftsdaten zu ändern. Bei Tausenden Tickets pro Tag würde es den Sinn der Automatisierung untergraben, jede Zwischenaktion zu prüfen.

Die Gefahr besteht dem Unternehmen zufolge darin, dass der Agent auf nicht vertrauenswürdige Inhalte trifft, während er diese Befugnisse besitzt. Ein Kundenanhang könnte Text enthalten, der als interne Anweisung getarnt ist und den Agenten auffordert, den Zahlungsverlauf an einen Diagnose-Endpunkt hochzuladen. Ein Coding-Agent steht vor einem ähnlichen Risiko, wenn Anweisungen in einem Repository ihn dazu bringen, Quellcode hochzuladen oder Zugangsdaten offenzulegen.

DigitalOcean argumentiert, dass bessere Prompts und strengere Leitplanken das Problem nicht lösen, weil die Gefahr bereits besteht, sobald ein Zugangsdatum in der Umgebung des Agenten liegt. Der Ansatz des Unternehmens geht deshalb von der Annahme aus, dass der Agent das Geheimnis gar nicht erst besitzen sollte.

Action Gateway vermittelt Zugangsdaten erst bei der Ausführung

Laut DigitalOcean führt Managed Agents jeden Agenten in einer isolierten Harness-Sitzung auf der DigitalOcean Harness Runtime aus. Innerhalb dieser Sitzung verfügt der Agent über keine dauerhaften Zugangsdaten: keine API-Schlüssel, keine Tokens, nichts, was in seinem Dateisystem oder Arbeitsspeicher abgelegt wäre. Braucht er eine autorisierte Aktion, läuft der Aufruf über das DigitalOcean Action Gateway, das zwischen autonomen Workloads und mehr als 16.000 verfügbaren Integrationen sitzt.

Das Unternehmen nennt drei Mechanismen:

• Akteursverwaltung. Jede Tool-Verbindung ist an die Partei gebunden, für die der Agent handelt, etwa einen API-Schlüssel, eine gemeinsame OAuth-App oder OAuth pro Nutzer. Der Zugriff lässt sich einem bestimmten Akteur zuordnen, und Teams können den Zugriff eines Agenten pro Endnutzer eingrenzen.
• Auslösen von Tool-Aufrufen. Der Agent bittet das Action Gateway, den Aufruf auszuführen, und das Gateway fügt das Zugangsdatum in diesem Moment ein. Der Agent bekommt den Schlüssel nie zu sehen.
• Refresh-Abläufe. Läuft ein Token ab oder wird mitten im Workflow ein neuer Scope benötigt, zeigt das Action Gateway einen Anmeldelink an und setzt den Aufruf fort, sobald die Autorisierung abgeschlossen ist, ohne dem Agenten ein Refresh-Token auszuhändigen.

Netzwerkkontrollen bilden eine zusätzliche, eigene Ebene. Im Erstattungsbeispiel kann eine Anfrage an einen nicht freigegebenen Diagnose-Endpunkt blockiert werden, selbst wenn der Agent überzeugt wurde, der Upload sei notwendig. DigitalOcean zufolge sind die Berechtigungen und Netzwerkkontrollen so ausgelegt, dass sie dem offenen Policy-Schema von NVIDIA OpenShell entsprechen. So können Sicherheitsteams diese Grenzen zusammen mit der Konfiguration, die die Aufgaben des Agenten festlegt, prüfen und versionieren.

Wenn ein Agent einen eigenen Schlüssel braucht

Nicht jede Workload passt zum Action Gateway, etwa ein privater MCP-Server, eine interne API oder ein Modell-Endpunkt außerhalb des Katalogs. Für diese Fälle macht die Harness Runtime nach Angaben von DigitalOcean die Deklaration selbst zur Sicherheitsgrenze. Wie ein Wert in die Spezifikation der Umgebung geschrieben wird, entscheidet darüber, wer ihn wieder auslesen kann. Die drei Optionen sind bewusst nicht gleichwertig.

• env ist für Konfiguration wie Modellstufen, Endpunkte und Feature-Flags gedacht. Die Werte werden unverändert in der gespeicherten Spezifikation abgelegt und in API-Antworten an jeden zurückgegeben, der die Umgebung lesen darf. Die Harness Runtime durchsucht eingereichte Spezifikationen nach Namen, die wie Zugangsdaten aussehen (*_API_KEY, *_TOKEN, *_PAT), sowie nach bekannten Präfixen (sk-, ghp_, dop_v1_, AKIA) und markiert sie.
• secrets verschiebt den Wert in einen verwalteten Secret-Speicher, der ihn im Ruhezustand verschlüsselt. Er wird aus der gespeicherten Spezifikation entfernt und taucht weder in API-Antworten noch im Event-Stream oder im Control Panel auf. Der echte Wert wird allerdings weiterhin als Umgebungsvariable eingefügt, sodass der Agent und jeder von ihm gestartete Prozess ihn lesen können.
• Scoped Secrets ergänzen den Slot um eine URL und binden das Zugangsdatum an ein einziges HTTPS-Ziel. Die Sandbox erhält unter demselben Variablennamen ein kurzlebiges Autorisierungs-Handle. Ruft der Agent den gebundenen Host auf, löst der Egress-Proxy das Handle ein und hängt das echte Zugangsdatum an.

Schwärme von Sub-Agenten (Beta)

DigitalOcean beschreibt außerdem Schwärme, derzeit in der Beta-Phase, zum Beispiel einen Compliance-Prüfer, der pro Vertrag einen Sub-Agenten sowie weitere für Zusammenfassungen und regulatorische Abfragen auffächert. In der Harness Runtime ist jeder Sub-Agent eine eigene Sitzung mit eigener MicroVM, eigenem Workspace, eigenem Ereignisverlauf und eigener Sitzungs-ID. Das Unternehmen stellt dies der üblichen Schwarmarchitektur gegenüber, bei der Auffächern mehr Threads bedeutet, die sich einen Speicherbereich und einen Satz Umgebungsvariablen teilen.

Geschwister-Agenten teilen standardmäßig nichts, sodass ein Sub-Agent, der einen Vertrag auswertet, nicht den Workspace des Agenten lesen kann, der ihn zusammenfasst. Eine untergeordnete Sitzung wird aus einer Umgebung erzeugt, und ihre Zugangsdaten werden beim Start aus dem Secret-Speicher aufgelöst. Laut DigitalOcean erhält damit die Frage „Worauf hat dieser Sub-Agent Zugriff?“ eine dokumentierte Antwort in der Control Plane. Jede Sitzung führt Buch darüber, welche Secrets sie deklariert hat und woher sie stammen, sodass sich ein Schwarm nachträglich prüfen lässt.

Was das für Teams bedeutet, die Agenten betreiben

Für Teams, die Agenten auf der Plattform einsetzen, lautet das Versprechen: Ein kompromittierter oder manipulierter Agent hat keinen wiederverwendbaren Schlüssel, den er preisgeben könnte, weil Zugangsdaten außerhalb der Sandbox eingefügt und ausgehende Ziele separat beschränkt werden. Da die Grenzen deklarativ sind, können Sicherheitsteams sie zusammen mit der Konfiguration des Agenten prüfen und versionieren. Quelle ist die eigene Darstellung des Unternehmens, unabhängige Tests oder Angaben zu Preisen enthält sie nicht.