Agenten führt man wie Mitarbeiter — oder gar nicht

Warum KI-Agenten einen Lebenszyklus brauchen: Onboarding, Probezeit, Beförderung, Offboarding. Und wie man das technisch durchsetzt.

Kein Unternehmen gibt einem neuen Mitarbeiter am ersten Tag Admin-Rechte auf alle Systeme, eine Firmenkreditkarte ohne Limit und die Freiheit, eigenständig Verträge zu unterschreiben. Bei KI-Agenten passiert genau das — täglich, in Unternehmen, die sich für vorsichtig halten. Ein Agent bekommt den Service-Account eines Entwicklers, Zugriff auf das halbe Datenhaus und einen API-Key ohne Budget-Deckel. Nicht aus Leichtsinn, sondern weil niemand die Frage gestellt hat, die bei Menschen selbstverständlich ist: Wie onboarden wir den eigentlich?

Die These dieses Artikels: Agenten sind keine Tools, sie sind eine neue Art Belegschaft. Und für Belegschaften haben HR und Identity-Management seit Jahrzehnten funktionierende Prozesse. Man muss sie nicht neu erfinden — man muss sie übertragen. Als Lebenszyklus in vier Phasen.

Phase 1: Onboarding — die Grundausstattung

Vier Dinge bekommt jeder menschliche Mitarbeiter am ersten Tag. Jeder Agent braucht dieselben.

Eine eigene Identität. Der häufigste Sündenfall in der Praxis: Der Agent läuft unter dem Service-Account eines Menschen oder — schlimmer — unter einem geteilten Team-Account. Damit ist jede Nachvollziehbarkeit dahin. Wer hat um 3 Uhr nachts 40.000 Datensätze exportiert — der Kollege oder sein Agent? Jeder Agent braucht eine eigene, eindeutige Identität im Identity-Management (Entra, Okta, was immer im Haus läuft), mit Rechten nach Least-Privilege: genau die Berechtigungen für seine Aufgabe, keine mehr, jederzeit widerrufbar.

Einen eigenen Arbeitsplatz. Isolierte Speicher- und Ausführungsbereiche statt Vollzugriff auf gemeinsame Laufwerke. Das ist keine Schikane, sondern die Voraussetzung dafür, dass sich im Ernstfall rekonstruieren lässt, worauf der Agent zugegriffen hat — und worauf nicht.

Eine Zielvereinbarung. Klarer Auftrag, umrissener Scope, explizit erlaubte Aktionen — und ebenso explizite No-Gos. Das ist die Stellenbeschreibung des Agenten, und sie gehört dokumentiert, versioniert und freigegeben wie jede andere Systemdokumentation auch. Wer den EU AI Act im Blick hat, erkennt hier bereits die Vorarbeit für die technische Dokumentation nach Artikel 11.

Monitoring und ein Budget. Jede Handlung protokolliert, klare Eskalationspfade, ein hartes Kosten-Limit. Der letzte Punkt wird chronisch unterschätzt: Ein Agent ohne Budget-Deckel ist ein Mitarbeiter mit Blankoscheck. API-Kosten laufen leise auf — ein fehlgeleiteter Retry-Loop kann über ein Wochenende fünfstellig werden, ohne dass es jemand merkt.

Phase 2: Probezeit und Beförderung — Autonomie in Stufen

Der häufigste Fehler nach dem Onboarding ist die Alles-oder-nichts-Autonomie: Entweder der Agent darf gar nichts und ist nutzlos — oder er darf plötzlich fast alles, weil das Pilotprojekt überzeugt hat und der Termindruck steigt. Beides ist falsch. Vertrauen ist bei Menschen keine binäre Größe, und bei Agenten auch nicht.

Ein Muster, das sich direkt übertragen lässt, kommt aus dem Data Warehousing: das Medallion-Prinzip. Dort wandern Daten in Qualitätsstufen von Bronze über Silver zu Gold. Bei Agenten werden daraus Vertrauens- und Autonomiestufen:

Entscheidend ist, was zwischen den Stufen passiert. Beförderung darf nur nach definierten, messbaren Kriterien erfolgen — nicht nach Bauchgefühl und nicht nach Termindruck. Praktikable Kriterien sind etwa: Fehlerrate unter Schwellwert über n Wochen, null Policy-Verletzungen im Beobachtungszeitraum, dokumentierte Reviews der Sandbox-Phase. Und genauso wichtig wie die Beförderung ist die Rückstufung: Ein Agent, der auffällig wird — ungewöhnliche Zugriffsmuster, gehäufte Eskalationen, ein Vorfall — geht eine Stufe zurück. Automatisch, nicht nach Diskussion.

Wer hier die Parallele zum EU AI Act sucht, findet sie in Artikel 14: menschliche Aufsicht, angemessen zum Risiko. Das Stufenmodell ist nichts anderes als die operationalisierte Antwort auf die Frage, was „angemessen" konkret heißt — abgestuft statt pauschal. Und wer ein AI-Managementsystem nach ISO 42001 aufbaut, bekommt mit den Stufen gleich die Struktur für die geforderten Lifecycle-Kontrollen mitgeliefert.

Phase 3: Durchsetzung — der Pförtner vor den Werkzeugen

Stufen auf Papier sind Governance-Theater, wenn nichts sie technisch erzwingt. Und genau hier liegt bei agentischen Systemen die offene Flanke, über die kaum jemand spricht: die Werkzeuge.

Konkret am Beispiel MCP (Model Context Protocol), dem sich abzeichnenden Standard für die Anbindung von Tools an Agenten: Ein MCP-Server stellt dem Agenten Werkzeuge zur Verfügung — Datenbankzugriffe, E-Mail-Versand, Dateioperationen. Das Problem: Diese Server sind oft extern, und sie ändern sich. Der Betreiber kann jederzeit neue Tools hinzufügen oder bestehende Tool-Beschreibungen umschreiben. Der Agent, der gestern drei harmlose Lesezugriffe hatte, hat heute vielleicht ein viertes Tool mit Schreibrechten — und niemand im Unternehmen hat es freigegeben, weil niemand gefragt wurde.

Die Antwort ist ein Muster, das aus dem klassischen Netzwerk-Design vertraut ist: ein Gateway. Statt Agenten direkt mit externen MCP-Servern sprechen zu lassen, schaltet man einen eigenen, unternehmenskontrollierten Zwischenserver dazwischen. Der macht drei Dinge:

• Er reicht nur eine geprüfte Allowlist an Tools durch. Was upstream neu auftaucht, existiert für den Agenten schlicht nicht, bis es explizit freigegeben wurde.
• Er pinnt die freigegebenen Tool-Definitionen. Ändert sich upstream eine Beschreibung oder ein Parameter-Schema, schlägt der Gateway Alarm statt die Änderung stillschweigend durchzureichen.
• Er ist der natürliche Ort für zentrales Logging und für die Durchsetzung der Autonomiestufen — ein Bronze-Agent bekommt am Gateway schlicht andere Tools zu sehen als ein Gold-Agent, aus derselben Konfiguration heraus.

In der Mitarbeiter-Analogie: Der neue Kollege bestellt nicht direkt beim Lieferanten. Er geht über den Einkauf. Nicht weil man ihm misstraut, sondern weil der Einkauf die Konditionen kennt, die Lieferanten geprüft hat und jede Bestellung dokumentiert.

Phase 4: Offboarding — der Teil, den alle vergessen

Menschen verlassen Unternehmen, und IAM-Prozesse sorgen (idealerweise) dafür, dass mit ihnen auch ihre Zugänge gehen. Agenten werden ausgemustert — durch neue Versionen ersetzt, nach Pilotende abgeschaltet, nach Umstrukturierung obsolet. Und ihre Zugänge? Bleiben erstaunlich oft bestehen.

Zombie-Agenten mit Restrechten sind ein Sicherheitsalbtraum mit besonders unangenehmer Eigenschaft: Niemand fühlt sich zuständig. Der Entwickler ist im nächsten Projekt, das Fachteam weiß nicht, dass der Agent noch Credentials hat, und im IAM taucht er als unauffälliger Service-Account auf. Die Lösung ist unspektakulär: Offboarding als Pflichtschritt im Lebenszyklus, mit Entzug aller Identitäten, Widerruf aller Credentials, Löschung oder Archivierung der Arbeitsbereiche — und einem regelmäßigen Review aller aktiven Agenten-Identitäten gegen die Liste tatsächlich betriebener Agenten. Rezertifizierung, wie sie für privilegierte menschliche Accounts längst Standard ist.

Eine wichtige Anmerkung

Wer das Stufenmodell als Haftungsverschiebung liest, hat es missverstanden.

Fazit

Das Muster hinter alledem ist banal, und genau deshalb funktioniert es: Alles, was HR und Identity-Management seit Jahrzehnten für Menschen tun — Identität, Berechtigung, Zielvereinbarung, Bewährung, Kontrolle, Austritt — braucht jetzt eine zweite Zielgruppe. Eine, die nie krank wird, nie schläft und deren Zahl schneller wächst als jede Belegschaft zuvor.

Die gute Nachricht: Die Prozesse existieren. Die Frage ist nur, ob Sie sie auf Ihre Agenten anwenden, bevor der erste Vorfall es erzwingt.