Sie haben AI-Agenten im Produktivbetrieb, oder Sie stehen kurz davor. Das Modell funktioniert. Das Tooling ist solide. Die Demos laufen sauber.
Was weniger sauber ist: die Governance-Schicht. Bevor Ihre Agenten produktive Systeme berühren, hier die Checkliste, die sicherheitsbewusste Teams durchgehen sollten — bevor ein Vorfall die Diskussion erzwingt.
1. Hat jeder Agent eine definierte Identität?
Ein Agent, der anonym läuft, ist ein Agent, den Sie nicht auditieren können. Im Produktivbetrieb muss jeder Agent über eine registrierte Identität mit einem klaren Vertrauensniveau verfügen.
Das bedeutet:
- Eine eindeutige Agenten-Kennung, kein gemeinsam genutztes Dienstkonto
- Eine explizite Vertrauensstufe (z. B. nur lesend, schreibbeschränkt, schreibfreigegeben)
- Eine Aufzeichnung dessen, was dieser Agent tun darf — und was nicht
Wenn Ihre Agenten sich Anmeldedaten mit anderen Systemen teilen oder unter einem Sammel-API-Schlüssel laufen, ist dies das Erste, was behoben werden muss.
Was zu prüfen ist: Können Sie eine Liste aller aktuell in Ihrer Umgebung laufenden Agenten, ihrer Vertrauensniveaus und ihrer zulässigen Tool-Kategorien erstellen?
2. Haben Sie jedes Tool inventarisiert, das der Agent aufrufen kann?
Agenten sind nur so riskant wie die Tools, auf die sie Zugriff haben. Ein nur-lesender Agent, der auch send_email oder delete_record aufrufen kann, ist nicht nur-lesend.
Dokumentieren Sie vor dem Produktivbetrieb jedes Tool, das jedem Agenten zugänglich gemacht wird. Beantworten Sie für jedes Tool:
- Welche Daten kann dieses Tool lesen?
- Welchen Zustand kann dieses Tool verändern?
- Ruft dieses Tool einen externen Dienst auf?
- Erfordert dieses Tool eine Authentifizierung, und wessen Anmeldedaten verwendet es?
Wenn Sie MCP-Server einsetzen, wird daraus: jedes Tool, das von jedem für diesen Agenten registrierten Server bereitgestellt wird, über jede Sitzung hinweg, die dieser Server geöffnet hat.
Was zu prüfen ist: Können Sie ein vollständiges Tool-Inventar für jeden Agenten erstellen, einschließlich des Berechtigungsumfangs jedes Tool-Calls?
3. Sind schreibfähige Aktionen an eine menschliche Freigabe gebunden?
Dies ist die Prüfung, die die meisten Teams überspringen, und diejenige, die am meisten zählt, wenn etwas schiefgeht.
Nur-lesende Agenten-Aktionen (zusammenfassen, analysieren, abrufen) können oft autonom laufen. Schreibfähige Aktionen (senden, erstellen, aktualisieren, löschen, ausführen) sollten einen Menschen in der Schleife erfordern für alles, was produktive Daten oder externe Systeme berührt — zumindest so lange, bis Sie genügend Verlaufsdaten haben, um einem bestimmten Aktionsmuster zu vertrauen.
Ihr Freigabemechanismus muss:
- Die Aktion vor der Ausführung abfangen, nicht danach
- Die geschwärzte Aktion einem Prüfer präsentieren (keine rohen Anmeldedaten oder sensiblen Argumente offenlegen)
- Die Entscheidung des Prüfers und die Begründung protokollieren
- Die Agenten-Sitzung auf Basis dieser Entscheidung fortsetzen oder abbrechen
Ohne ein Freigabe-Gate vor der Ausführung haben Sie eine Nachprüfung nach dem Vorfall, keine Governance.
Was zu prüfen ist: Verfügen Sie über einen Mechanismus, der die Agenten-Ausführung vor schreibfähigen Aktionen pausiert und an einen menschlichen Prüfer leitet?
4. Protokollieren Sie die richtigen Dinge — und nicht die falschen?
Audit-Protokollierung für AI-Agenten ist nicht dasselbe wie Anwendungsprotokollierung. Sie benötigen:
- Eine kanonische Trace-ID pro Anfrage, die Prompt → Tool-Call → Ergebnis verknüpft
- Eine Aufzeichnung dessen, was der Agent zu tun beschlossen hat und warum (Richtlinienentscheidung, nicht nur Ergebnis)
- Welche Daten in der Anfrage erkannt wurden und wie sie behandelt wurden
- Welche Freigabe erteilt wurde, von wem und wann
Was Sie nicht protokollieren sollten:
- Rohe Prompts mit PII, Geheimnissen oder vertraulichen Kundendaten
- Vollständige Tool-Call-Argumente mit Bearer-Tokens oder Verbindungszeichenfolgen
- Ungeschwärzte Nutzereingaben in append-only Audit-Datensätzen
Alles zu protokollieren ist keine Compliance-Haltung. Die richtigen Dinge zu protokollieren — mit PII und Geheimnissen, die behandelt werden, bevor sie ins Protokoll gelangen — schon.
Was zu prüfen ist: Können Sie für eine beliebige Agenten-Aktion einen Trace von der ursprünglichen Anfrage bis zum Endergebnis erstellen, ohne dass dieser Trace rohe sensible Daten enthält?
5. Können Sie eine Agenten-Sitzung in Echtzeit beenden?
Wenn ein Agent in einen unerwarteten Zustand gerät — sich in einer Schleife befindet, Berechtigungen eskaliert, Aufrufe tätigt, die Sie nicht erwartet haben — müssen Sie ihn stoppen, bevor er abschließt. Nicht danach.
Das bedeutet:
- Einen Notausschalter, der eine aktive Agenten-Sitzung sofort beendet
- Einen Mechanismus, der verhindert, dass die Sitzung nach der Beendigung automatisch fortgesetzt wird
- Eine Aufzeichnung darüber, warum die Sitzung beendet wurde und wer sie ausgelöst hat
„Wir können ohne diesen Agenten neu bereitstellen“ ist kein Notausschalter.
Was zu prüfen ist: Können Sie eine bestimmte laufende Agenten-Sitzung jetzt, innerhalb von 30 Sekunden, beenden, ohne angrenzende Dienste lahmzulegen?
6. Sind die Anbieter-Anmeldedaten auf die Sitzung beschränkt — nicht auf den Agenten?
Wenn sich Ihre Agenten bei AI-Anbietern oder Tools mit langlebigen API-Schlüsseln authentifizieren, werden diese Schlüssel in dem Moment zum Ziel, in dem ein Teil Ihrer Pipeline kompromittiert wird.
Die sicherere Architektur: kurzlebige, eingegrenzte Tokens an der Sitzungsgrenze ausstellen. Das Token ist für eine Sitzung gültig, mit einem Satz zulässiger Aktionen. Wenn die Sitzung endet, läuft das Token ab. Keine langlebigen Geheimnisse in Ihrer Agenten-Laufzeit.
Was zu prüfen ist: Sind Ihre Anmeldedaten zwischen Agent und Anbieter sitzungsgebunden und selbst-ablaufend, oder handelt es sich um langlebige Schlüssel, die aus Ihrer Bereitstellung extrahiert werden könnten?
7. Laufen Ihre Agenten unter einem Richtliniendokument — oder unter einer Annahme?
Die meisten Agenten-Bereitstellungen laufen unter einer Annahme: Der Entwickler ging davon aus, dass sich der Agent auf eine bestimmte Weise verhalten würde, aber nichts erzwingt diese Annahme zur Laufzeit.
Ein Richtliniendokument bedeutet:
- Explizite Allow/Deny-Regeln, welche Modelle der Agent aufrufen darf
- Explizite Allow/Deny-Regeln, welche Tools und Aktionen der Agent ausführen darf
- Explizite Regeln, was eine Freigabepflicht auslöst gegenüber automatischer Ausführung
- Versionierte Richtlinie — damit Sie sehen können, was sich wann und warum geändert hat
Policy-as-Code für Agenten ist für regulierte Teams kein Nice-to-have. Es ist das, wonach Ihr Auditor fragen wird.
Was zu prüfen ist: Verfügen Sie über ein schriftliches, versioniertes Richtliniendokument, das jeden produktiven Agenten regelt? Könnten Sie es während eines Audits vorlegen?
8. Haben Sie getestet, was passiert, wenn ein Agent ausfällt?
Fehlermodi für AI-Agenten unterscheiden sich von Fehlermodi für deterministischen Code. Ein Agent kann:
- Einen Tool-Call halluzinieren, der nicht existiert
- Sich bei einer Aufgabe, die er nicht abschließen kann, in einer Schleife verfangen
- Seine eigenen Berechtigungen eskalieren, wenn die Richtlinienschicht an der Ausführungsgrenze nicht durchgesetzt wird
- Stillschweigend die falsche Aktion erfolgreich ausführen
Führen Sie vor dem Produktivbetrieb Fehlerszenarien durch:
- Was passiert, wenn das Freigabe-Gate nicht erreichbar ist?
- Was passiert, wenn der Agent ein Tool aufruft, das einen Fehler zurückgibt?
- Was passiert, wenn der Agent versucht, ein Tool aufzurufen, das er nicht verwenden darf?
- Was passiert, wenn das LLM ein fehlerhaftes Tool-Call-Argument zurückgibt?
Wenn die Antwort auf eine dieser Fragen „wir sind uns nicht sicher“ lautet, ist das eine Lücke in der Produktionsreife.
Was zu prüfen ist: Verfügen Sie über dokumentierte Fehlerszenarien und erwartetes Verhalten für jedes davon?
Die Schwelle zur Produktionsreife
Ein AI-Agent ist aus Governance-Sicht produktionsreif, wenn Sie alle acht obigen Prüfungen mit Ja beantworten können.
Die meisten Teams, die heute Agenten starten, können zwei oder drei mit Ja beantworten. Die Lücken sind kein Zeichen von Nachlässigkeit — sie sind ein Zeichen eines Marktes, der sich schneller bewegt hat als das Tooling.
Shield Control von Qadar AI schließt diese Lücken: Agenten-Identitätsregister, Tool-Inventar, Freigabe-Gates vor der Ausführung, sitzungsgebundene Anmeldedaten, Richtliniendurchsetzung und Audit-Trail — bereitgestellt als eine einzige Governance-Schicht, die Ihr Operations-Team ohne eigene Entwicklung konfigurieren kann.
Bereiten Sie Agenten für den Produktivbetrieb vor? Sehen Sie, wie Qadar AI den gesamten Agenten-Lebenszyklus regelt. Buchen Sie eine Walkthrough-Session
