Sicherheit von KI-Agenten: Zugriffe, Geheimnisse und Human-in-the-Loop
Ein KI-Agent kann im CRM suchen, E-Mails schreiben, Befehle ausloesen, Aufgaben aktualisieren und externe APIs aufrufen. Genau deshalb muss die Sicherheit von KI-Agenten vor dem Launch geplant werden und nicht erst nach dem ersten Vorfall. Die haeufigsten Probleme sind zu breite Zugriffsrechte, Geheimnisse in Prompts und Logs sowie fehlendes Human-in-the-Loop, wenn der Agent ohne Bestaetigung eines Menschen handeln darf.
- Zugriffe - der Agent sollte nur die Systeme und Felder sehen, die er wirklich braucht
- Geheimnisse - API-Schluessel, Tokens und Passwoerter gehoeren nicht in Prompts, git oder normale Logs
- Human-in-the-loop - kritische Aktionen sollten durch Menschen bestaetigt werden
- Grundprinzip - nicht maximale Rechte "fuer alle Faelle", sondern nur das notwendige Minimum
- Praktischer Effekt - weniger Risiko fuer Datenlecks, Fehlaktionen und teure Rollbacks
Warum KI-Agenten riskanter sind als ein normaler Bot
Ein normaler Chatbot beantwortet oft nur Fragen. Ein KI-Agent geht weiter: Er liest Dokumente, nutzt Tools, aendert Datenbankeintraege, erstellt Rechnungen, sendet Kundennachrichten und kann Code ausfuehren. Je mehr Autonomie er hat, desto teurer werden seine Fehler.
Typische Risiken:
- der Agent bekommt gleichzeitig Zugriff auf CRM, E-Mail, Wissensdatenbank und Zahlungen;
- personenbezogene Daten, Konditionen und interne Anweisungen landen in einem Kontext;
- ein Mitarbeiter fuegt "nur zum Testen" ein echtes Token in den System-Prompt ein;
- das Logging speichert komplette Eingaben inklusive Geheimnisse;
- der Agent sendet ohne Pruefung eine Nachricht, loescht einen Datensatz oder startet die falsche Aktion.
Fazit: Sicherheit bei Agenten bedeutet nicht nur, "das Modell zu schuetzen". Es geht um Zugriffssteuerung, Secret-Handling, Logging und Freigabeprozesse.
Zugriffe: Minimalrechte statt Vollzugriff
Der haeufigste Fehler ist ein Admin-Konto fuer den Agenten, weil "die Integration so schneller geht". Am Anfang bequem, in Produktion gefaehrlich.
So begrenzen Sie Zugriffe
- Rollen trennen - ein Support-Agent sollte keine Finanzberichte sehen, ein Analyse-Agent keine Kundennachrichten senden.
- Datenbereiche begrenzen - nicht das ganze CRM, sondern nur benoetigte Entitaeten, Felder und Projekte.
- Lesen und Schreiben trennen - zuerst read-only, Schreibrechte nur dort, wo sie wirklich noetig sind.
- Service-Accounts verwenden - keine persoenlichen Mitarbeiter-Logins.
- Regelmaessig pruefen - Berechtigungen muessen ueberarbeitet werden und duerfen nicht ewig bestehen bleiben.
| Ansatz | Was passiert | Risiko |
|---|---|---|
| Admin-Zugriff fuer den Agenten | Der Agent sieht und aendert alles | Maximaler Schaden bei Fehlern |
| Read-only fuer benoetigte Daten | Der Agent analysiert, ohne Prozesse zu beschaedigen | Geringeres Risiko, einfacheres Audit |
| Rolle + Scope + Freigabe | Der Agent ist begrenzt und schreibt nur nach Bestaetigung | Beste Balance aus Tempo und Kontrolle |
Wo Fehler besonders teuer sind
- CRM - Kontakte, Deals, Notizen, Telefonnummern, E-Mail;
- E-Mail und Messenger - Risiko externer Aussendungen;
- Dateispeicher - Vertraege, Berichte, personenbezogene Daten;
- Finanzsysteme - Rechnungen, Zahlungen, Erstattungen;
- Terminal-Tools - Befehle, Deployments, Migrationen, Datenloeschung.
Wenn ein Agent Zugriff auf fuenf Systeme braucht, sollte man meist fragen, ob es nicht besser mehrere Agenten mit enger Verantwortung sein sollten.
Geheimnisse: Wo Lecks meistens entstehen
Geheimnisse leaken selten durch einen "Super-Hack". Viel oefter legt man sie selbst an den falschen Ort:
- in
.env, das versehentlich in git landet; - in den System-Prompt aus Bequemlichkeit;
- in Screenshots, Tickets und Dokumente fuer Dienstleister;
- in Request- und Response-Logs;
- in Test-JSON-Dateien und Entwickler-Notebooks.
Grundregeln fuer Secrets
- Secrets in einem Secret Manager oder in geschuetzten Umgebungsvariablen speichern, nicht im Prompt.
- Tokens auf Tool-Ebene einbinden, nicht auf Modellebene.
- Sensible Felder in Logs maskieren - Schluessel, Passwoerter, Cookies, Kartennummern, Access Tokens.
- Dev, Stage und Prod trennen - unterschiedliche Schluessel, Scopes und Limits.
- Widerruf und Rotation vorbereiten - wenn ein Secret leakt, muss es schnell ersetzt werden koennen.
Gute Praxis: Das Modell weiss, dass es ein Tool wie create_invoice() oder search_crm() hat, sieht aber niemals den echten API-Schluessel dahinter.
Human-in-the-Loop: Wann ein Mensch bestaetigen sollte
Nicht jede Agentenaktion braucht manuelle Freigabe. Aber es gibt eine Klasse von Vorgängen, bei denen Human-in-the-loop mehr Geld spart, als sie Zeit kostet.
Freigaben lohnen sich fuer:
- Nachrichten an Kunden im Namen des Unternehmens;
- Preis-, Rabatt-, Vertrags- oder Statusaenderungen;
- Loeschen von Daten, Dateien und Datensaetzen;
- Serverbefehle und Deployments;
- jede Aktion mit rechtlichen oder finanziellen Folgen.
Praktische Kontrollmodi
| Modus | Funktionsweise | Wann geeignet |
|---|---|---|
| Voller Autopilot | Der Agent entscheidet und handelt allein | Nur fuer risikoarme interne Aufgaben |
| Draft Mode | Der Agent bereitet etwas vor, ein Mensch bestaetigt | Support, Vertrieb, Dokumente |
| Zweistufige Freigabe | Gefaehrliche Aktionen brauchen extra Approve | Geld, Produktion, Loeschung, Rechte |
Fuer die meisten SMBs ist es optimal, wenn der Agent Daten sammelt und Entwuerfe vorbereitet, waehrend ein Mensch den externen oder kritischen Schritt bestaetigt.
Logs, Audit und Vorfallanalyse
Wenn ein Agent einen Fehler macht, muss das Unternehmen verstehen:
- welche Eingabe er erhalten hat;
- welches Tool er aufgerufen hat;
- welche Daten das Tool zurueckgegeben hat;
- wer die Aktion bestaetigt hat oder warum sie automatisch lief;
- wie schnell sich das Ergebnis rueckgaengig machen laesst.
Deshalb sind sinnvoll:
- Logs der Tool-Aufrufe;
- Nutzer- und Sitzungs-IDs;
- Version des Prompts oder der Agentenkonfiguration;
- Nachweis der manuellen Bestaetigung;
- maskierte Fehlerlogs ohne offene Geheimnisse.
Wichtig: komplettes Logging ohne Maskierung wird selbst zur Leckquelle. Audit ist wichtig, aber nicht um den Preis von Passwoertern und Tokens im Klartext.
Eine sichere Architektur fuer KI-Agenten
Ein praktisches Minimum fuer viele Projekte:
- Separater Service-Account pro Agent oder Rolle.
- Schmale Tools mit begrenzten Rechten statt eines universellen "mach alles"-Tools.
- Secret Manager / env statt Schluessel im Prompt oder Repository.
- Approve-Schritt fuer externe, finanzielle und destruktive Aktionen.
- Logging und Monitoring mit Maskierung sensibler Daten.
- Schluesselrotation und Rechte-Review nach Plan.
Check vor dem Launch
- der Agent laeuft nicht als Admin, ausser wenn es wirklich noetig ist;
- im Repository liegen keine echten Tokens oder Passwoerter;
- Testdaten enthalten keine echten personenbezogenen Daten;
- kritische Aktionen laufen nicht ohne Bestaetigung;
- fuer jedes Tool ist klar, was es lesen und was es aendern darf;
- es gibt einen klaren Weg, den Agenten im Vorfall abzuschalten.
Hauefige Fehler bei der Einfuehrung
- Ein Agent fuer alles - Support, Finanzen und Admin zusammen.
- Secrets in Prompts - weil "Debugging so einfacher ist".
- Keine Read-only-Phase - der Agent darf sofort schreiben und loeschen.
- Kein Human-in-the-loop - bis der erste teure Fehler passiert.
- Kein Audit-Trail - nach einem Vorfall weiss niemand mehr, was passiert ist.
Je autonomer der Agent, desto mehr muss man wie ein Security Engineer denken und nicht nur wie ein LLM-Integrator.
Fazit
Die Sicherheit von KI-Agenten basiert vor allem auf drei Dingen: minimalen Zugriffsrechten, sauberem Secret-Handling und Human-in-the-loop fuer riskante Aktionen. Wenn Sie den Scope begrenzen, Schluessel vom Modell fernhalten, Freigaben einbauen und Auditierbarkeit sichern, beschleunigt KI das Team, statt eine neue Vorfallsflaeche zu schaffen.
Wenn Sie einen KI-Agenten fuer CRM, Support oder interne Prozesse planen - kontaktieren Sie uns.
Haeufig gestellte Fragen
Worin unterscheidet sich ein KI-Agent aus Sicherheits-Sicht von einem normalen Chatbot?
Ein KI-Agent antwortet meist nicht nur, sondern handelt auch. Er ruft Tools auf, liest Datenbanken, aendert Datensaetze, sendet E-Mails und startet Operationen. Deshalb geht es nicht nur um falsche Antworten, sondern um falsche Aktionen in echten Systemen.
Kann ein interner Agent Admin-Rechte bekommen?
In der Regel besser nicht. Interne Nutzung beseitigt nicht das Risiko von Fehlern, Lecks oder falschen Tool-Aufrufen. Auch intern sind ein eigener Service-Account, read-only wo moeglich und enge Schreibrechte sicherer.
Wo sollte man API-Schluessel fuer Agenten-Tools speichern?
In einem Secret Manager oder in geschuetzten Umgebungsvariablen. Nicht im System-Prompt, nicht in Markdown-Dokumenten, nicht im Quellcode und nicht in normalen Logs. Das Modell soll das Tool nutzen, waehrend der Schluessel ausserhalb des Modellkontexts eingebunden wird.
Braucht jede Agentenaktion Human-in-the-loop?
Nein. Suche, Entwuerfe, Klassifikation und sichere Analysen koennen oft automatisch laufen. Aber externe Nachrichten, Geldbewegungen, Datenloeschung, Statusaenderungen und Serverbefehle sollten ueber menschliche Bestaetigung laufen.
Was tun, wenn ein Secret bereits in einem Log oder Prompt aufgetaucht ist?
Als kompromittiert behandeln. Den Schluessel widerrufen oder rotieren, aus Logs und Repositories entfernen, angebundene Systeme pruefen und die eigentliche Ursache im Prompt-Template, Logger, Testfile oder Entwicklungsprozess beseitigen.