KI-Agenten absichern: eigene Identität statt persönlicher Schlüssel

Geben Sie jedem KI-Agenten eine eigene Identität und nur die Rechte, die sein Auftrag erfordert. Persönliche Schlüssel von Mitarbeitenden gehören nicht in Agentenprozesse: Die OWASP-Leitlinie für Agenten und MCP empfiehlt Dienstidentitäten, kurzlebige aufgabenbezogene Tokens sowie getrennte Identitäten für Lese- und Schreibzugriffe.

Entscheidend ist, wo diese Grenzen greifen. Der Dienst, der einen Werkzeugaufruf ausführt, oder eine vorgeschaltete Richtlinienprüfung muss Identität, Aktion und Ziel prüfen. Ergänzen Sie Freigaben vor schwer rückgängig zu machenden Aktionen, begrenzen Sie ausgehende Verbindungen und speichern Sie Protokolle außerhalb der Kontrolle des Agenten. Eine Anweisung im Prompt kann diese technischen Kontrollen nicht ersetzen.

Identität und Werkzeugrechte festlegen

Registrieren Sie für jeden Agententyp eine eigene Dienstidentität, etwa ein Dienstkonto oder für Repository-Zugriffe eine GitHub App. Ordnen Sie ihr einen verantwortlichen Betreiber, erlaubte Aufgaben und erreichbare Ressourcen zu. Handelt der Agent für eine Person, muss die Autorisierung auch erkennen lassen, wer den Auftrag erteilt hat. So lässt sich die Agentenberechtigung entziehen, ohne das persönliche Konto der beauftragenden Person zu sperren.

Das NIST-Konzeptpapier zur Agentenidentität behandelt dynamische Autorisierung, minimale Rechte, Delegation und überprüfbare Aktionsprotokolle als offene Kontrollfragen. Es ist ein Entwurf, keine fertige Rollenrichtlinie. Die konkrete Verteilung von Rechten hängt deshalb von den Werkzeugen, Daten und Folgen einer Aktion in der eigenen Umgebung ab.

Beginnen Sie mit einer Grundregel, die Zugriffe verweigert, solange sie nicht ausdrücklich erlaubt sind. Beschreiben Sie pro Werkzeug die zulässige Aktion, die betroffene Ressource und gegebenenfalls erlaubte Argumente. Leserechte für ein Ticketsystem umfassen beispielsweise weder den Versand einer Antwort noch eine Statusänderung. Prüfen Sie bei einem angebundenen MCP-Server auch dessen eigene Rechte: Ein eng konfigurierter Agent hilft wenig, wenn der Server mit weitreichenden Zugangsdaten arbeitet.

Beispielmatrix für Recherche, Support und Code

Die NIST-Einordnung von Werkzeugzugriffen unterscheidet Lesen, begrenztes Schreiben und Schreiben sowie vertrauenswürdige und nicht vertrauenswürdige Umgebungen. Für eine nutzbare Berechtigungsmatrix müssen zusätzlich Netzwerkziele, Geheimnisse, Freigaben und Protokolle feststehen. Die folgenden Rollen und Laufzeiten sind ausdrücklich Konfigurationsbeispiele, keine von NIST oder OWASP vorgegebenen Grenzwerte.

Recherche-Agent: Lesen darf er aus einer freigegebenen Wissensbasis und von benötigten öffentlichen Quellen. Schreiben darf er nur einen Entwurf im eigenen Arbeitsbereich; die Wissensbasis bleibt unverändert. Das Netz ist auf festgelegte Such- und Quellendienste begrenzt. Für die Wissensbasis erhält er ein ausschließlich lesendes, auftragsbezogenes Token, beispielsweise mit höchstens 30 Minuten Laufzeit. Veröffentlichung oder Versand brauchen eine Freigabe. Das Protokoll erfasst Werkzeugaufrufe, gelesene interne Ressourcen, erreichte Dienste und die freigegebene Fassung.
Support-Agent: Lesen darf er das zugewiesene Ticket und die dafür nötigen Kundendaten. Schreiben darf er einen Antwortentwurf und gegebenenfalls eine interne Notiz zum selben Ticket; Versand und Statusänderung sind eigene Aktionen. Er erreicht nur Ticket- und freigegebene Versanddienste. Lese- und Schreib-Tokens gelten für den jeweiligen Vorgang und laufen im Beispiel spätestens nach 30 Minuten ab. Externe Nachrichten, Löschungen, Erstattungen und Änderungen von Kundendaten erfordern eine Freigabe. Das Protokoll hält Ticketkennung, Aktion, Entscheidung und Ergebnis fest, aber keine geheimen Tokenwerte.
Coding-Agent: Lesen darf er das zugewiesene Repository ohne Geheimnisdateien. Änderungen bleiben auf einen Arbeitszweig beschränkt; geschützte Zweige und Deployment sind gesondert abgesichert. Netzwerkzugriffe gelten nur für geprüfte Paketquellen und benötigte Dienste. Ein begrenztes Repository-Token läuft im Beispiel nach höchstens 15 Minuten ab; Produktionszugänge bleiben außerhalb der Agentenumgebung. Push in geschützte Bereiche, Zusammenführung, Deployment und neue Netzwerkziele brauchen eine Freigabe. Das Protokoll erfasst Befehle, Änderungen als Diff, Netzwerkanfragen und die freigebende Person.

Die Laufzeit allein macht ein Token nicht sicher: Sein Geltungsbereich muss ebenso eng sein. Dauert ein Auftrag länger, kann ein neues Token nach erneuter Prüfung von Identität und Aufgabe ausgestellt werden. Ein beendeter oder entzogener Auftrag darf keine weiter nutzbare Berechtigung zurücklassen.

Freigaben an die tatsächliche Aktion binden

Eine Freigabe gehört unmittelbar vor die Aktion, die Wirkung entfaltet. Bei einer Support-Nachricht sollte die prüfende Person Empfänger und endgültigen Text sehen, bei Codeänderungen den Zielzweig, den Diff und den auszuführenden Befehl. Die Zustimmung gilt nur für diese Aktion. Ändern sich Ziel oder Argumente, ist eine neue Entscheidung erforderlich.

Der Agent kann nach einem freigegebenen Plan noch Inhalte aus Webseiten, Tickets oder Werkzeugantworten aufnehmen, die seine nächsten Schritte beeinflussen. Prüfen Sie deshalb beim tatsächlichen Aufruf erneut, ob Identität, Ressource und Aktion zusammenpassen. Für irreversible Schritte darf sich der Agent die nötige Freigabe weder selbst erteilen noch aus einer früheren allgemeinen Zustimmung ableiten.

Netz, Geheimnisse und Delegation begrenzen

Ein Agent mit Zugriff auf vertrauliche Daten und beliebige Internetziele kann Informationen nach außen übertragen. Lassen Sie ausgehende Verbindungen nur zu Zielen zu, die seine Rolle benötigt. Ein neuer MCP-Server, eine neue Domain oder ein geänderter Startbefehl sollte erst nach Prüfung zugelassen werden. Bei Coding-Agenten sind außerdem Dateisystem und Befehlsausführung zu begrenzen; eine Netzregel allein erfasst nicht jede Werkzeugfunktion.

Stellen Sie Zugangsdaten möglichst erst für den einzelnen Auftrag aus. Langlebige oder produktive Schlüssel sollten weder in Prompts und Konfigurationsdateien noch in der für den Agenten lesbaren Prozessumgebung liegen. Wenn der Agent einen weiteren Dienst beauftragt, erhält dieser eine eigene Berechtigung für seine Teilaufgabe. Das ursprüngliche Token ungeprüft weiterzureichen würde dem nachgelagerten Dienst möglicherweise mehr Zugriff geben, als er benötigt.

Aktionen nachvollziehen und Rechte entziehen

Ein brauchbares Protokoll verbindet Agentenidentität, beauftragende Person, Sitzung, Werkzeug, Ziel, Berechtigungsentscheidung und Ergebnis. Bei Schreibaktionen gehören die geänderte Ressource oder ein Diff dazu. Senden Sie die Einträge an ein zentrales System, in dem der Agent sie weder ändern noch löschen kann. Geheime Werte und für die Nachvollziehbarkeit unnötige personenbezogene Inhalte gehören nicht hinein.

Zur Konfiguration gehört auch ein wirksamer Entzug: Das Team muss die Agentenidentität sperren, aktive Tokens widerrufen und Schreib- oder Netzzugriffe gezielt abschalten können. Alarme für Zugriffe auf Geheimnisdateien, ungewöhnlich umfangreiche Lesevorgänge oder neue Netzwerkziele geben Anlass zur Prüfung. Nach einer Sperre zeigen die getrennt gespeicherten Protokolle, welche Aktionen tatsächlich ausgeführt wurden und welche Änderungen überprüft werden müssen.

Lesen Sie auch: