Umgang mit den Zugangsdaten von Agenten und Modellintegrationen

Vier Arten von Zugangsdaten in einem Agenten-Setup

• API-Schlüssel von Modellanbietern, die die Anwendung oder ein Gateway nutzt
• Zugangsdaten für Tools und MCP-Server: Servicekonten, API-Tokens, Datenbanknutzer
• OAuth-Tokens, die die Plattform für Nutzer speichert, die Zugriff delegiert haben
• Pipeline- und Workload-Identitäten, die Agenten starten, ausrollen oder Code pushen lassen

Jede Art hat einen anderen Lebenszyklus. Erfassen Sie daher alle Zugangsdaten in einem Verzeichnis mit Zweck, Verantwortlichen, Umfang, Ablageort und Rotationsweg. Das OWASP Secrets Management Cheat Sheet empfiehlt genau solche Metadaten, einschließlich Ansprechpartner und Rotationszeitpunkt, damit sich ein Secret ohne Detektivarbeit verschieben oder ersetzen lässt.

Wo Zugangsdaten liegen sollten und wo nie

OWASP empfiehlt ein zentrales System zur Verwaltung von Secrets mit Zugriff nach dem Prinzip minimaler Rechte, automatischer Rotation und, wo möglich, dynamischen Secrets mit kurzer Laufzeit. Für Pipelines dokumentiert GitHub OpenID Connect als Weg, über den Workflows kurzlebige Cloud-Tokens für einen einzelnen Job erhalten, statt langlebige Cloud-Zugangsdaten als Repository-Secrets zu speichern. Bei Agenten sollte das Tool oder der MCP-Server die Zugangsdaten genau dann abrufen, wenn ein Aufruf sie braucht, sodass das Modell nur die Aktion und ihr Ergebnis sieht. Zugangsdaten gehören nie in:

• Prompts, Systemanweisungen oder Anweisungsdateien für Agenten in einem Repository
• Tool-Ergebnisse, die an das Modell zurückgehen
• Traces und Logs, denn die MCP-Autorisierungsspezifikation stuft auf einem Server zwischengespeicherte oder protokollierte Tokens als Diebstahlrisiko ein
• Umgebungsvariablen einer Agentensitzung, die Shell-Befehle ausführen kann, es sei denn, das Token ist kurzlebig und eng begrenzt

Eine Identität je Agent, Umgebung und Zweck

Gemeinsame Zugangsdaten machen jeden Vorfall zu einem globalen und jede Logzeile zu einer Vermutung. OWASP weist darauf hin, dass sich die Quelle eines Leaks schwer finden lässt, wenn Dienste dieselben Secrets teilen. Geben Sie jedem Agenten in jeder Umgebung eine eigene Identität und trennen Sie lesende von schreibenden Zugangsdaten, wo das Zielsystem es zulässt. Ein MCP-Server, der Upstream-APIs aufruft, nutzt dafür eigene Zugangsdaten, denn die Spezifikation verbietet, das Token eines Clients durchzureichen. Für Verbindungen zwischen Maschinen zu einem MCP-Server empfiehlt die offizielle Client-Credentials-Erweiterung signierte JWT-Assertions statt langlebiger Client Secrets.

Rotieren, ohne laufende Abläufe zu brechen

Der folgende Ablauf setzt voraus, dass das Zielsystem zwei gültige Zugangsdaten gleichzeitig akzeptiert. Lässt es nur eine zu, planen Sie einen koordinierten Wechsel mit pausierten Nutzern oder wechseln zwischen zwei Identitäten ab, sofern das System das unterstützt.

1. 1

   Neue Zugangsdaten neben den alten anlegen

   Beide bleiben für ein Überlappungsfenster gültig, mit gleichem oder engerem Umfang.

2. 2

   Die neuen Zugangsdaten testen, bevor sie aktiv werden

   Das Rotationsbeispiel von OWASP für AWS Secrets Manager testet die ausstehenden Zugangsdaten, bevor sie zu den aktuellen werden.

3. 3

   Nutzer umstellen lassen

   Abläufe holen Zugangsdaten je Lauf oder Aufruf, nicht einmal beim Start, und ein langer Lauf versucht es bei einem Authentifizierungsfehler einmal erneut, bevor er eindeutig scheitert.

4. 4

   Nutzung der alten Zugangsdaten beobachten

   Audit-Logs zeigen, welche Nutzer sie noch verwenden.

5. 5

   Alte Zugangsdaten widerrufen und das Scheitern prüfen

   Eine Testanfrage mit den alten Zugangsdaten sollte jetzt abgelehnt werden.

Ein hypothetischer Ausfall zeigt, warum die Überlappung zählt. Ein Agentenlauf dauert bis zu zwei Stunden und liest beim Start ein Datenbankpasswort. Die Rotation widerruft das alte Passwort dreißig Minuten nach Ausgabe des neuen, also scheitern früher gestartete Läufe auf halber Strecke. Holen Sie Zugangsdaten entweder je Schritt oder machen Sie die Überlappung länger als den längsten Lauf, und halten Sie diese Dauer in der Rotationsrichtlinie fest.

Wenn Zugangsdaten geleakt sind

Laut OWASP wird ein offengelegtes Secret sofort widerrufen, über einen wiederholbaren automatisierten Prozess rotiert, aus Code und Logs entfernt, und Aufzeichnungen zum Lebenszyklus zeigen, wer Zugriff hatte, wann es genutzt und wann es zuletzt rotiert wurde. Agenten bringen zwei weitere Prüfungen mit. Stellen Sie fest, ob die Zugangsdaten über einen Prompt oder ein Tool-Ergebnis zu einem Modellanbieter gelangt sind, denn dort können sie je nach Bedingungen des Anbieters und Ihrer Konfiguration aufbewahrt werden. Prüfen Sie danach alles, was der Agent seit Beginn der Offenlegung mit diesen Zugangsdaten getan hat. OWASP rät außerdem zu getesteten Notfallzugängen in einem separaten System, falls der Secrets Manager selbst ausfällt.

Ein praktischer nächster Schritt: Erstellen Sie das Verzeichnis für einen Agenten und markieren Sie alle Zugangsdaten, die langlebig, geteilt oder für das Modell lesbar sind.

Sicherheit von Coding-Agenten in Engineering-TeamsKI-Engineering und -Architektur