Stellen Sie sich einen Dienstagvormittag vor. Ein Prüfer sitzt Ihrem IT-Leiter gegenüber und hat eine einzige Frage.
„Welche Fassung dieses Agenten lief am Monatsende, und wer hat sie freigegeben?“
Der Agent beantwortet seit Wochen Anfragen. Er nutzt zwei Skills und läuft in einer eigenen Umgebung. Gebaut hat ihn ein Entwickler, Schritt für Schritt in der Claude Console.
Die Antwort steht nirgends. Sie steht im Gedächtnis dieses Entwicklers.
Was im Pilot niemand fragt
Im Pilot ist das kein Problem. Mit dem Betrieb kommen die Fragen, die vorher niemand gestellt hat. Es sind fast immer dieselben vier:
- Welche Fassung läuft gerade?
- Wer hat die letzte Änderung freigegeben?
- Was passiert, wenn jemand abends in der Console ein Feld ändert?
- Wie kommen Sie zurück, wenn die neue Fassung schlechter ist als die alte?
Im Pilot beantwortet das der Entwickler aus dem Gedächtnis. Im Betrieb reicht das nicht.
Aus einem Werkzeug wird eine Identität
Im ersten Teil dieser Reihe ging es um Schlüssel, die den Menschen überleben, der sie angelegt hat. Dieser Teil geht eine Ebene höher, zu den Agenten selbst.
Die Veränderung ist leise. Ein Agent im Betrieb handelt im Namen des Unternehmens, mit Rechten und unter einer Identität. Damit gehört er in dieselbe Ordnung wie jedes andere System im Betrieb.
Zwei Antworten auf dieselbe Frage
Zurück zum Prüfer. Seine Frage lässt sich auf zwei Arten beantworten.
Das eine sucht. Es fragt den Entwickler, sieht sich die Console an und rekonstruiert, was vermutlich gelaufen ist.
Das andere öffnet das Repository. Dort liegt die Datei, die den Agenten beschreibt, mit Historie, Autor und Freigabe.
Der Agent ist in beiden Fällen derselbe. Der Unterschied liegt in seinem Umfeld.
Wohin die Reise geht
Die These dieses Beitrags: Was im Betrieb läuft, behandeln Sie wie Infrastruktur. Dann hat ein Agent vier Eigenschaften, die im Pilot niemand verlangt hat:
- reproduzierbar, weil er als Datei vorliegt,
- prüfbar, weil jede Änderung an der Datei durch Plan und Review geht,
- zurücknehmbar, weil die vorherige Fassung im Repository liegt,
- nachvollziehbar, soweit die Nutzung protokolliert wird.
Für Claude-Ressourcen gibt es dafür den Befehl ant apply im Kommandozeilenprogramm ant.
Frage 1: Welche Fassung läuft gerade?
ant ist das Kommandozeilenprogramm von Anthropic für die Claude-Schnittstelle: "The ant CLI provides access to the Claude API from your terminal." Jede Ressource steht darin als eigener Befehl bereit, gesteuert über Dateien statt über Klicks in der Console. Den Zweck von ant apply fasst die Dokumentation in einem Satz zusammen: "ant apply creates and updates Claude API resources from files: agents, environments, skills, memory stores, deployments, and vaults."
Der Satz danach ist der wichtigere: "They live in your repository and change through the same review as your code."
Ein Agent ist damit keine Einstellung mehr, die jemand in einer Oberfläche vornimmt. Er ist eine Datei im Repository, mit Historie, Autor und Freigabe. Voraussetzung ist die CLI-Version (Kommandozeilenprogramm) 1.30.0 oder neuer, für Vault-Dateien 1.34.0.
Die Lockfile claude-lock.json entsteht beim ersten Lauf im Aufrufverzeichnis. Sie hält für jede Datei die ID der angelegten Ressource fest, dazu Organisation und Arbeitsbereich. Über sie findet der nächste Lauf, lokal oder in der Pipeline, dieselben Ressourcen wieder, statt sie neu anzulegen.
Frage 2: Wer hat die letzte Änderung freigegeben?
Der Ablauf: Sie beschreiben eine Ressource in einer Datei, führen ant apply aus, geben den angezeigten Plan frei und committen die Lockfile, die dabei entsteht.
Mit --dry-run gibt ant apply den Plan nur aus und ändert nichts.
Im Betrieb läuft ant apply in der Pipeline. Ohne Terminal zeigt das Programm den Plan und stoppt. Anwenden geht dann nur mit --yes.
Die Dokumentation beschreibt dafür ein Muster. In Pull Requests läuft ant apply --dry-run . und zeigt den Prüfern den Plan. Nach dem Merge läuft auf dem Standardzweig ant apply --yes .. Der Probelauf ist nur informativ und endet auch bei blockiertem Plan ohne Fehlercode.
Ein blockierter Plan hält den Merge also nicht von selbst auf. Jemand muss ihn lesen.
Eine Regel aus der Dokumentation gehört in jede Pipeline-Beschreibung: immer nur einen Apply gleichzeitig ausführen, denn nichts sperrt die Lockfile.
Frage 3: Was passiert, wenn jemand abends in der Console ein Feld ändert?
Zwei Prüfsummen in der Lockfile halten fest, was zuletzt gesendet wurde und was die Schnittstelle zurückgab. Daran erkennt ein späterer Lauf eine geänderte Datei, aber auch eine Ressource, die jemand außerhalb der Dateien geändert hat.
An dieser Stelle wird aus Bequemlichkeit Governance. Genau den abendlichen Fall beschreibt die Dokumentation. Alle Angaben der Übersicht stammen aus der Herstellerdokumentation.
| Situation | Verhalten von ant apply |
|---|---|
| Datei geändert | Der nächste Lauf aktualisiert dieselbe Ressource. |
| Ressource außerhalb der Dateien geändert, archiviert oder gelöscht | Der Plan endet mit This plan cannot be applied:, der Befehl bricht mit refusing to apply ab. --force überschreibt oder legt Ersatz an. |
| Datei gelöscht | Die Ressource bleibt mit einer Warnung bestehen. Erst --prune entfernt sie: Sie wird archiviert, ein Skill wird gelöscht. |
| Datei umbenannt | Gilt als neue Ressource. Die alte bleibt bis zum --prune bestehen. |
| Bestehender Agent aus der Console | Kein Import. Eine Datei, die ihn beschreibt, erzeugt einen zweiten. |
Eine Änderung an der Datei vorbei fällt beim nächsten Apply-Lauf auf und blockiert ihn. Bis dahin läuft die geänderte Fassung. Wer sie überschreiben will, muss das ausdrücklich mit --force tun.
Frage 4: Wie kommen Sie zurück?
Zurücknehmen heißt hier, die vorherige Fassung der Datei wiederherstellen und erneut anwenden.
Das hat Grenzen. Fehlt in der alten Fassung ein Feld, leert ant apply es nur, wenn die Schnittstelle das zulässt, sonst bleibt der Wert stehen. Wie ant apply auf eine nach --prune wiederhergestellte Datei reagiert, beschreibt die Dokumentation nicht. Das gehört in Ihre Freigaberegel.
Die Falle beim Übergang aus dem Pilot
Der Agent vom Anfang wurde in der Console gebaut. Genau hier liegt die Falle.
Die Dokumentation ist eindeutig: "ant apply can't adopt a resource you created in the Console or with ant beta:agents create." Verwaltet wird nur, was in der Lockfile steht.
Wer jetzt eine Datei schreibt, die den bestehenden Agenten beschreibt, bekommt einen zweiten Agenten.
Es gibt einen geregelten Weg. Laden Sie den Agenten in der Console über „Export as code“ herunter, enthält der Download eine eigene claude-lock.json. Ein Apply aktualisiert dann die Ressourcen, die dort gebaut wurden.
Der Export ist der eigentliche Übergabepunkt vom Pilot in den Betrieb. Er gehört auf die Checkliste, bevor jemand die erste Datei schreibt.
Aus der Praxis: Der live geschaltete Agent durfte nur sehr eingeschränkt online suchen. Für die Suche war deshalb ein eigener Aufruf über das Model Context Protocol (MCP) einzuplanen, und der erforderte eigene Berechtigungen für API-Aufrufe.
Aus einer Funktionsfrage wird so eine Berechtigungsfrage. Genau dorthin führt der nächste Abschnitt.
Unter wessen Namen der Agent handelt
Die Pipeline spielt Änderungen ein. Sie braucht dafür eine Identität, und die sollte keinem Menschen gehören. Hier schließt sich der Kreis zum ersten Teil.
Für die Anmeldung in der Pipeline empfiehlt die Dokumentation Workload Identity Federation statt eines gespeicherten API-Schlüssels. Zugangsdaten, die zu einer anderen Organisation oder einem anderen Arbeitsbereich gehören als dem in der Lockfile, weist ant apply zurück.
Die Dienstkonten verwaltet die Admin API, im ant-Programm unter ant beta:organization. Einen Reifegrad nennt die Dokumentation nicht, der Namensraum heißt beta:.
Drei Bausteine, mit den Kennungen aus der Dokumentation:
| Baustein | Kennung | Zweck |
|---|---|---|
| Service Account | svac_... |
Nicht-menschliche Identität, als die Service-Account-Schlüssel und Föderations-Tokens handeln |
| Federation Issuer | fdis_... |
Registrierter OIDC-Identitätsanbieter (OpenID Connect), dessen Tokens eine Workload-Identität für die Organisation behaupten dürfen |
| Federation Rule | fdrl_... |
Ordnet Tokens eines Issuers Service Accounts und Scopes zu |
Ein Detail passt genau zum Offboarding aus Teil 1. Service-Account-Schlüssel hören auf zu funktionieren, wenn der Service Account archiviert wird. Sie arbeiten aber weiter, wenn der Mensch entfernt wird, der sie angelegt hat.
Für den Betrieb ist das richtig, denn ein Agent soll nicht stehen bleiben, weil ein Entwickler geht. Das Ende eines Dienstkontos wird damit aber zu einem eigenen Prozessschritt.
Die Grenze minimaler Rechte liegt an anderer Stelle. Die Endpunkte für Service Accounts, Issuer und Rules akzeptieren nur ein OAuth-Token mit dem Scope org:admin. Ein solches Token gilt für die ganze Organisation, unabhängig vom Arbeitsbereich, an den das Profil oder die Föderationsregel gebunden ist.
Die Frage für Ihr Rollenkonzept lautet deshalb: Wer hält dieses Token, und wo ist das festgehalten?
Was sich im Nachhinein belegen lässt
Die Compliance API gibt Kunden von Claude Enterprise und der Claude Console programmatischen Zugriff auf den Activity Feed ihrer Organisation. Für Claude-Enterprise-Organisationen deckt sie zusätzlich Verzeichnis, Einstellungen, Inhalte und Sitzungen ab.
Entscheidend ist, welche Sitzungen erfasst sind:
| Sitzung | Über die Compliance API abrufbar |
|---|---|
| Claude Code lokal: Terminal, Claude Desktop, IDE-Erweiterung | ja, über die Endpunkte für lokale Sitzungen |
| Cowork aus claude.ai im Web und mobil | ja, über die Endpunkte für Remote-Sitzungen |
| Claude Code in der Cloud | nein |
| Claude Code mit einem Console-API-Schlüssel | nein |
| Claude Code über Amazon Bedrock, Google Cloud oder Microsoft Foundry | nein |
Das „ja“ für Claude Code lokal gilt nur bei aktivierter Compliance API und Anmeldung mit dem Claude-Enterprise-Konto. Lokale Sitzungen unter Zero Data Retention fehlen.
Ein Transkript enthält Prompts, Antworten, Tool-Aufrufe und deren Ergebnisse. Lokale Sitzungen werden serverseitig aufgezeichnet, auf dem Gerät wird nichts installiert. Die Grenze steht in einem Satz: "Local session transcripts show what Claude was asked to do and what it returned, not what happened on the device."
Im lokalen Transkript fehlen Thinking Blocks, der System-Prompt, Tool-Definitionen und die MCP-Konfiguration, ebenso Bilder und PDFs. URLs, Zugangsdaten und personenbezogene Daten werden darin nicht maskiert, Transkripte sind deshalb als sensibel zu behandeln.
Zwei Grenzen gehören in jedes Prüfkonzept. Erstens ruft die Compliance API Daten nachträglich ab. Für das Eingreifen vor der Inferenz nennt die Dokumentation Inference Hooks, gekennzeichnet als Beta. Zweitens reicht die Liste der erfassten Oberflächen heute von Cowork bis Claude in Chrome und wird laut Dokumentation ergänzt, wenn die Abdeckung wächst. Per ant apply verwaltete Agenten stehen nicht auf dieser Liste. Ist Ihre Console-Organisation eigenständig, also nicht Teil eines Enterprise-Tenants, kann sie nur den Activity Feed abfragen. Das sollten Sie klären, bevor Sie Ihren Nachweis darauf aufbauen.
Und NIS2?
Für Unternehmen, die unter die NIS2-Umsetzung fallen, gibt es einen Bezugspunkt im Gesetz. § 30 Absatz 2 BSIG bestimmt, dass die Maßnahmen den Stand der Technik einhalten sollen und „zumindest Folgendes umfassen“ müssen.
Nummer 9 nennt die „Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen, -Produkten und -Prozessen“. Sie spricht von Konzepten, nicht von Werkzeugen.
Einordnung des Autors, keine Rechtsauslegung: Ein Agent, der als Datei im Repository liegt, über einen geprüften Plan ausgerollt wird und unter einer eigenen Maschinenidentität läuft, kann ein Baustein solcher Konzepte sein. Ob das im Einzelfall genügt, beantwortet kein Werkzeug.
Fazit: Zurück am Tisch mit dem Prüfer
Dieselbe Frage, ein halbes Jahr später: „Welche Fassung dieses Agenten lief am Monatsende, und wer hat sie freigegeben?“
Diesmal öffnet Ihr IT-Leiter das Repository. Dort liegen die Datei, ihr Stand zum Monatsende und der Pull Request mit dem freigegebenen Plan.
Ein Agent im Pilot gehört dem, der ihn gebaut hat. Ein Agent im Betrieb gehört dem Unternehmen.
Für den Anfang reichen drei Fragen an Ihre IT. Wo liegt die Definition des Agenten, der bei Ihnen am längsten läuft? Wurde er in der Console gebaut, und gibt es einen Export? Unter welcher Identität spielt Ihre Pipeline Änderungen ein, und wer ist für sie zuständig?
Quellen
- Manage resources as code with ant apply, Claude Platform Docs: https://platform.claude.com/docs/en/cli-sdks-libraries/cli/apply
- CLI quickstart, Claude Platform Docs: https://platform.claude.com/docs/en/cli-sdks-libraries/cli/quickstart
- Compliance API, Claude Platform Docs: https://platform.claude.com/docs/en/manage-claude/compliance-api
- Retrieve session transcripts, Claude Platform Docs: https://platform.claude.com/docs/en/manage-claude/compliance-sessions
- Admin API, Claude Platform Docs: https://platform.claude.com/docs/en/manage-claude/admin-api
- § 30 BSIG: https://www.gesetze-im-internet.de/bsig_2025/__30.html
Siehe Claude-Dokumentation vom 01.10.2026, Admin API vom 05.10.2026, § 30 BSIG vom 10.09.2026.
