Was passiert
Tuskira hat mit AI Agent Gateway ein Open-Source-Projekt veröffentlicht, das eine Architektur-Schicht zwischen AI-Agenten und ihren Abhängigkeiten einzieht. Das Tool fungiert als Vermittler zwischen Agenten einerseits und den Services andererseits, die sie aufrufen – konkret MCP (Model Context Protocol) Tool Servers, die Verbindungen zu Plattformen wie GitHub und Jira bereitstellen, sowie den Model Providern, an die Prompts geleitet werden.
Der Kern des Problems, das AI Agent Gateway löst, liegt in der typischen Praxis bei Teams, die Claude Code, Cursor oder selbstentwickelte Agent-Bots einsetzen: Diese Tools benötigen Zugriff auf externe Services. Derzeit geschieht das meist dadurch, dass API-Keys und Credentials direkt in die Agenten-Konfigurationen eingebettet werden – eine Praxis, die zwei große Risiken mit sich bringt. Erstens werden sensible Credentials dann in Konfigurationsdateien gespeichert, die möglicherweise versioniert, geteilt oder unvorsichtig weitergegeben werden. Zweitens ist es schwierig, Berechtigungen zentral zu verwalten, zu rotieren oder zu widerrufen, wenn Keys überall verteilt sind.
AI Agent Gateway läuft vollständig in der eigenen Infrastruktur des Nutzers – es ist nicht erforderlich, ein Tuskira-Konto zu erstellen oder ein externes System zu verlassen. Das Gateway fungiert als Proxy: Agent-Konfigurationen enthalten keine echten Credentials mehr, sondern nur Referenzen zu den Geheimnissen, die das Gateway bereitstellt. Wenn ein Agent eine MCP-Verbindung herstellen oder einen Model Provider aufrufen muss, erfolgt die Anfrage über das Gateway, das die tatsächlichen Credentials einspritzt und damit abwickelt.
Dadurch erhalten Teams mehrere konkrete Vorteile: Credentials liegen zentral und sind nicht über Hunderte von Konfigurationsdateien verteilt. Berechtigungen lassen sich an einer Stelle ändern, ohne jeden einzelnen Agenten neu zu konfigurieren. Audit-Logs können zentral protokolliert werden, um nachzuvollziehen, welche Agenten auf welche Services zugegriffen haben. Und die Secrets selbst können mit bewährten Vault-Systemen oder anderen Secret-Management-Lösungen integriert werden.
Das Projekt ist als Open Source verfügbar, was bedeutet, dass Teams den Code einsehen, auditen und selbst erweitern können. Es gibt keine Lock-in-Abhängigkeit von Tuskira, und die Lösung lässt sich in bestehende Deployment-Infrastrukturen integrieren.
Einordnung
Der Hintergrund dieses Tools liegt in einer bekannten Best Practice der Sicherheit: das Prinzip der Least Privilege und die strikte Trennung von Code und Secrets. In der Cloud-Native-Infrastruktur ist es längst Standard, dass API-Keys nicht ins Quellcode-Repository gehören und dass Secret Management über dedizierte Systeme erfolgt – sei es HashiCorp Vault, AWS Secrets Manager oder ähnliche Lösungen.
Bei AI-Agenten und Automatisierungssystemen ist diese Disziplin bislang weniger verankert. Viele Teams improvisieren: Ein Agent braucht einen GitHub-Token, also wird er in die .env-Datei der Agenten-Umgebung geschrieben. Ein anderer braucht Jira-Credentials, also rein damit. Wenn mehrere Agenten auf die gleichen Services zugreifen sollen, wird die Datei kopiert und weitergegeben. Das ist schnell, aber nicht skalierbar und birgt erhebliche Sicherheitsrisiken – vor allem in größeren Organisationen, wo viele verschiedene Teams und Tools auf gemeinsame Services wie GitHub oder interne Systeme zugreifen.
AI Agent Gateway greift hier ein aktuelles Problem auf: Mit der wachsenden Adoption von Agenten – sowohl proprietäre wie Claude Code und Cursor als auch selbst entwickelte Bots – steigt die Komplexität des Berechtigungsmanagements. Jeder Agent, der hinzukommt, bringt zusätzliche Credentials mit sich. Teams, die bereits DevOps- oder Platform-Engineering-Teams haben, werden schnell feststellen, dass die IT-Sicherheit fragt, wie diese Geheimnisse verwaltbar bleiben.
Das Gateway setzt an dieser Stelle an: Es bringt Agent-Infrastruktur näher an etablierte Security-Praktiken heran. Es ermöglicht es, Agenten wie normale Anwendungen zu behandeln – nicht als schwarze Boxen, die eigene Sicherheitsregeln brauchten, sondern als Teile einer Security-Architektur, die zentralisiert kontrolliert wird. Für Organisationen, die bereits Secret-Management-Systeme haben, bedeutet das eine natürliche Integration ohne Bruch.
Was das bedeutet
Das konkrete Take-Away ist: AI Agent Gateway adressiert das Credentials-Management als Architektur-Problem, nicht als Config-Problem. Das ist wichtig, weil es einen konzeptionellen Unterschied macht. Wenn Credentials nur "besser" in Konfigurationsdateien organisiert werden, bleibt das grundsätzliche Risiko – jede Datei kann geleakt werden, jede muss bei Rotation aktualisiert werden. Ein Gateway dagegen zentralisiert die Credentials und macht sie für Agenten „unsichtbar".
Das wird relevanter, je mehr Agenten ein Team nutzt und je sensibler die Services sind, auf die sie zugreifen. Ein Startup mit einem einzelnen Cursor-Agent hat vielleicht kein großes Sicherheitsproblem. Ein Enterprise mit 50 verschiedenen Agenten, die auf Git-Repositories, CI/CD-Systeme und Datenbanken zugreifen, braucht genau diese Art von Kontrolle. AI Agent Gateway bietet dafür die technische Grundlage – dezentral betreibbar, open source und ohne Abhängigkeit von einem kommerziellen Anbieter.
Der langfristige Effekt könnte sein, dass Credential Management für Agenten zum Standard wird, ähnlich wie es heute für Microservices üblich ist. Teams, die jetzt die Gewohnheit aufbauen, Agenten über ein Gateway zu betreiben, bauen gleichzeitig Sicherheits-Kultur auf, die beim Skalieren nicht zusammenbricht.
