AI Agents in Production: Controls für sichere Agenten

AI Agents in Production: Controls für sichere Agenten

Praktische Checkliste für Observability, Evals, Guardrails, ITSM und Human-in-the-Loop.

Ein AI-Agent, der im Service-Desk Tickets klassifiziert, CMDB-Daten liest, eine Passwortzurücksetzung in Microsoft Entra ID vorbereitet und eine Antwort in Microsoft Teams entwirft, ist kein Chatbot mehr. Er nutzt Tools, verarbeitet interne Daten und stößt Workflows an. Damit verschiebt sich das Risiko von falschen Antworten zu falschen Aktionen: Ein plausibler Text ist weniger gefährlich als ein falsch ausgeführter API-Aufruf. Wenn Du diese Betriebsfragen vertiefen willst, ordnet die Schulung Agentic AI betreiben: Architektur. Sicherheit. Betrieb. Architektur, Sicherheit und Betrieb agentischer Systeme ein.

Agentic AI betrifft Plattform-Teams, Security-Teams, Service-Owner und Prozessverantwortliche. Die Kategorie KI-Agenten & Multi-Agent-Systeme bündelt technische Themen wie Tool-Calling, Multi-Agent-Kommunikation und Betriebsarchitekturen.

Warum AI Agents in Production mehr brauchen als einen Prompt

Ein Prompt beschreibt erwünschtes Verhalten, begrenzt aber keine API-Berechtigungen, erzwingt keine Freigabe für Löschaktionen und erzeugt keine forensisch brauchbaren Logs. Ein RAG-Assistent liefert Antworten aus einem Dokumentenindex. Ein AI-Agent ruft zusätzlich Tools auf, schreibt Datensätze, sendet Nachrichten, startet Jobs und entscheidet über mehrere Schritte hinweg, welches Tool als Nächstes verwendet wird.

Der Sicherheitsentwurf muss deshalb bei Befugnissen, Datenflüssen und Ausführungspfaden beginnen. Frameworks wie das NIST AI Risk Management Framework und OWASP-Empfehlungen für LLM-Anwendungen helfen als Prüfliste, ersetzen aber keine technischen Kontrollen an Identitäten, Tools, Logs und Freigaben.

Arbeite mit klaren Autonomie-Stufen: nur lesen und zusammenfassen, Änderungen als Entwurf anlegen, nach Freigabe ausführen oder reversible Standardaktionen selbst ausführen. Datenlöschung, Zahlung, IAM-Änderung, Firewall-Regel und Produktions-Deployment bleiben außerhalb vollautomatischer Ausführung, solange Risiko, Rollback und Verantwortlichkeit nicht eindeutig geregelt sind.

Definiere, was der Agent tun darf

Jede Agenten-Fähigkeit braucht einen dokumentierten Geschäftszweck, eine Datenquelle, ein Tool, eine Risikostufe, einen technischen Owner und eine Freigaberegel. Diese Zuordnung verhindert, dass ein Agent über ein generisches API-Token Zugriff auf Systeme erhält, die für seine Aufgabe irrelevant sind.

FähigkeitTool und DatenRisikoMindestkontrolle
Ticket triagierenITSM-API, Knowledge Base, CMDBMittelRead-only-Token, Trace-ID und keine Schreibrechte
Passwort-Reset vorbereitenMicrosoft-Entra-ID-API und IdentitätsdatenHochVier-Augen-Freigabe, kurzlebige Credentials und Audit-Log
Kunden-E-Mail sendenCRM, Mail-Gateway, VorlagenHochFreigabe-Queue, Vorlagenbindung und DLP-Prüfung
Kubernetes-Deployment ändernGit-Repository, CI/CD-Pipeline, Cluster-APISehr hochPull-Request, Tests, Change-Freigabe und Rollback-Plan

Least Privilege gilt auch für Agenten-Identitäten. Trenne Read-only-Zugriffe, Schreibaktionen, externe Kommunikation, finanzielle Aktionen und sicherheitsrelevante Aktionen. Verwende RBAC oder ABAC, scoped API-Tokens, kurzlebige Credentials aus HashiCorp Vault oder einem Cloud-Secret-Manager und einen benannten technischen Owner. Wenn der Agent im Namen eines Menschen handelt, protokollierst Du Benutzerrolle, Agenten-ID, Tool, Objekt-ID, Freigabe und Zeitpunkt als On-behalf-of-Nachweis.

Sichere Tool-Nutzung mit Allow-Lists, Validierung und Limits

AI agent guardrails beginnen an der Tool-Grenze, nicht erst im Sprachmodell. Ein Agent sollte keine beliebigen Tools entdecken oder dynamisch fremde Endpunkte aufrufen. Eine Allow-List legt fest, welche Funktionen der Agent mit welchen Parametern, Zielsystemen, Limits und Freigaben verwenden darf.

{
  "agent": "service-desk-triage",
  "allowed_tools": [
    { "name": "itsm.get_ticket", "mode": "read", "rate_limit_per_minute": 60 },
    { "name": "identity.prepare_password_reset", "mode": "write_pending_approval", "requires_approval": true }
  ],
  "blocked_actions": [ "delete_user", "export_customer_data", "send_payment" ],
  "max_calls_per_run": 8
}

Validiere Tool-Eingaben vor der Ausführung. JSON-Schema, Pydantic-Modelle, OPA/Rego-Policies, parametrisierte SQL-Abfragen, Pfad-Normalisierung und Allow-Lists für Zielsysteme prüfen Parameter, Objekt-IDs, Dateipfade, API-Payloads und Berechtigungen. Unbekannte Felder, freie SQL-Fragmente, absolute Dateipfade und nicht freigegebene Domains werden abgewiesen.

Validiere auch Tool-Ausgaben, bevor der Agent sie als Kontext für den nächsten Schritt nutzt. Entferne aktives HTML aus Tickets, maskiere Secrets, prüfe URLs gegen erlaubte Domains und behandle Inhalte aus Webseiten, SaaS-Antworten und Dokumenten als potenziell manipuliert. Diese Kontrolle reduziert Prompt Injection, vergiftete RAG-Dokumente und kompromittierte Tool-Antworten.

Ergänze Rate-Limits, Timeouts, Retry-Policies, Idempotency-Keys, Kostenlimits und Circuit-Breaker. Der Default ist Deny: unbekannte Tools, fehlende Freigaben, Policy-Konflikte und unerwartete Tool-Sequenzen stoppen den Agenten-Lauf und erzeugen ein Ereignis für Review oder Incident-Triage.

Baue AI agent observability für jeden Schritt auf

AI agent observability muss jeden relevanten Schritt rekonstruierbar machen. Logge strukturierte Ereignisse statt ungefilterter Volltexte: Benutzerabsicht, Agenten-Version, Modell-ID, Prompt-Version, Policy-Version, abgerufenen RAG-Kontext als Dokument-ID oder Hash, Tool-Aufruf, Parameterklasse, Tool-Antwortstatus, Policy-Entscheidung, Freigabe-ID und finale Ausgabe.

OpenTelemetry und W3C Trace Context eignen sich, um Agenten-Schritte mit API-Aufrufen, Datenbankabfragen, Queue-Jobs und CI/CD-Läufen zu verbinden. Ein Trace zeigt Tool-Sequenzen, Retries, Fallbacks, abgebrochene Schritte und Human-Approvals. Metriken erfassen Latenz, Kosten, Token-Nutzung, Tool-Fehlerrate, Policy-Verstöße, Eskalationsrate, Approval-Wartezeit und Anteil ungelöster Fälle.

Trenne sensible Inhalte von Audit-Metadaten. Speichere personenbezogene Daten, Secrets und vertrauliche Dokumentausschnitte nicht ungefiltert im zentralen Log. Ein Incident-Team benötigt für die erste Analyse meist Zeitstempel, Tool-Namen, Policy-Entscheidung, Rollen, Objekt-IDs und Hashes dringender als vollständige Prompts mit Kundendaten. Für technische Vertiefung zu Metriken, Logs und Traces passt die Kategorie Monitoring und Logging Schulungen.

Nutze Evals vor und nach dem Deployment

LLM evaluation in practice bedeutet, dass Du Agenten-Versionen gegen konkrete Aufgaben testest, bevor sie Benutzer-Tickets, Kunden-E-Mails oder Infrastrukturänderungen bearbeiten. Baue Offline-Eval-Sets aus typischen Tickets, Grenzfällen, negativen Beispielen, Prompt-Injection-Versuchen, fehlenden Daten, widersprüchlichen Policies und sicherheitsrelevanten Szenarien.

Jeder Eval-Fall enthält Eingabe, erwartete Tool-Sequenz, verbotene Aktionen, benötigte Evidenz, Akzeptanzkriterium und Abbruchbedingung. Kombiniere regelbasierte Checks, Golden-Datasets, Human-Review und LLM-as-a-judge mit fester Rubrik. Ein einzelner Score reicht nicht aus, weil ein Agent fachlich richtig antworten und trotzdem ein falsches Tool verwenden kann.

Führe Regression-Tests bei Prompt-Änderungen, Modell-Upgrades, RAG-Änderungen, neuen Tools und Policy-Updates aus. Online-Evals überwachen Produktionsqualität, Drift, ungelöste Fälle, Benutzerfeedback und riskantes Verhalten. Definiere Release-Schwellen: Eine Version wird ausgeliefert, blockiert oder zurückgerollt, wenn Fehlerrate, Policy-Verstöße, Eskalationsrate oder Kosten pro Aufgabe die intern vereinbarten Grenzen überschreiten. Die Schulung LLM-Evaluation: Evaluation. Praxis. Sicherheit behandelt Offline-Evals, Online-Evals, LLM-as-a-judge, Human-Review, Regressionstests, CI/CD-Integration und Qualitäts-Governance.

Für Governance kannst Du das NIST AI Risk Management Framework, das Generative-AI-Profil von NIST und interne Risiko-Policies kombinieren. Wichtig ist die Übersetzung in prüfbare Artefakte: Eval-Set, Policy-Datei, Freigabeprotokoll, Monitoring-Dashboard und Runbook.

Lege fest, wann Human-in-the-Loop Pflicht ist

Human-in-the-Loop ist Pflicht, wenn eine Aktion irreversibel, teuer, rechtlich relevant, sicherheitssensitiv oder kundenwirksam ist. Beispiele sind Datenlöschung, Zahlung, Vertragsänderung, Kundennachricht, IAM-Änderung, Firewall-Regel, Produktions-Deployment und Export personenbezogener Daten.

  • Eine Review-Queue sammelt Aktionen, die der Agent vorbereitet, aber nicht selbst ausführt.
  • Ein Vier-Augen-Prozess erzwingt eine zweite Freigabe für hohe Risikostufen.
  • Ein Decision-Template speichert Evidenz, empfohlene Aktion, Alternativen, Risiko, zuständige Rolle und Ablaufdatum der Freigabe.
  • Eine Stop-Regel beendet den Agenten-Lauf bei Unsicherheit, fehlenden Daten, Policy-Konflikt, verdächtiger Prompt Injection oder Tool-Fehler.
  • Ein Separation-of-Duties-Check verhindert, dass dieselbe Rolle Tool-Berechtigung, Freigabe und nachträgliche Kontrolle allein verantwortet.

Der Reviewer sollte nicht nur eine Modell-Empfehlung sehen, sondern die verwendete Evidenz, die geplante Tool-Aktion, betroffene Objekte, erwartete Nebenwirkungen und den Rollback-Pfad. Die Verantwortung bleibt bei der Rolle, die für Change, Security, Legal, Finance oder Kundenkommunikation zuständig ist.

Verbinde AI-Agenten mit ITSM, Security und DevOps

Produktions-Agenten sind digitale Services. Führe sie im ITSM als Service oder Configuration Item mit Service-Owner, SLA oder SLO, Monitoring, Runbook, Release-Management und Lifecycle-Management. ITSM-Prozesse müssen Incidents, Problem-Management, Change-Enablement, Release-Management und Service-Requests für Agenten abdecken. Für Teams, die Monitoring, Event-Management, Incident-Management und Service-Requests nach ITIL strukturieren, ist die Kategorie ITIL® 4 Seminare auf Deutsch thematisch passend.

Lege agentenspezifische Playbooks an: Prompt Injection, Datenabfluss, Tool-Misuse, fehlgeschlagene Automation, Rogue-Agent-Verhalten, Kostenanstieg und Credential-Missbrauch. CI/CD-Gates prüfen Eval-Ergebnisse, Security-Tests, Policy-Checks, Approval-Workflows und Rollback-Pläne, bevor eine Agenten-Version produktiv geht. Themen wie Pipeline-Gates, Plattform-Betrieb und Release-Kontrollen passen in die Kategorie DevOps & KI-Plattformbetrieb.

Nutze Incidents, Traces und Human-Reviews als Feedback-Quellen. Ein fehlgeschlagener Tool-Aufruf verbessert die Eingabevalidierung. Eine eskalierte Kundennachricht verbessert das Review-Template. Ein Prompt-Injection-Fund erweitert RAG-Filter, Content-Policies und Eval-Sets. Ein Kostenalarm führt zu engeren Tool-Limits oder zu einem günstigeren Fallback-Modell.

Praktische Production-Checkliste

Berechtigungen

Der Agent nutzt Least Privilege, scoped API-Tokens, kurzlebige Credentials und eine dokumentierte Agenten-Identität mit Owner.

Tool-Guardrails

Eine Allow-List begrenzt Tools, Parameter, Zielsysteme, Rate-Limits, Kosten und Freigabepflichten.

Evals

Offline-Evals, Online-Evals, Regressionstests und Human-Review definieren Release-Schwellen und Rollback-Auslöser.

Observability

Strukturierte Logs, Traces, Metriken und Audit-Metadaten rekonstruieren jeden Agenten-Schritt ohne unnötige Speicherung sensibler Inhalte.

Human-Approval

Irreversible, teure, rechtliche, sicherheitsrelevante und kundenwirksame Aktionen laufen durch Review-Queues und Vier-Augen-Freigaben.

Incident-Runbook

Ein Runbook beschreibt Kill-Switch, Token-Revoke, Tool-Deaktivierung, Kommunikationsweg, Forensik-Daten und Rollback.

Nimm eine Fähigkeit erst in AI Agents in Production auf, wenn Berechtigung, Tool-Policy, Eval, Observability, Approval-Pfad, Runbook und Rollback dokumentiert sind. agentic AI security ist dann keine Modell-Eigenschaft, sondern eine Betriebsarchitektur aus kontrollierten Identitäten, validierten Tools, messbarer Qualität, nachvollziehbaren Entscheidungen und sauberer Einbindung in ITSM-, Security- und DevOps-Prozesse.