# Von Auftragnehmern verwaltete KI-Agenten: Produktionszugriff sauber beenden Ein Auftragnehmer kann mit einem KI-Programmieragenten hervorragende Arbeit leisten und deine Produktionsumgebung trotzdem in einem schlechteren Zustand hinterlassen, als er sie vorgefunden hat. Das Problem beginnt meist nicht mit einem bösartigen Prompt. Es beginnt damit, dass alle davon ausgehen, jemand anderes kümmere sich um den Agentenprozess, die Genehmigungen und das Aufräumen. Behandle einen von einem Auftragnehmer betriebenen Agenten wie einen vorübergehenden Produktionsbediener. Gib ihm einen intern verantwortlichen Sponsor, eine erkennbare Prozessidentität, einen eng begrenzten Berechtigungspfad und ein Entfernungsverfahren, das jemand bereits geübt hat. Wenn du den Mitarbeiter nicht nennen kannst, der ihn heute stoppen kann, hast du keine Arbeit delegiert. Du hast einen verwaisten Prozess geschaffen. ## Die Identität eines Auftragnehmers darf keinen Produktionsagenten besitzen Das Unternehmen, dem das Produktionssystem gehört, muss auch die Berechtigungen des Agenten besitzen, selbst wenn ein Auftragnehmer den Prozess startet und überwacht. Das Arbeitsverhältnis, das persönliche Konto, der Laptop und die Kalendereinladung eines Auftragnehmers enden unter Bedingungen, die du nicht direkt kontrollierst. Der Produktionszugriff darf von keinem dieser Dinge abhängen. Teams verwechseln oft zwei Fragen: - Wer bedient den Agenten während dieses Auftrags? - Wer bleibt für jede Fähigkeit verantwortlich, die der Agent erhält? Der Auftragnehmer kann die erste Frage beantworten. Ein interner Mitarbeiter muss die zweite beantworten. Dieser Mitarbeiter braucht genügend Befugnisse, um die Arbeit zu pausieren, ihren Umfang zu ändern, Aufzeichnungen zu prüfen und den Zugriff zu beenden, ohne auf eine Antwort des Auftragnehmers warten zu müssen. Ich habe erlebt, wie das auf ganz gewöhnliche Weise schiefging. Ein Auftragnehmer erhält eine Einladung zu einem Quellcode-Repository und ein Produktions-API-Token, weil er ein Problem untersuchen soll. Von seinem eigenen Rechner aus verwendet er einen Agenten, um Code zu prüfen, die API abzufragen und eine Lösung vorzubereiten. Der Vertrag endet, das Repository-Konto des Auftragnehmers wird deaktiviert, und alle halten die Sache für erledigt. Wochen später besitzt ein automatisches Terminalprofil das Token noch immer. Das alte Arbeitsverzeichnis des Agenten enthält weiterhin Anweisungen zur Verwendung des Tokens. Das Unternehmen hat eine Person aus einem System entfernt, aber keinen betrieblichen Pfad zur Produktion. Mache das Benutzerkonto des Auftragnehmers nicht zur dauerhaften Identität für Agentenarbeit. Erstelle einen unternehmenseigenen Auftragseintrag und binde den Zugriff an diesen Eintrag. Er sollte den internen Sponsor, den technischen Verantwortlichen, den Bediener, die freigegebenen Umgebungen, die Prozessidentität und die Endbedingung nennen. Eine Person kann den Arbeitgeber wechseln oder über ein Wochenende verschwinden. Ein Eintrag kann dem nächsten Bereitschaftsingenieur weiterhin zeigen, was existiert und wie es abgeschaltet wird. Das ist keine Bürokratie um ihrer selbst willen. Es verhindert die teuerste Form von Unklarheit: einen Vorfall, bei dem das Team nicht feststellen kann, ob eine Anfrage von einem genehmigten Agenten, einer alten Konfiguration des Auftragnehmers oder einem Angreifer mit vergessenen Zugangsdaten stammt. ## Einen Mitarbeiter für die Delegationsentscheidung benennen Jeder Auftrag braucht einen Sponsor, der die Entscheidung verantwortet, einen Agenten handeln zu lassen, nicht nur die Entscheidung, den Auftragnehmer einzustellen. Das ist meist der Engineering Manager, der Serviceverantwortliche oder der Incident Commander mit Befugnissen für den betroffenen Produktionsbereich. Der Sponsor sollte vor der Erteilung von Produktionsberechtigungen vier konkrete Fragen beantworten: Welche Aufgabe erledigt der Agent? Welche Umgebung darf er erreichen? Welche Aktionen gehören zur Aufgabe? Wann endet die Berechtigung? Vermeide unklare Bereiche wie «den Service unterstützen» oder «bei Deployments helfen». Solche Formulierungen werden gefährlich, wenn ein Agent sie über seine Werkzeuge auslegen kann. Beschreibe die Arbeit stattdessen beobachtbar: Fehlermeldungen dieses Services prüfen, einen Pull Request öffnen, diesen freigegebenen Diagnosebefehl ausführen oder eine Änderungsanfrage für einen bestimmten Endpunkt einreichen. Der Sponsor muss nicht den ganzen Tag neben dem Auftragnehmer sitzen. Er muss aber die Grenzen verantworten. Wenn ein Auftragnehmer sagt, die Arbeit erfordere nun einen Datenbank-Write, eine neue Infrastrukturrolle oder Zugriff auf einen weiteren Service, ist das eine neue Delegationsentscheidung. Lass eine frühere Genehmigung nicht stillschweigend auf eine neue Anfrage ausgedehnt werden. Die NIST Special Publication 800-207 weist in ihrer Zero-Trust-Leitlinie auf einen wichtigen Punkt hin: Systeme sollten kein implizites Vertrauen gewähren, nur weil sich ein Akteur in einem bestimmten Netzwerk befindet oder früher auf eine Ressource zugegriffen hat. Übertrage diese Logik auf Agentenarbeit. Dass ein Auftragnehmer in deinem Chatkanal oder VPN ist oder früher einen Lesezugriff erhalten hat, berechtigt keinen anderen Prozess zu einem Schreibzugriff in der Produktion. Hier wählen Teams oft die falsche Vereinfachung. Sie geben dem Auftragnehmer weitreichenden dauerhaften Zugriff, weil wiederholte Genehmigungen langsam wirken. Sie wirken langsam, weil die Arbeit nicht genau genug definiert wurde. Kläre zuerst die Arbeitsgrenze. Dauerhafter weitreichender Zugriff macht aus einem Planungsproblem ein Problem für die Incident Response. Gib dem Sponsor einen klaren Ersatz. Wenn er das Unternehmen verlässt, übertrage den Auftragseintrag und genehmige die Berechtigungen erneut unter dem neuen Sponsor. Ein Prozess ohne aktuellen Sponsor sollte automatisch den Zugriff verlieren oder sofort manuell deaktiviert werden. Es gibt keinen legitimen Grund, warum ein unbeaufsichtigter Auftrag eines Auftragnehmers Produktionsberechtigungen behalten sollte. ## Die Herkunft des Prozesses gehört in jede Genehmigung Eine Person zu genehmigen ist etwas anderes, als einen Prozess zu genehmigen. Diese Unterscheidung wird regelmäßig verwischt. Dadurch decken Genehmigungen mehr Software ab, als der Prüfer beabsichtigt hat. Eine menschliche Identität zeigt, wer sich authentifiziert hat. Eine Prozessidentität zeigt, welche ausführbare Datei eine Aktion angefordert hat, wo sie lief und ob sie dem erwarteten Prozess entspricht. Wenn ein KI-Agent über Shells, Erweiterungen, MCP-Server, Hintergrundhelfer und Skripte arbeitet, erreicht der Prozess tatsächlich den Zugangsdatenpfad. Fordere Nachweise dafür an, dass ein neuer Agentenprozess der genehmigte Prozess ist. Unter macOS bietet die Codesignaturberechtigung einen nützlichen Ausgangspunkt. Sie kann die von einer ausführbaren Datei präsentierte Signaturberechtigung identifizieren. Sie kann aber nicht feststellen, ob eine Produktionsanfrage zu diesem Auftrag gehört, und auch nicht entscheiden, ob die angeforderte Aktion sinnvoll ist. Verwende sie als Prozessnachweis, nicht als pauschale Erlaubnis. Eine praktische Genehmigungskarte sollte mehr als den Anzeigenamen des Auftragnehmers zeigen. Sie sollte den Prozess oder Starter, sofern vorhanden die Codesignaturberechtigung, den aktiven Auftrag, die Zielumgebung und die angeforderte Fähigkeit nennen. Wenn der Prüfer einen bekannten Agentenprozess nicht von einem kopierten Skript unterscheiden kann, ist die Genehmigung zu schwach. Damit lässt sich ein typischer Fehler erkennen. Ein Auftragnehmer startet einen genehmigten Programmieragenten in einem Terminal. Später übernimmt ein Shellskript oder ein anderer Agentenprozess Umgebungsvariablen, liest eine lokale Konfigurationsdatei und stellt dieselbe Anfrage mit denselben Zugangsdaten. Eine Genehmigung nur für die Person kann nicht erkennen, dass es sich um verschiedene Aufrufer handelt. Der zweite Prozess mag harmlos sein, aber niemand hat das festgestellt. Die richtige Antwort ist nicht, von Prüfern unmögliche Gewissheit zu verlangen. Reduziere stattdessen, was eine einzelne Genehmigung abdeckt. Binde Genehmigungen an eine Sitzung oder einen Prozesslauf, kennzeichne diesen Lauf eindeutig und lasse die Genehmigung enden, sobald der Lauf beendet ist. Ein neuer Prozess muss sich erneut vorstellen. Halte lokal den Prozessbefehl, das Arbeitsverzeichnis, die Startzeit, den Sponsor und die erwartete Endbedingung fest. Du musst nicht jeden privaten Prompt oder jede Datei sammeln, die der Auftragnehmer liest. Du brauchst genügend betriebliche Nachweise, um eine grundlegende Frage zu einem Vorfall zu beantworten: Welcher genehmigte Prozess hat diese Aktion unter wessen Verantwortung ausgeführt, und lag sie noch innerhalb des zugewiesenen Auftrags? ## Die Genehmigungsverantwortung muss dem Schadensradius folgen Die Person, die eine Agentenaktion genehmigt, sollte den möglichen Folgen dieser Aktion entsprechen. Ein Auftragnehmer kann Routineaktionen innerhalb einer delegierten, eng begrenzten Aufgabe genehmigen. Er sollte nicht stillschweigend zur letzten Instanz für Aktionen werden, die Produktionsdaten, Berechtigungen, Kundenkommunikation oder Infrastruktur verändern können. Teile die Genehmigung in zwei Ebenen. Der Sponsor autorisiert die Kategorie der Arbeit und ihre Dauer. Der Aktionsgenehmiger autorisiert eine konkrete Operation, wenn ihre Auswirkungen eine menschliche Entscheidung verlangen. In einem kleinen Team kann ein Mitarbeiter beide Rollen übernehmen. Halte die Verantwortlichkeiten im Eintrag trotzdem getrennt, weil sie später unterschiedliche Fragen beantworten. Verwende ein einfaches Verantwortungsmodell: - Der Sponsor verantwortet Zweck, Umfang und Ablauf des Auftrags. - Der Auftragnehmer als Bediener verantwortet die Qualität der Aufgabe und fordert Aktionen innerhalb des Umfangs an. - Der Aktionsgenehmiger entscheidet, ob ein sensibler Aufruf erlaubt wird. - Der technische Verantwortliche besitzt den Zugangsdatenpfad und das Abschaltverfahren. - Security oder Operations prüft, dass der Widerruf abgeschlossen ist. Führe nicht für jeden harmlosen Lesezugriff ein Genehmigungsritual ein, nur um menschliche Kontrolle vorweisen zu können. Prüfer klicken es sonst nur noch weg und übersehen die Anfrage, die wirklich Aufmerksamkeit verdient. Setze Reibung dort ein, wo eine Aktion den Zustand verändert, Berechtigungen erweitert, geschützte Daten offenlegt oder ein neues Produktionsziel erreicht. Eine Genehmigung pro Aufruf eignet sich für leicht erkennbare und schwer rückgängig zu machende Operationen: einen Write in einen Kundendatensatz, ein Produktionsdeployment, einen SSH-Befehl mit administrativer Wirkung oder eine Anfrage zur Änderung von Berechtigungen. Eine Sitzungsgenehmigung passt zu begrenzten Untersuchungen, bei denen der Prozess mehrere zusammengehörige Lesezugriffe benötigt. Der Eintrag sollte vor Beginn der Arbeit festlegen, welche Variante gilt. Der Genehmigungsbildschirm muss außerdem das Ziel nennen. «Agent darf die API verwenden» sagt dem Prüfer fast nichts. «Diesem genehmigten Prozess erlauben, eine POST-Anfrage an den Produktionsendpunkt für Abrechnungen zu senden» ergibt eine Entscheidung, die der Prüfer verantworten kann. Er kann sie dennoch ablehnen, eine Änderungsanfrage verlangen oder den Auftragnehmer auf die Staging-Umgebung verweisen. Genehmigungsmüdigkeit ist ein Designfehler, kein Grund, Genehmigungen aufzugeben. Wenn die Warteschlange nur noch aus Lärm besteht, beschränke die Werkzeuge, fasse sichere Operationen in einer kurzen Sitzung zusammen oder verlagere die Untersuchung in eine Nichtproduktionsumgebung. Löse das Problem nicht mit dauerhaftem Produktionszugriff. ## Zugangsdaten aus dem Kontext des Agenten heraushalten Ein Agent sollte eine Aktion anfordern, nicht das Geheimnis besitzen, das sie autorisiert. Genau diese Trennung macht Offboarding möglich. Wenn der Agent eines Auftragnehmers ein Klartext-API-Token, einen privaten SSH-Schlüssel oder ein kopiertes Geheimnis in einer Konfigurationsdatei erhält, hast du bereits die Kontrolle darüber verloren, wohin die Zugangsdaten gelangen können. Das Token kann in der Terminalhistorie, im Agentenspeicher, in Protokollen, temporären Dateien, einem Codepatch oder einem an einen anderen Service gesendeten Prompt landen. Eine Rotation kann die Zugangsdaten bereinigen, rekonstruiert aber nicht, wohin sie gelangt sind. Verwende ein Aktionsgateway, das die Zugangsdaten auf der vom Unternehmen kontrollierten Seite hält und genehmigte HTTP- oder SSH-Aktionen stellvertretend für den Agenten ausführt. Der Agent erhält das Ergebnis, nicht das Geheimnis. Das macht eine unsichere Aktion nicht sicher. Es gibt dem Team aber einen Ort, an dem es Genehmigungen anwenden, Aufrufe protokollieren und Berechtigungen widerrufen kann, ohne das Dateisystem des Auftragnehmers durchsuchen zu müssen. Sallyport folgt diesem Modell bei HTTP-API-Aufrufen und SSH-Befehlen: Die Geheimnisse bleiben im verschlüsselten Tresor, und der Agent fordert Aktionen über eine MCP-Verbindung an, statt die Zugangsdaten zu erhalten. Der wichtige Vorteil ist die Trennung, keine Magie. Ein kompromittierter oder unvorsichtiger Agent kann innerhalb seines Umfangs weiterhin schädliche Aktionen anfordern. Deshalb bleiben Zuständigkeiten und Genehmigungen notwendig. Behandle jeden Zugangsdatenpfad als Inventarobjekt. Halte Eigentümer, Ziel, erlaubte Aktionsart, Auftragsreferenz und Abschaltmethode fest. Eine Notiz wie «Produktions-Token vom Auftragnehmer verwendet» reicht nicht. Sie sagt einem Incident Responder nichts darüber, wo das Token liegt, ob es kopiert wurde oder welcher Pfad deaktiviert werden muss. SSH verdient besondere Aufmerksamkeit, weil Teams oft annehmen, ein Host-Login sei vorübergehend, wenn der Auftragnehmer vorübergehend ist. Prüfe autorisierte Schlüssel, Zertifikate, lokales Agent Forwarding, Zugriff über Jump Hosts, Shell-Profile, geplante Aufgaben und entfernte Kopien von Deployment-Skripten. Das Entfernen eines öffentlichen Schlüssels widerruft keinen privaten Schlüssel, der noch einen anderen vertrauenswürdigen Sprung erreichen kann. Dasselbe gilt für HTTP-Zugangsdaten. Entferne oder deaktiviere den Aktionspfad und prüfe anschließend, dass das Ziel eine neue Anfrage ablehnt. Erkläre die Sache nicht für erledigt, nur weil ein Zugriffsmanagementbildschirm einen Benutzer als deaktiviert anzeigt. Aktionsgateway, Dienstkonto, API-Zugangsdaten und Netzwerkroute können getrennte Lebenszyklen haben. ## Den Widerruf entwerfen, bevor Zugriff gewährt wird Ein Team sollte einen von einem Auftragnehmer betriebenen Agenten widerrufen können, ohne dessen Mithilfe zu benötigen. Wenn das Verfahren den Laptop, das Passwort-Management oder das Gedächtnis des Auftragnehmers voraussetzt, ist es kein Widerrufsverfahren. Schreibe den Abschaltweg vor der ersten Produktionsaktion auf. Er sollte den Agentenprozess, die Genehmigungssitzung, den Zugangsdatenpfad, den Zugriff auf Quellcode und Infrastruktur, geplante Arbeiten und die Aufbewahrung von Auditdaten abdecken. Für jeden Punkt braucht es einen benannten Bediener und eine Möglichkeit, den Abschluss zu überprüfen. Der Unterschied zwischen Deaktivieren und Widerrufen ist wichtig. Deaktivieren verhindert die künftige Nutzung eines bestimmten Kontos oder Zugangsdatenobjekts. Widerrufen beendet die aktive Berechtigungsbeziehung und entfernt Pfade, über die sie wiederhergestellt werden könnte. Ein Konto des Auftragnehmers kann deaktiviert sein, während ein bereits laufender Prozess eine aktive Sitzung behält. Ein Token kann widerrufen sein, während eine SSH-Verbindung offen bleibt. Behandle beide Zustände. Verwende diese Reihenfolge, wenn ein Auftrag endet oder sofort gestoppt werden muss: 1. Blockiere neue Agentenaktionen am Zugangsdaten-Gateway oder Autorisierungspunkt und widerrufe anschließend aktive Sitzungen, die zum Auftrag gehören. 2. Stoppe bekannte lokale und entfernte Agentenprozesse, einschließlich Terminal-Multiplexern, Launch Agents, CI-Jobs und geplanten Aufgaben. 3. Deaktiviere oder rotiere die dem Auftrag zugewiesenen Unternehmenszugangsdaten und entferne den Zugriff auf Repositorys, Cloud, VPN, Bastion Host und Ticketsystem. 4. Durchsuche das Auftragsinventar nach kopierten Konfigurationen, erzeugten Skripten, Deploy-Schlüsseln und temporären Dienstkonten und entferne sie. 5. Prüfe die Ablehnung mit einem harmlosen Test über den autorisierten Pfad und bewahre die Aktionsaufzeichnungen auf, bevor du den Auftrag schließt. Die Reihenfolge ist wichtig. Wenn du zuerst Aufzeichnungen löschst oder das Konto des Auftragnehmers deaktivierst, können dir die Informationen fehlen, die du zum Auffinden aktiver Sitzungen brauchst. Stoppe zuerst die Aktionspfade, sichere die Nachweise und bereinige danach den Zugriff. Behaupte nicht, der Vorgang sei erfolgreich, nur weil jede Checkbox einen Verantwortlichen hat. Teste das Verfahren während des Auftrags. Bitte den technischen Verantwortlichen, eine Nichtproduktionssitzung zu widerrufen, während der Auftragnehmer anwesend ist. Bestätige, dass der Agent keinen weiteren Aufruf ausführen kann, dass der Auftragnehmer versteht, was gestoppt wurde, und dass das Aktivitätsprotokoll die Ablehnung zeigt. Zum ersten Mal sollte dein Team einen fehlenden Abschaltweg nicht während eines Sicherheitsvorfalls oder Vertragsstreits entdecken. ## Ein kurzer Auftragseintrag macht fehlende Entscheidungen sichtbar Ein kleiner, überprüfbarer Eintrag deckt mehr echte Probleme auf als eine lange Zugriffsrichtlinie, die niemand liest. Speichere ihn beim Arbeitsticket oder in einem kontrollierten Betriebsrepository, nicht in einem privaten Chatverlauf. Dieses Beispiel ist bewusst schlicht. Ersetze die Platzhalter durch deine eigenen Kennungen, aber lass keine Felder weg, nur weil der Auftrag vorübergehend scheint. ```yaml engagement: contractor-search-repair-2025-04 sponsor: employee-ops-owner technical_custodian: employee-platform-owner contractor_operator: external-developer purpose: diagnose production search indexing failures agent_process: approved_launcher: signed-local-agent-process allowed_workstation: managed-mac-asset-184 expires_at: 2025-04-30T17:00:00Z scope: environments: [staging, production-read] permitted_actions: - GET search-service health endpoint - GET indexing queue depth endpoint prohibited_actions: - production writes - credential administration approval: session_owner: employee-ops-owner per_call_owner: employee-platform-owner credential_routes: - search-api-read-route - bastion-diagnostic-route revocation_owner: employee-platform-owner verification_owner: employee-security-owner ``` Der Eintrag trennt Dinge, die häufig unter einem einzigen Etikett zusammengefasst werden. `contractor_operator` ist nicht `sponsor`. `session_owner` ist nicht unbedingt `per_call_owner`. `revocation_owner` ist nicht die Person, die entschieden hat, dass die Arbeit nötig ist. Diese Trennung verhindert, dass der Auftragnehmer seine eigene Ausweitung der Berechtigungen faktisch genehmigt. Sie verhindert auch, dass ein abwesener Manager zur einzigen Person wird, die den Zugriff stoppen kann. Das Feld `permitted_actions` sollte Verben und Ziele verwenden. «Nur Lesen» ist zu ungenau, wenn ein Service Endpunkte besitzt, die Exporte auslösen, personenbezogene Daten offenlegen oder Kapazität verbrauchen. Auch «Produktions-Lesezugriff» muss sorgfältig verstanden werden. Ein Lesezugriff kann regulierte Daten oder betriebliche Details offenlegen, die einen Angriff erleichtern. Setze ein Ablaufdatum, auch wenn der Vertrag kein genaues Enddatum hat. Verlängere den Zugriff durch eine neue Entscheidung, wenn die Arbeit weitergeht. Eine ausdrückliche Verlängerung zwingt den Sponsor zu prüfen, ob der Produktionszugriff noch benötigt wird und ob der ursprüngliche Prozess noch verwendet wird. ## Auditaufzeichnungen müssen betriebliche Fragen beantworten Ein Audittrail für Agentenarbeit muss zeigen, wer die Aktion autorisiert hat, welcher Prozess sie angefordert hat, welches Ziel sie erreichte, ob sie erfolgreich war und wann die Berechtigung widerrufen wurde. Ein Chatverlauf kann das nicht zuverlässig leisten. Halte nach Möglichkeit zwei Ansichten vor. Eine folgt dem Agentenlauf oder der Sitzung, damit ein Ermittler den Autorisierungslebenszyklus sehen und einen laufenden Lauf stoppen kann. Die andere folgt einzelnen Aktionen, damit ein Bediener einen bestimmten API-Aufruf oder SSH-Befehl prüfen kann. Verknüpfe beide Ansichten mit demselben zugrunde liegenden Ereigniseintrag, statt getrennte Geschichten manuell zu führen. Schütze das Auditprotokoll vor dem Prozess, den es aufzeichnet. Ein Prozess, der seine eigene Historie ändern kann, kann die wichtigsten Nachweise verbergen. Nur anhängbare Speicherung, eingeschränkter Schreibzugriff und kryptografische Verkettung helfen dabei, aber jedes Verfahren hat eine eigene Aufgabe. Eine Kette kann zeigen, dass Aufzeichnungen verändert oder entfernt wurden. Sie kann nicht sagen, ob die ursprüngliche Anfrage eine gute Idee war. Sallyport führt Sitzungs- und Aktivitätsjournale, die aus einem verschlüsselten, hashverketteten Auditprotokoll abgeleitet werden. Mit `sp audit verify` lässt sich die Kette offline über dem Chiffretext prüfen. Das ist nützlich, wenn der Rechner mit dem Tresor gesperrt ist oder ein Ermittler die Geheimnisse selbst nicht lesen sollte. Lege für jeden Auftrag fest, wer die Aufzeichnungen wann prüft. Ein sensibler Produktions-Write kann eine Prüfung erfordern, bevor der Auftragnehmer weiterarbeitet. Eine kurze Diagnoseaufgabe braucht vielleicht nur eine Prüfung beim Abschluss. Das Team muss trotzdem wissen, wie es die Ereignisse während eines Vorfalls findet. Bewahre auch Ablehnungen auf. Eine abgelehnte Aktion kann zeigen, dass der Agent seinen Umfang überschreiten wollte, dass ein Auftragnehmer die Aufgabe missverstanden hat oder dass nach dem Offboarding ein veralteter Prozess weiterläuft. Wenn du nur erfolgreiche Aufrufe behältst, verwirfst du die Nachweise, die den nächsten Vorfall oft erklären. ## Vertragstext und Zugriffskonzept müssen zusammenpassen Ein Vertrag kann ein API-Token nicht widerrufen. Er kann aber die Unklarheit beseitigen, die Teams dazu bringt, Zugriff zurückzulassen. Formuliere betriebliche Pflichten so, dass sie den tatsächlichen Kontrollen deines Teams entsprechen. Halte fest, dass das Unternehmen Zugangsdaten, Prozessregistrierungen, Auditaufzeichnungen und jede für den Auftrag erstellte Zugriffskonfiguration besitzt. Schreibe vor, dass der Auftragnehmer für Produktionsaktionen genehmigte, vom Unternehmen kontrollierte Pfade verwendet und keine Zugangsdaten in lokale Dateien, Prompts, Repositorys oder Drittanbieterdienste kopiert. Wenn die Arbeit eine Ausnahme erfordert, muss der Sponsor diese Ausnahme vor ihrem Eintreten schriftlich genehmigen. Nimm eine Verpflichtung zur Rückgabe und Löschung von Arbeitsmaterialien auf, verlasse dich aber nicht auf eine Bestätigung als einzige Kontrolle. Auftragnehmer können in gutem Glauben handeln und trotzdem eine Shellhistorie, eine zwischengespeicherte Umgebungsvariable oder ein Backup übersehen. Technischer Widerruf erledigt, was du kontrollieren kannst. Vertragsbedingungen decken Pflichten ab, die außerhalb deiner Systeme bleiben. Definiere das Ende des Auftrags operativ: Der Sponsor schließt die Arbeit, der technische Verantwortliche deaktiviert die Aktionspfade, der Prüfverantwortliche bestätigt den Ablehnungstest, und das Team bewahrt das Auditprotokoll nach den üblichen Aufbewahrungsregeln auf. Wenn der Auftragnehmer später erneut Supportzugriff braucht, eröffne einen neuen Auftrag, statt den alten wiederzubeleben. Vermeide Klauseln, nach denen der Auftragnehmer «für die Sicherheit verantwortlich» ist, ohne Entscheidungen und Kontrollen zu benennen. Diese Formulierung klingt streng, lässt aber die entscheidenden Fragen offen, wenn jemand um 18 Uhr eine Produktionsänderung verlangt. Schreibe fest, wer die Änderung genehmigen darf, wer sie durchführt und wer sie stoppen kann. Das erste Dokument, das du vorbereiten solltest, ist keine umfassende KI-Richtlinie. Es ist der Auftragseintrag für den nächsten Auftragnehmer, der einen Agenten in die Nähe der Produktion bringen muss. Fülle ihn gemeinsam mit Sponsor und technischem Verantwortlichen aus. Jedes leere Feld zeigt direkt auf Arbeit, die dein Team vor der Zugriffserteilung noch erledigen muss.