Stell dir vor, du hast einen persönlichen Assistenten, der für dich Termine plant, Einkäufe erledigt und E-Mails schreibt. Damit er das kann, braucht er Zugang zu deinem Kalender, deinem Bankkonto, deinen Kontakten. Und wehe, er muss für jede Aufgabe einen anderen Schlüssel finden. Genau vor diesem Problem stehen Unternehmen, wenn sie KI-Agenten in ihre Arbeitsabläufe integrieren. Es geht nicht um einen einzelnen Schlüssel, sondern um dutzende Türen. DoorDash hat dafür ein zentrales Tor gebaut: ein Agent Gateway.
In einem technischen Blogbeitrag beschreiben die Software-Engineers Siddarth Kodwani und Vasily Vlasov, wie dieses Gateway die Art und Weise verändert, wie KI-Agenten auf interne und externe Werkzeuge zugreifen. Das Besondere daran ist nicht die Erfindung eines neuen Protokolls, sondern eine klare Plattform, die die vielen Einzelprobleme der Tool-Anbindung löst. Es geht um Zugriff, Sichtbarkeit und Kontrolle – und das, ohne dass jede Anwendung das Rad neu erfinden muss.
Vom Protokoll zum Produktionsproblem
KI-Agenten werden wirklich nützlich, wenn sie Aktionen in echten Systemen ausführen können. Bei DoorDash heißt das: interne APIs, Engineering-Systeme, Observability-Plattformen, Ticketing-Systeme, Wissensdatenbanken und externe SaaS-Produkte. Das Model Context Protocol, kurz MCP, hat dabei geholfen, diese Werkzeuge einheitlich zu beschreiben, zu entdecken und aufzurufen. Es ist sozusagen die gemeinsame Sprache zwischen Agenten und Servern.
Aber wie so oft im Leben: Die Sprache allein löst nicht das Problem, was man tun darf. MCP standardisiert die Form eines Tool-Aufrufs, aber es beantwortet nicht die kritischen Produktionsfragen: Welcher Agent darf dieses Tool überhaupt aufrufen? Für welchen Benutzer, welches Team oder welchen Dienst handelt er? Welches Zugangsdatum soll verwendet werden? Welche Teilmenge der Werkzeuge soll der Agent sehen? Wie entzieht man Zugriff wieder? Und was passiert nach dem Aufruf? Das sind Fragen, die in der Praxis schnell an Bedeutung gewinnen.
Der Artikel macht das an einem Beispiel deutlich: Ein Coding-Agent braucht Zugriff auf GitHub, Jira, Code-Suche, CI, Observability und Doku. Ein externer MCP-Server kann hunderte Tools bereitstellen, obwohl der Arbeitsablauf nur fünf braucht. Ein Benutzer-Agent braucht OAuth-Zustimmung des Nutzers, während Team-Automatisierung mit einem Dienstkonto arbeitet. Wenn jedes Team diese Probleme separat löst, entsteht ein Flickenteppich aus Auth-Code, OAuth-Flüssen, Geheimnis-Verwaltung, Tool-Katalogen, Rate-Limits und Logs. Genau hier setzt das Agent Gateway an.
Ein Tor, viele Regeln
Das Gateway ist ein einziger, kontrollierter Einstiegspunkt, über den Agenten Werkzeuge entdecken und aufrufen. Es authentifiziert den Aufrufer, prüft die Autorisierung, zeigt nur die genehmigte Tool-Oberfläche, spritzt die richtigen Anmeldedaten, leitet an den passenden MCP-Server weiter und protokolliert jeden Aufruf strukturiert. Der Blog betont: Das Gateway ist kein einfacher Proxy, sondern die Kontrollebene für das gesamte Agenten-Ökosystem. Es verwaltet, wer Tools aufrufen darf, kuratiert die Tool-Listen, bündelt Werkzeuge nach Aufgaben und bietet DoorDash einen zentralen Ort für Beobachtung, Rate-Limits, Zugriffsentzug und Verbesserung.
Die Architektur besteht aus zwei zentralen Teilen: einem Proxy und einem Registry. Der Proxy bildet die Datenebene. Er empfängt jede MCP-Anfrage, authentifiziert, autorisiert, begrenzt die Rate, spritzt Anmeldedaten, leitet weiter und sendet Observability-Daten. Die Registry ist die Quelle der Wahrheit in der Kontrollebene. Sie speichert Agenten, MCP-Server, Verantwortliche, Transport-Konfigurationen, Auth-Modi, Richtlinien, entdeckte Tool-Kataloge und Tool-Oberflächen-Konfigurationen.
Diese Trennung bringt Eigenschaften, die mit Punkt-zu-Punkt-Integrationen kaum zu erreichen sind. Agenten nutzen einen konsistenten MCP-Endpunkt statt die Auth- und Routing-Modelle jedes Servers zu lernen. Tool-Anbieter registrieren ihre Fähigkeiten einmal, hinterlegen Ownership und Richtlinien und sehen die Nutzung in Produktion. Security-Teams haben einen Ort, um Zugriff zu erzwingen, Berechtigungen zu entziehen und Prüfungen durchzuführen. Und die Plattform-Teams können den gemeinsamen Pfad einmal verbessern, und alle Agenten profitieren davon.
Identität, Autorisierung und Geheimnisse unter einem Dach
Jede Gateway-Anfrage löst eine Identität auf: einen Benutzer, einen Dienst oder einen Agenten, der im Namen eines Benutzers handelt. Diese Identität wird durch Autorisierung, Credential-Injektion, Routing und Beobachtung getragen, sodass jede Aktion zugeordnet werden kann. Die Autorisierung fragt nicht nur, ob der Aufrufer Zugriff auf den Server hat, sondern auch, ob dieser Agent diesen Server nutzen darf, ob dieser Benutzer dieses Tool über diesen Agenten verwenden darf, ob das Tool in dieser Umgebung überhaupt sichtbar ist und ob eine schreibende oder nur lesende Variante möglich ist.
Weil die Richtlinie im Gateway lebt, gibt es einen einzigen Ort, um Zugriff zu ändern oder zu entziehen. Tool-Besitzer müssen nicht für jeden Server eine eigene Autorisierung aufbauen, und Agent-Entwickler müssen keine Sicherheitsentscheidungen in Prompts oder Code einbauen. Das Credential-Handling folgt demselben Muster. Es gibt verschiedene Auth-Modi: interne Service-Identitäten, Gateway-gespeicherte Tokens, nutzerbezogenes OAuth und Service-Prinzipale. In allen Fällen gilt ein Prinzip: Agenten sollen keine rohen Anmeldedaten in den Händen halten, weder API-Keys noch OAuth-Refresh-Tokens noch geliehene menschliche Berechtigungen. Das Gateway hält diese Grenzen explizit und prüfbar.
Besonders spannend ist die Behandlung von per-user OAuth. Nutzerbezogene Drittanbieter-Tools brauchen die Zustimmung des Benutzers. Wenn ein Agent im Namen eines Nutzers Dokumente liest oder Tickets anlegt, darf er nicht einfach einen geteilten Schlüssel verwenden. Früher baute jedes Team seinen eigenen OAuth-Fluss, seine eigene Token-Speicherung und seine eigene „Verbinde dich zuerst“-Erfahrung. Das Gateway zentralisiert die OAuth-Zustimmung und speichert die Tokens verschlüsselt. Die Zugriffseinheit ist auf Agent, Benutzer und Server bezogen.
Bei der ersten Anfrage, die eine Autorisierung braucht, startet das Gateway den OAuth-Fluss des Anbieters und speichert das Ergebnis. Der Agent sieht das Token nie. Für Clients, die MCP-Elicitation unterstützen, kann das Gateway die Tool-Ausführung unterbrechen, den Client bitten, einen Verbindungsbildschirm zu zeigen, und nach der Zustimmung den ursprünglichen Aufruf fortsetzen. Für Clients ohne Unterstützung gibt es eine strukturierte Antwort mit einer Verbindungs-URL. Das macht aus einem gescheiterten Durchlauf einen behebbaren Teil des Tool-Aufrufs. Genau so soll Software sich anfühlen: Wenn etwas fehlt, bricht es nicht ab, sondern zeigt den Weg.
Kuratierte Werkzeuglandschaften statt Tool-Wildwuchs
Agenten denken nicht in MCP-Servern. Sie denken in Aufgaben. Ein Coding-Agent will nicht GitHub, Jira, Observability und Doku als separate Setup-Schritte behandeln. Er will die Werkzeuge, die er braucht, um ein Problem zu untersuchen, Code zu ändern, einen Pull-Request zu öffnen, die CI zu prüfen und das Produktionsverhalten zu verstehen. Gleichzeitig bieten viele MCP-Server weit mehr Werkzeuge an, als ein einzelner Agent nutzen sollte. Manche Drittanbieter-Server veröffentlichen hunderte Operationen, darunter Admin-Aktionen, destruktive Befehle, Billing-APIs und spezielle Nischenfunktionen. Die meisten Arbeitsabläufe benötigen nur einen kleinen Teil davon.
Das Gateway löst dieses Problem mit kuratierten Tool-Surfaces. Bundles kombinieren Werkzeuge aus mehreren MCP-Servern zu einem logischen Endpunkt. Filter entscheiden, welche Werkzeuge aus jedem Server für ein bestimmtes Bundle, einen Agenten, eine Benutzergruppe, eine Umgebung oder eine Zielgruppe sichtbar sind. Ein Entwickler-Tools-Bundle kann etwa ausgewählte GitHub-Werkzeuge, Jira-Werkzeuge, Observability-Werkzeuge, Code-Suche- und Doku-Werkzeuge sowie Feature-Flag-Werkzeuge enthalten.
Der Agent verbindet sich mit einer einzigen Gateway-URL. Dahinter führt das Gateway die Tool-Listen über die Server im Bundle zusammen, wendet Filter an, passt Namen und Beschreibungen an, wo nötig, und liefert einen zusammenhängenden Katalog. Bei jedem Tool-Aufruf wird die Richtlinie erneut geprüft, die Anfrage an den richtigen Server geroutet und das jeweilige Credential verwendet. Der Vorteil ist ein Produkterlebnis für den Agenten: eine bewusste Auswahl an Werkzeugen mit stabilen Namen, klaren Beschreibungen, Ownership-Metadaten und zielgruppenspezifischen Bundles. Technik-, Datenanalyse-, Support- und externe Anwendungsfälle können dieselben Gateway-Primitive nutzen, aber unterschiedliche Oberflächen bekommen.
Das klingt vielleicht trivial, ist es aber nicht. Eine kuratierte Tool-Surface kann den Unterschied ausmachen zwischen einem Agenten, der das richtige Werkzeug findet, und einem, der in einem riesigen API-Katalog umherirrt. Genau hier zeigt sich, warum das Gateway mehr ist als ein Access-Proxy. Es prägt, was Agenten entdecken können, was sie aufrufen dürfen und wie viel irrelevanter Kontext sie mit sich herumtragen. Für KI-Einsteiger ist das eine wichtige Lektion: Was ist KI also wirklich? Ein nützliches System, das aber klare Grenzen braucht, um nicht in Beliebigkeit zu versinken.
Beobachtbarkeit, Kosten und Schutz
Weil jeder Aufruf durch das Gateway läuft, kann jede Anfrage ein strukturiertes Ereignis auslösen: Server, Tool, Bundle und verantwortliches Team; Benutzer, Agent, Dienst und Plattform; Autorisierungsergebnis, Statuscode, Fehlerquelle und Latenzaufschlüsselung; Anfrage- und Antwortgröße; und gegebenenfalls vom System gemeldete Kostenmetadaten. Das Gateway erzeugt auch Metriken für Anfragevolumen, Latenz pro Tool, Autorisierungsentscheidungen, OAuth-Ergebnisse, Rate-Limit-Entscheidungen, Streaming-Verbindungen und Upstream-Fehler. Trace-Propagation erlaubt es, einen Aufruf vom Agenten durch das Gateway bis zum Server zu verfolgen.
Der operative Wert ist direkt spürbar: Die Sicherheit kann Zugriffe auditieren, Plattform-Teams finden laute Agenten, Tool-Besitzer sehen Einführung und Fehler, und die Infrastruktur kann Kosten zuordnen. Gleichzeitig schützt das Gateway nachgelagerte Systeme vor Überlastung. Rate-Limits lassen sich pro Server, Tool, Aufrufer, Benutzer, Bundle oder Aufrufertyp konfigurieren. Neue Limits können zuerst im Schattenmodus laufen, also nur beobachten, was sie abgelehnt hätten, ohne den Produktionsbetrieb zu beeinträchtigen. Das Gateway verwandelt Governance in Daten, statt sich darauf zu verlassen, dass jedes Team die richtigen Felder protokolliert und die richtigen Limits erzwingt.
Selbstbedienung ist der Schlüssel
Ein Gateway funktioniert nur, wenn die Teams es gern nutzen, statt es zu umgehen. Deshalb setzt DoorDash auf Self-Service. Registrierung, Entdeckung, Filterung und Bundle-Verwaltung laufen über eine Control-Plane-Oberfläche und API. Teams können selbst ihre MCP-Server und Agenten registrieren, Authentifizierung konfigurieren, Tools entdecken, Verantwortlichkeiten hinterlegen, Filter definieren, Tools in Bundles aufnehmen und den Produktionseinsatz verfolgen.
Der Onboarding-Prozess folgt klaren Schritten: Zuerst den MCP-Server registrieren, dann den rohen Tool-Katalog per tools/list entdecken. Danach werden die Werkzeuge ausgewählt und freigegeben, die DoorDash wirklich nutzen will. Im nächsten Schritt werden Auth-Modus, Ownership und Richtlinien zugewiesen. Schließlich kommen die freigegebenen Tools in ein Bundle – und fertig. So bekommt ein Agent einen eigenen, sauberen Zugang, ohne hinter den Kulissen ein eigenes Sicherheits- und Verwaltungssystem aufzubauen.
Das alles klingt nach einem klassischen Plattform-Thema. Und doch steckt eine größere Idee dahinter: Wenn KI-Agenten ernsthaft in Unternehmen ankommen sollen, brauchen sie eine Infrastruktur, die Skalierung, Sicherheit und Vertrauen ermöglicht. Das Gateway von DoorDash ist ein gutes Beispiel dafür, wie so etwas aussehen kann. Es ist kein Hype, sondern eine handfeste Ingenieurslösung für ein Problem, das jede Organisation treffen wird, die Agenten jenseits von Spielereien einsetzen will.
Für alle, die sich fragen, was KI-Anwendungen in der Praxis wirklich brauchen, liefert dieser Beitrag eine klare Antwort: nicht nur schlauere Modelle, sondern bessere Zugriffswege. Das Wichtigste ist die Einsicht, dass Technologie allein nicht reicht. Es braucht Governance, gute Gliederung und die Bereitschaft, den gemeinsamen Pfad zu bauen. Dann können KI-Agenten zu dem werden, was sie versprechen: nützliche Kollegen, die uns Arbeit abnehmen – ohne dass wir uns Sorgen um die Schlüssel machen müssen.
Quelle: careersatdoordash.com
