DigitalOcean erklärt, wie das Action Gateway Tool-Aufrufe von KI-Agenten kontrolliert

13. Oktober 2026Quelle: DigitalOcean

DigitalOcean hat eine ausführliche Beschreibung des Action Gateway veröffentlicht, der Komponente von Managed Agents, die Aufrufe eines Agenten an externe Systeme abwickelt. Laut dem Unternehmen ist der Vorschlag eines Modells, ein Tool aufzurufen, "eine Anfrage, keine Befugnis". Das Gateway entscheide, ob der Aufruf tatsächlich ausgeführt wird.

Das Wichtigste in Kürze

Das Action Gateway von DigitalOcean regelt in Managed Agents die Aufrufe eines Agenten an externe Systeme, nicht aber lokale Shell-Befehle oder Netzwerkaufrufe außerhalb seines Tool-Pfads.
Ein Tool-Aufruf kann erlaubt, verboten oder mit ask markiert werden. Letzteres verlangt eine menschliche Freigabe, die an das konkrete Tool, die Argumente und die Verbindung gebunden ist.
Die Meta-Tools action.search, action.invoke und action.code ermöglichen es, große Tool-Sammlungen zu nutzen, ohne jedes Schema in den Kontext des Modells zu laden.
Die Suche ordnet nur Tools, für die der Aufrufer berechtigt ist, und action.invoke prüft bei der Ausführung Richtlinie und Verbindung erneut.
Laut DigitalOcean sollen Zugangsdaten der Anbieter außerhalb des Modellkontexts und des vom Modell geschriebenen Codes bleiben.

Arbeitsumgebung des Agenten und externe Aktionen getrennt

DigitalOcean teilt die Arbeit von Agenten in zwei Gruppen: was in der eigenen Umgebung des Agenten geschieht und was andere Systeme erreicht. Eine Datei lesen, pytest ausführen oder ein Repository bearbeiten findet in der eigenen Arbeitsumgebung des Agenten statt. Ein GitHub-Issue anzulegen oder ein Ticket zu aktualisieren ist etwas anderes, denn der Aufruf erreicht eine externe API, oft mit einer Zugangsberechtigung und einer Änderung, die auch andere sehen können.

Das Action Gateway regelt nur diese zweite Gruppe. Es verwaltet die Definitionen der Tools, die es ausführen kann, darunter was ein Tool tut, wie seine Eingaben aufgebaut sind und welche Verbindung und Richtlinie es erfordert. Der Toolbelt eines Kunden ist eine kuratierte Sammlung solcher Tools für einen Agenten oder eine Aufgabe. DigitalOcean beschreibt ihn als Speisekarte, nicht als Freifahrtschein: Ein Tool kann auf der Karte stehen und dennoch von einer Richtlinie abgelehnt werden oder keine gültige Verbindung haben.

Die Grenzen benennt das Unternehmen klar. Das Action Gateway kann weder einen Shell-Befehl steuern, den ein Agent lokal ausführt, noch einen Netzwerkaufruf außerhalb seines Tool-Pfads, weil die Host-Laufzeitumgebung und deren eigene Netzwerkkontrollen diesen Bereich abdecken.

Suche, Meta-Tools und MCP-Zugriff

Das Gateway bietet einen Endpunkt für das Model Context Protocol (MCP), sodass sich ein MCP-kompatibler Client ohne eigene Integration für jeden Anbieter verbinden kann. Bei einem kleinen Toolbelt kann es konkrete Tools bereitstellen. Bei einer deutlich größeren Sammlung kann es stattdessen eine kleinere Zahl von Meta-Tools anbieten:

action.search findet passende Tools innerhalb der autorisierten Menge
action.invoke führt ausgewählte Tools aus
action.code koordiniert voneinander abhängige Aufrufe

Das Modell muss also nicht Hunderte Schemata lesen, um ein einzelnes Tool anzufordern. Die Reihenfolge ist laut DigitalOcean entscheidend: Das Gateway ermittelt zuerst, welche Tools der Aufrufer nutzen darf, und die Suche ordnet dann Kandidaten aus dieser Menge. Ein Suchergebnis ist keine Erlaubnis zur Ausführung. action.invoke prüft zum Zeitpunkt des Aufrufs die aktuelle Richtlinie und Verbindung. Ändern sich Berechtigungen zwischen Suche und Aufruf, zählt die spätere Prüfung.

Dieselben Regeln gelten, egal ob die Anfrage von einem verwalteten Coding-Agenten kommt, von einer anderen Anwendung, die als MCP-Client angebunden ist, oder von einer Person, die in einer Konsole Tools und Verbindungen konfiguriert.

Richtlinien, Freigabe und Verbindungen

Schlägt ein Agent eine Aktion vor, authentifiziert sich die aufrufende Anwendung bei DigitalOcean, oder eine integrierte Laufzeitumgebung legt eine vertrauenswürdige Dienstidentität samt Kundenkontext vor. Das Gateway löst diese Identität und die Tool-Definition auf, bevor es irgendeine Zugangsberechtigung des Anbieters verwendet. Anschließend wertet es die Richtlinie für den konkreten Aufruf aus. Ein Team kann ein Tool erlauben, verbieten oder mit ask markieren, was bedeutet, dass ein Mensch zustimmen muss.

Ein abgelehnter Aufruf wird gestoppt. Ein Aufruf mit ask wartet auf eine Entscheidung über die Freigabeoberfläche der aufrufenden Anwendung. Laut DigitalOcean ist die Freigabe an Tool, Argumente und Verbindung gebunden, und diese werden beim Versand erneut geprüft. Eine verweigerte, abgelaufene oder nicht unterstützte Freigabe soll nicht automatisch zu einer Erlaubnis führen. Entwickler sollten vorab klären, ob die gewählte Integration eine ask-Entscheidung anzeigen kann, bevor sie sich auf einen freigabepflichtigen Workflow verlassen.

Der Beitrag unterscheidet außerdem zwischen Authentifizierung, die klärt, wer die Anfrage stellt, und Autorisierung, die klärt, ob dieser Aufrufer dieses Tool unter dieser Richtlinie ausführen darf. Ein gültiger API-Schlüssel ist kein Universalpass für jede Aktion eines Anbieters, und die Verbindung eines GitHub-Kontos bedeutet für sich genommen nicht, dass jeder Agent darin Issues anlegen darf. Die eigenen Berechtigungen des Anbieters gelten weiterhin.

Auch Verbindungen spielen eine Rolle. Ein Team kann ein schreibgeschütztes Konto für Untersuchungen und ein separates Konto mit Schreibrechten für ein Projekt haben. Da der Name des Anbieters allein nicht festlegt, welche Autorisierung gilt, muss ein Aufruf die vorgesehene Verbindung auflösen, und die Richtlinie wird auf diese tatsächliche Wahl angewendet. Ein einzelner globaler GitHub-Zugriffsschalter könne diese Unterscheidung laut Unternehmen nicht leisten.

Was das für Teams bedeutet, die Agenten entwickeln

Laut DigitalOcean ist das System so ausgelegt, dass Zugangsdaten der Anbieter außerhalb des Modellkontexts und des vom Modell geschriebenen Codes bleiben. Der genannte Vorteil für Teams, eine API mit Zugangsdaten hinter das Action Gateway zu legen, ist eine zentrale Stelle, an der entschieden wird, ob ein Agent sie aufrufen darf, und ein eigener Pfad für die Ausführung. Routineabfragen bleiben dadurch unkompliziert, während für Änderungen an einem externen System strengere Regeln gelten.

Der vorliegende Quelltext endet mitten in der Darstellung von Verbindungen und OAuth, weshalb Details zu diesem Teil des Designs hier nicht behandelt werden.