# Genehmigung pro Sitzung oder pro Aufruf für Agent-Aktionen

Ein KI-Agent braucht keinen uneingeschränkten Zugriff, um nützlich zu sein. Er braucht für die aktuelle Aufgabe genügend Berechtigungen, für einen nachvollziehbaren Zeitraum und mit einer menschlichen Entscheidung genau an der Stelle, an der ein weiterer Aufruf das Risiko verändern würde. Das ist der praktische Unterschied zwischen einer Genehmigung pro Sitzung und einer Genehmigung pro Aufruf.

Ich habe erlebt, dass Teams zwei entgegengesetzte Fehler machen. Die einen genehmigen jede harmlose Abfrage und bringen Menschen dazu, Warnungen ungelesen wegzuklicken. Die anderen geben einem Coding-Agenten eine langlebige Sitzung und sind dann überrascht, wenn eine Schleife fünfzig Tickets anlegt, mehrere Deployments auslöst oder weit mehr Daten exportiert als beabsichtigt. Keiner dieser Fehler braucht einen exotischen Exploit. Beide entstehen, weil die Genehmigungsgrenze an der falschen Stelle liegt.

Die zentrale Suchphrase **Genehmigung pro Sitzung vs. pro Aufruf** beschreibt eine Entscheidung, für die drei Informationen nötig sind: Wie lange läuft die Aufgabe, wie weit reichen die Berechtigungen der Zugangsdaten und was kann ein wiederholter gültiger Aufruf bewirken? Das HTTP-Verb, der behauptete Plan des Agenten und die Tatsache, dass ein Entwickler zusieht, sind schwächere Signale als diese drei Punkte.

## Eine Genehmigung erlaubt Aktionen innerhalb einer festgelegten Grenze

Eine Genehmigung pro Sitzung gibt einem identifizierten Agent-Prozess die Berechtigung, Zugangsdaten für die Dauer dieses Laufs zu verwenden. Bei einer Genehmigung pro Aufruf wird jedes Mal eine Entscheidung verlangt, wenn diese Zugangsdaten verwendet werden. Beide Varianten beantworten unterschiedliche Fragen. Wer sie gleich behandelt, erzeugt entweder blindes Vertrauen oder unnötige Reibung.

Eine Sitzungsentscheidung sagt: «Ich erkenne diesen Prozess, akzeptiere diesen begrenzten Lauf und halte die über diese Zugangsdaten verfügbaren Aktionen für sicher genug, um sie während dieses Laufs zu wiederholen.» Das ist eine vernünftige Entscheidung für einen Agenten, der bei der Fehlersuche einige Issue-Datensätze prüft. Für einen Agenten, der Produktionsänderungen vornehmen kann, sobald seine eigene Überlegung eine weitere Mutation für sinnvoll hält, ist sie schlecht.

Eine Aufrufentscheidung sagt: «Ich akzeptiere genau diese Nutzung dieser Zugangsdaten jetzt.» Sie ist absichtlich langsamer. Die Eingabeaufforderung sollte an einem Punkt erscheinen, an dem eine Person die Folge erkennen und ablehnen kann, ohne die gesamte Aufgabe zu verlieren. Wenn die Aufforderung keine echte Wahl vermittelt, ist das Genehmigungsdesign falsch. Erscheint sie vor einer irreversiblen Aktion, ist die zusätzliche Sekunde meist gut investiert.

Verwechseln Sie das nicht mit Authentifizierung. Die Authentifizierung teilt dem lokalen System mit, wer den Zugangsdaten-Tresor entsperren darf. Die Autorisierung beantwortet die Frage, ob ein Agent-Lauf bestimmte Zugangsdaten verwenden darf. Die Kontrolle pro Aufruf fügt eine dritte Frage hinzu: Verdient diese Nutzung in diesem Moment eine neue menschliche Entscheidung?

Das ist auch bei einer gewöhnlichen Coding-Aufgabe wichtig. Ein Agent kann ein API-Token verwenden, um den Build-Status zu lesen, und ein anderes, um ein Release auszulösen. Derselbe Prozess kann vertrauenswürdig genug sein, um das erste Token zu verwenden, und für das zweite trotzdem eine ausdrückliche Entscheidung benötigen. Die Identität des Prozesses macht das Risiko der erreichbaren Endpunkte nicht gleich.

Eine gute Genehmigungsgrenze hat vier Eigenschaften:

- Eine Person kann sagen, welche Arbeit der Agent erledigt.
- Der Berechtigungsumfang der Zugangsdaten passt zu dieser Arbeit und nicht zur gesamten möglichen Aufgabenliste des Agenten.
- Die Genehmigung endet, wenn die Arbeit oder der identifizierte Prozess endet.
- Die Person kann das schlimmste plausible Ergebnis beschreiben, falls der Agent eine erlaubte Aktion wiederholt.

Die vierte Eigenschaft deckt mehr schlechte Designs auf als die meisten Checklisten. Lautet die Antwort «Er würde nur eine weitere harmlose Anfrage stellen», kann eine Sitzungsgenehmigung passen. Umfasst die Antwort Geld, Kundenkommunikation, Produktionszustand, Löschung, Zugriffsänderungen oder einen großen Export, sollte die menschliche Entscheidung nahe an jeder Aktion bleiben.

## Die Aufgabendauer verändert die Bedeutung eines Sitzungsversprechens

Eine Sitzung ist am sichersten, wenn sie kurz und auf eine einzelne Aufgabe begrenzt ist und an einen Prozess gebunden bleibt, der nach Abschluss der Aufgabe endet. Eine Sitzung, die unbemerkt für andere Arbeiten weiterläuft, ist eine dauerhafte Berechtigung mit einem freundlicheren Namen.

Die Dauer beeinflusst das Risiko, weil ein Agent nach seiner ersten geplanten Aktion nicht aufhört zu überlegen. Er kann es erneut versuchen, eine neu entdeckte Teilaufgabe verfolgen, ein anderes Repository untersuchen oder einer schädlichen Anweisung folgen, die er aus einer Datei oder einem Ticket gelesen hat. Je länger der Prozess lebt, desto weniger nützlich wird das ursprüngliche mentale Modell. Ein zehnminütiger Lauf zur Untersuchung fehlschlagender Tests hat einen verständlichen Zweck. Ein Prozess, der den ganzen Nachmittag läuft, sammelt Kontext, ändert Ziele und hat mehr Gelegenheiten, auf feindselige oder irreführende Eingaben zu stoßen.

Nutzen Sie möglichst die Aufgabengrenze statt einer Uhr. Das Ende des Prozesses ist eine ehrliche Endbedingung: Der genehmigte Agent ist nicht mehr da. Ein festes Timeout ist ein Ersatz, aber keine gleichwertige Kontrolle. Nach fünfzehn Minuten kann ein Agent noch an der ursprünglichen Aufgabe arbeiten, oder ein anderes Tool kann dieselben Berechtigungen übernommen haben. Die Zeit allein verrät nicht, welcher Fall vorliegt.

Beschreiben Sie bei einer begrenzten Sitzung die Arbeitseinheit, bevor Sie sie genehmigen. Eine gute Beschreibung ist konkret: «Den fehlgeschlagenen Continuous-Integration-Lauf untersuchen und einen Entwurfskommentar mit den Ergebnissen öffnen.» Eine schlechte Beschreibung ist «Beim Release helfen». Eine breite Formulierung gibt dem Agenten Raum, aus einer kleinen Diagnoseaufgabe Release-Arbeit zu machen.

Berücksichtigen Sie diese Aufgabenformen:

| Aufgabenform | Eignung für Sitzungsgenehmigung | Warum |
| --- | --- | --- |
| Während eines Agent-Laufs eine festgelegte Menge von Build-Logs lesen | Meist gut | Der Prozess endet, die Datenmenge ist begrenzt und der entfernte Zustand sollte sich nicht ändern. |
| Interne Dokumentation durchsuchen, während ein Patch vorbereitet wird | Oft gut | Die Zugangsdaten können eng begrenzt sein und die erwarteten Operationen sind wiederholte Lesevorgänge. |
| Einen Produktionsalarm analysieren | Bedingt | Lesezugriff kann über eine Sitzung laufen; jede Änderung zur Behebung braucht eine eigene Entscheidung. |
| Eine Migration ausführen | Meist schlecht | Der Agent kann viele zustandsverändernde Anfragen senden, und Wiederholungen können einen zweiten Migrationspfad anlegen. |
| Ein gemeinsames Postfach oder ein Kundenkonto verwalten | Schlecht | Jede gesendete, bearbeitete oder exportierte Information kann eine externe Verpflichtung erzeugen oder private Daten offenlegen. |

Die beliebte Abkürzung lautet, jede Aufgabe über eine Sitzung zu genehmigen, weil Menschen Unterbrechungen hassen. Die Beschwerde ist berechtigt, wenn Eingabeaufforderungen bei Aktionen mit geringen Folgen erscheinen. Die Lösung besteht darin, die Zahl der Aufforderungen durch engere Zugangsdaten und echte Gruppierung routinemäßiger Arbeit in Sitzungen zu reduzieren, nicht darin, einen langen Agent-Lauf in ein Fenster mit Vollzugriff zu verwandeln.

Auch bei Neustarts eines Agenten ist Vorsicht angebracht. Für die Person, die den Befehl gestartet hat, kann ein Neustart wie eine Fortsetzung aussehen. Es handelt sich jedoch um einen neuen Prozess, der andere Anweisungen, anderen Code oder andere Plugins laden kann. Fordern Sie nach einem Neustart eine neue Sitzungsgenehmigung an. Das ist keine Bürokratie. Die ursprüngliche Entscheidung galt einer bestimmten ausführbaren Berechtigung und einem bestimmten Lauf, nicht der vagen Absicht des Entwicklers für den Nachmittag.

## Die Sensibilität von Zugangsdaten beginnt bei ihren Fähigkeiten, nicht bei ihrem Geheimnistyp

Zugangsdaten sind wegen dessen sensibel, was sie bewirken, offenlegen oder delegieren können, nicht wegen ihres Namens. Ein API-Schlüssel, der nur zum Lesen eines öffentlichen Build-Artefakts dient, kann weniger gefährlich sein als ein Token, das Administratoren Zugriff auf einen privaten Arbeitsbereich gibt. Ein SSH-Schlüssel mit Zugriff auf einen Deployment-Host hat einen anderen Fehlermodus als ein Token für eine Billing-API. Beide können jedoch eine Genehmigung pro Aufruf benötigen.

Ordnen Sie jede Zugangsdatenart anhand der tatsächlichen Berechtigungen des entfernten Systems ein. Akzeptieren Sie keine Bezeichnung wie «Read-Token», ohne zu prüfen, was die API als Lesen betrachtet. Manche Dienste stellen Export-Endpunkte als Lesevorgänge bereit. Andere erlauben einem angeblich schreibgeschützten Endpunkt, die Erstellung eines Berichts zu starten, knappe Kapazitäten zu verbrauchen oder Daten zurückzugeben, die der Agent niemals in großer Menge sehen sollte.

Vor der Wahl einer Genehmigungsstufe stelle ich vier Fragen:

1. Können diese Zugangsdaten außerhalb des lokalen Rechners den Zustand verändern?
2. Können sie Informationen offenlegen, die nicht sicher in den Kontext oder die Ausgabe des Agenten gelangen dürfen?
3. Können sie direkt oder über einen auslösbaren Ablauf weitere Zugriffsrechte vergeben?
4. Kann ein Aufrufer Geld ausgeben, ein Kontingent verbrauchen oder eine vertragliche beziehungsweise reputationsbezogene Verpflichtung erzeugen?

Eine positive Antwort zwingt nicht immer zu einer Genehmigung pro Aufruf. Sie bedeutet aber, dass eine Sitzungsgenehmigung eine engere Aufgabe, einen kleineren Berechtigungsumfang und einen plausiblen Rollback braucht. Sind mehrere Antworten positiv, ist die Genehmigung bei jeder Nutzung meist die ehrlichere Wahl.

Reduzieren Sie zuerst den Berechtigungsumfang und setzen Sie die Genehmigung erst danach ein. Ein Token, das nur ein einzelnes Repository lesen kann, ermöglicht eine deutlich bessere Sitzungsentscheidung als ein Token, das jedes Repository der Organisation liest. Zugangsdaten für eine einzelne Staging-Umgebung sind einer Sitzung eher anzuvertrauen als Zugangsdaten für die Produktion. Menschliche Genehmigung kann ein absurd breit gefasstes Token nicht reparieren, sobald der Agent damit teure Anfragen stellen kann.

SSH verdient besondere Aufmerksamkeit, weil Menschen es routinemäßig als «nur Shell-Zugriff» bezeichnen. Shell-Zugriff ist ein Transportweg zu einer großen und veränderlichen Aktionsfläche. Das tatsächliche Risiko hängt vom Konto, Host, der Netzwerkerreichbarkeit, den verfügbaren Befehlen, Deployment-Hooks und den lesbaren Dateien ab. Ein eingeschränktes Konto, das einen einzelnen Diagnosebefehl ausführen kann, kann für eine Sitzung geeignet sein. Ein Deployment-Konto, ein Host mit Kundendaten oder ein Konto, das Zugriffskontrollen ändern kann, sollte hinter einer Genehmigung pro Aufruf bleiben, bis Sie es weiter einschränken können.

Lassen Sie diese Analyse nicht durch die Rotation von Zugangsdaten aus dem Blick geraten. Ein frisch erzeugter Schlüssel mit weitreichenden Produktionsrechten hat weiterhin weitreichende Produktionsrechte. Nach einem schlechten Lauf begrenzt die Rotation den künftigen Missbrauch, aber sie macht die bereits erfolgreich ausgeführten entfernten Aufrufe nicht rückgängig.

## Wiederholung macht aus einer tolerierbaren Aktion eine kostspielige

Eine Anfrage kann einzeln akzeptabel sein und trotzdem unsicher werden, wenn ein Agent sie wiederholt. Bewerten Sie die wiederholte Aktion und nicht nur die erste Aktion, die in einer Eingabeaufforderung angezeigt wird.

Hier verlassen sich Teams zu stark auf Namen von HTTP-Methoden. RFC 9110 sagt, dass sichere Methoden für Lesevorgänge gedacht sind: GET, HEAD, OPTIONS und TRACE. Der Standard warnt auch, dass ein Client nicht dafür verantwortlich gemacht werden kann, wenn ein Server über eine sichere Methode unsicheres Verhalten anbietet, weil der Eigentümer der Ressource dieses Verhalten bestimmt. Diese Formulierung ist wichtig. Ein GET-Endpunkt kann semantisch zum Abrufen von Informationen gedacht sein, während die Anwendung ihn teuer macht, einen umfangreichen Export offenlegt, ein Audit-Feld aktualisiert oder nachgelagerte Arbeit auslöst. Methodennamen helfen beim Beginn einer Untersuchung. Sie ersetzen sie nicht.

Auch der Begriff Idempotenz wird häufig falsch verwendet. Eine Anfrage ist idempotent, wenn ihre Wiederholung dieselbe beabsichtigte Wirkung auf den Serverzustand hat wie ihre einmalige Ausführung. Das bedeutet nicht, dass eine Wiederholung harmlos ist. Eine PUT-Anfrage, die ein Flag auf `true` setzt, kann idempotent sein und trotzdem eine Produktionsfunktion aktivieren. Ein DELETE kann nach der ersten Löschung idempotent sein und trotzdem etwas Wichtiges entfernen. Ein GET kann im Sinne des Protokolls sicher sein und bei einer Schleife des Agenten dennoch ein Ratenlimit aufbrauchen.

Testen Sie das Wiederholungsverhalten eines Endpunkts in einem Wegwerfkonto oder einer Staging-Umgebung. Senden Sie dieselbe Anfrage zweimal, prüfen Sie den entfernten Zustand und die Seiteneffekte und fragen Sie anschließend, was passiert, wenn der Agent sie hundertmal sendet. Bleiben Sie nicht beim Antworttext stehen. Prüfen Sie gesendete Nachrichten, eingereiht Jobs, erzeugte Audit-Datensätze, verbrauchte Kontingente, ausgelöste Webhooks und an andere Orte kopierte Daten.

Verwenden Sie bei einem Endpunkt, der Objekte erstellt, einen Idempotenzschlüssel, wenn der Dienst dies unterstützt. Diese Anfrageform verhindert, dass ein Netzwerk-Retry eine zweite Zahlung, ein zweites Ticket oder eine zweite Bereitstellungsanfrage erzeugt, wenn die erste Antwort verloren geht:

```http
POST /v1/provisioning-requests HTTP/1.1
Authorization: Bearer injected-by-gateway
Idempotency-Key: agent-run-8b2f1-request-17
Content-Type: application/json

{"environment":"staging","version":"2025.04.18"}
```

Ein Dienst sollte das ursprüngliche Ergebnis zurückgeben, wenn er denselben Idempotenzschlüssel erneut erhält. Die Antwort enthält häufig dieselbe Objektkennung und einen Erfolgsstatus statt eines neuen Objekts. Bestätigen Sie dieses Verhalten in der Dokumentation des Dienstes und testen Sie es selbst. Ein Idempotenzschlüssel reduziert doppelte Erstellung durch Wiederholungen. Er macht jedoch kein unpassendes Deployment passend und hindert einen Agenten nicht daran, für jeden fehlgeleiteten Versuch einen neuen Schlüssel zu erzeugen.

Eine Genehmigung pro Aufruf passt zu Aktionen mit einem dieser Wiederholungsprofile:

- Jeder Aufruf erstellt etwas Neues, zum Beispiel eine Rechnung, ein Konto, ein Ticket, eine Nachricht oder eine Bestellung.
- Jeder Aufruf verändert den Live-Zustand und der vorherige Zustand lässt sich nur schwer rekonstruieren.
- Jeder Aufruf kann eine weitere Seite, ein weiteres Archiv oder Daten eines weiteren Kunden offenlegen.
- Jeder Aufruf kann eine öffentliche oder kundenbezogene Wirkung erzeugen.
- Jeder Aufruf kann kostenpflichtige Arbeit auslösen oder knappe Kapazitäten belegen.

Eine Sitzung eignet sich für wiederholte Aufrufe, wenn die entfernte Seite Wiederholungen als folgenarm behandelt, der Berechtigungsumfang klein ist und die Aufgabe ein klares Ende hat. Das Team muss diese Aussage belegen können. «Der Agent wird wahrscheinlich keine Schleife bilden» ist keine Eigenschaft des Endpunkts.

## Ein Nur-Lese-Label entscheidet das Risiko nicht

Lesezugriff kann Datenschutz-, Betriebs- und Prompt-Injection-Risiken erzeugen, selbst wenn er keinen entfernten Datensatz verändert. Behandeln Sie die Datenoffenlegung als Aktion mit Folgen, besonders wenn der Agent die abgerufenen Daten zusammenfassen, kopieren oder für seine nächste Entscheidung verwenden kann.

Angenommen, ein Agent darf ein Supportsystem durchsuchen. Eine Sitzung kann für eine auf ein Ticket und seine Anhänge begrenzte Aufgabe angemessen sein. Dieselben Zugangsdaten sind für einen Lauf, der jedes Ticket auflisten, Exporte abrufen oder private Kundengespräche in einen lokalen Kontext laden kann, viel schwerer zu genehmigen. Der Endpunkt mag durchgehend GET verwenden. Die Datengrenze und nicht das Verb bestimmt das Risiko.

Die unangenehme Frage lautet, ob der Agent das zurückgegebene Ergebnis überhaupt sehen darf. Ein Zugangsdaten-Gateway, das Tokens vom Agenten fernhält, macht nicht automatisch jedes Ergebnis sicher. Geheimnisse gelangen häufig über Antworten nach außen: Konfigurationsendpunkte geben Verbindungszeichenfolgen zurück, Benutzerdatensätze enthalten personenbezogene Daten, die Befehlsausgabe enthält Umgebungsvariablen und Fehlermeldungen legen interne Pfade oder Kennungen offen.

Wählen Sie bei einem Lesevorgang eine Genehmigung pro Aufruf, wenn ein einzelnes Ergebnis eine sensible Informationsklasse offenlegen kann oder wenn die Anfrage des Agenten seinen eigenen Suchraum erweitern kann. Dazu gehören breite Suchen, Exporte, das Abrufen von Geheimnissen, das Auflisten von Konten und Befehle wie `cat` über Verzeichnisse mit veränderlichem Inhalt. Eine Person braucht die Möglichkeit, das Ziel zu sehen, bevor diese Daten in den Lauf gelangen.

Beschränken Sie bei routinemäßigen Lesevorgängen die Form der Anfrage. Bevorzugen Sie Zugangsdaten, die auf ein Projekt, ein Repository, eine Umgebung oder eine API-Ressourcengruppe begrenzt sind. Legen Sie serverseitige Seitenlimits fest, sofern der Dienst sie anbietet. Geben Sie dem Agenten nach Möglichkeit eine Suchfunktion, die konkrete Kennungen akzeptiert, statt eines uneingeschränkten Suchendpunkts. Diese Entscheidungen reduzieren die Zahl der Genehmigungsaufforderungen, weil der erlaubte Aufruf selbst kleiner ist.

Ein typisches Fehlermuster zeigt sich bei der Reaktion auf Vorfälle. Ein Agent beginnt mit einer harmlosen Anfrage, um Logs zu prüfen, findet eine Zugangsdatenzeile im Log und sucht anschließend in einem umfangreichen Archiv nach jedem Vorkommen dieses Tokens. In der Vorstellung des Menschen bezog sich die ursprüngliche Sitzungsgenehmigung auf die Fehlersuche, doch Berechtigungsumfang und Abfrageform erlaubten eine Sammlung. Der Betreiber sieht keine Änderung in der Aktivitätsliste und hält den Lauf für sicher. Die sensible Aktion war das Abrufen der Daten.

Führen Sie getrennt Buch darüber, was angefordert wurde, welche Zugangsdaten verwendet wurden und ob der Aufruf als Sitzungsaktion oder pro Aufruf genehmigt war. Diese Aufzeichnung hilft einem Ermittler, einen kompromittierten Agenten von einer schlechten Genehmigungsentscheidung zu unterscheiden. Sie zeigt außerdem, welche Zugangsdaten einen kleineren Umfang brauchen. Wer nur erfolgreiche Änderungen protokolliert, lässt die schwierigsten Fehler beim Abrufen unsichtbar.

## Eingabeaufforderungen müssen Entscheidungen entsprechen, die Menschen tatsächlich treffen können

Genehmigungsmüdigkeit ist ein Designfehler, wenn Aufforderungen so häufig oder so vage erscheinen, dass sie nicht gelesen beziehungsweise bewertet werden. Eine Genehmigung pro Aufruf funktioniert nur, wenn jede Aufforderung dem Prüfer genug Informationen gibt, um eine konkrete Folge anzunehmen oder abzulehnen.

Eine brauchbare Aufforderung nennt den aufrufenden Prozess, die Zugangsdaten oder Aktionskategorie, das Ziel und die wesentliche Wirkung. «API-Anfrage erlauben» ermöglicht keine gute Entscheidung. «Signierter Agent-Prozess fordert mit den Release-Zugangsdaten ein Produktions-Deployment an» schon. Bei einem sensiblen Lesevorgang sollte die Aufforderung den Datensatz oder das Ziel nennen und nicht nur «GET-Anfrage». Bei SSH sollten Host und Befehl oder eine sinnvolle Befehlsklasse angezeigt werden.

Versuchen Sie nicht, die Überlastung durch Aufforderungen zu lösen, indem Sie das Ziel verbergen. Ein Entwickler, der eine Anfrage anhand eines freundlichen Aufgabennamens genehmigt, kann keinen Tippfehler, keine schädliche Anweisung und keinen Kurswechsel des Agenten erkennen. Die Aufforderung braucht genug Details, um eine Abweichung zwischen geplanter Arbeit und tatsächlicher Aktion zu bemerken.

Gleichzeitig sollten Menschen nicht bei jeder routinemäßigen Anfrage einen rohen HTTP-Body analysieren müssen. Das erzeugt bloß zeremonielle Genehmigungen. Bündeln Sie wiederholte, folgenarme Aufrufe in einer begrenzten Sitzung und reservieren Sie Genehmigungen pro Aufruf für Vorgänge, die eine echte Entscheidungsgrenze überschreiten. Die Person sollte weniger Aufforderungen sehen, aber jede verbleibende sollte wichtig sein.

Halten Sie neben jeder Konfiguration von Zugangsdaten eine kurze Genehmigungsnotiz fest. Sie ist keine Richtliniensprache und muss auch keine werden. Ein Satz wie «Nur Sitzung für Lesevorgänge zum Build-Status eines Repositorys; jedes Produktions-Release einzeln genehmigen» macht spätere Prüfungen konkret. Wenn ein Team keinen Satz schreiben kann, der gewöhnliche Arbeit von einer folgenreichen Aktion trennt, sind die Zugangsdaten wahrscheinlich zu weit gefasst.

Auch die bei der Sitzungsgenehmigung angezeigte Prozessidentität verdient Aufmerksamkeit. Menschen sollten die ausführbare Berechtigung genehmigen und nicht nur eine kopier- oder veränderbare Befehlszeile. Ein signierter übergeordneter Prozess und ein unsignierter Helfer sind unterschiedliche Vertrauensentscheidungen. Die richtige Reaktion auf eine unbekannte Berechtigung besteht darin, den Lauf anzuhalten, die Änderung zu klären und sie nur zu genehmigen, wenn sie erwartet wurde. Wer wegen Zeitdrucks klickt, bringt der Organisation bei, einen Weg zur Identitätsvortäuschung zu akzeptieren.

## Verwenden Sie vor der Einstellung eine Entscheidungsmatrix

Eine kleine Matrix verhindert Diskussionen, die auf der persönlichen Toleranz für Eingabeaufforderungen beruhen. Bewerten Sie die Aktion nach ihren Folgen und wählen Sie die strengere Stufe, wenn die Bewertung in zwei Richtungen weist.

| Frage | Spricht für Genehmigung pro Sitzung | Spricht für Genehmigung pro Aufruf |
| --- | --- | --- |
| Wie lange lebt dieser Lauf? | Eine begrenzte Aufgabe, die mit dem Ende des Prozesses endet | Lang laufende, neu gestartete, geplante oder unklar definierte Arbeit |
| Was können die Zugangsdaten erreichen? | Ein einzelnes, eng begrenztes Projekt oder eine Umgebung | Produktion, viele Mandanten, privilegierte Konten oder umfangreiche Exporte |
| Was bewirkt ein Aufruf? | Er ruft begrenzte Routinedaten ab oder nimmt eine reversible Änderung mit geringen Folgen vor | Er sendet, löscht, veröffentlicht, provisioniert, deployt, ändert Zugriff oder überträgt Werte |
| Was bewirkt eine Wiederholung? | Wiederholungen haben geringe Folgen und serverseitige Kontrollen verhindern doppelte Effekte | Jeder Aufruf verursacht Kosten, erzeugt ein weiteres Objekt oder erweitert die Offenlegung |
| Kann ein Betreiber die Aktion rückgängig machen? | Ein klarer Rollback ist vorhanden und Datenverlust unwahrscheinlich | Der Rollback ist unvollständig, teuer oder unmöglich |

Wenn die Tabelle gemischte Antworten liefert, trennen Sie den Ablauf, statt einen Kompromiss zu erzwingen. Geben Sie dem Agenten für die Diagnose Zugangsdaten mit Sitzungsgenehmigung und für die Behebung Zugangsdaten mit Genehmigung pro Aufruf. Das wirkt oft natürlicher, als wiederholt Lesevorgänge zu genehmigen oder eine breite Sitzung zu gewähren, um Genehmigungen für Änderungen zu vermeiden.

Hier ein Beispiel. Ein Agent untersucht ein fehlgeschlagenes Deployment. Er muss Build-Logs lesen, den Status einer bestimmten Staging-Umgebung abrufen und möglicherweise einen Dienst neu starten.

Logs und Statusabfragen können unter einer Sitzungsgenehmigung laufen, wenn das Token nur dieses Projekt erreicht und der Prozess nach der Diagnose endet. Der Neustart sollte andere Zugangsdaten mit Genehmigung pro Aufruf verwenden, weil er den laufenden Zustand verändert. Selbst wenn ein Neustart meist sicher ist, können wiederholte Neustarts aktive Arbeit unterbrechen, eine eigentliche Ursache verdecken und automatische Wiederherstellungsschleifen auslösen. Dass der Agent den Neustart als sinnvolle Lösung entdeckt hat, macht ihn nicht zur Routine.

Ändern Sie nun ein Detail: Die Status-API kann jede Produktionsumgebung abfragen, und der Log-Abruf kann unredigierte Kundendaten laden. Eine Sitzungsgenehmigung passt für die Diagnose-Zugangsdaten nicht mehr. Das Team sollte den Zugriff zuerst einschränken. Die breiten Zugangsdaten lediglich hinter eine Genehmigung pro Aufruf zu stellen, begrenzt eine bestimmte Fehlerart. Ein Prüfer kann jedoch nicht zuverlässig jede Abrufanfrage bewerten, wenn der Datenselektor uneingeschränkt bleibt.

Deshalb ist eine einzige Einstellung pro Agent ein schlechtes Modell. Die Genehmigung gehört zum Aktionskanal und zum Berechtigungsumfang der Zugangsdaten. Ein Agent-Lauf kann beide Stufen sicher kombinieren, wenn die Grenzen bewusst gezogen werden.

## Audit-Spuren erklären eine schlechte Entscheidung, können sie aber nicht rückgängig machen

Ein manipulationssicherer Datensatz ermöglicht es, einen Agent-Lauf zu untersuchen, eine aktive Sitzung zu widerrufen und festzustellen, ob der Agent eine Aktion wiederholt hat. Er hindert einen entfernten Dienst jedoch nicht daran, einen bereits genehmigten Aufruf anzunehmen.

Halten Sie zwei Aktivitätsansichten vor. Ein Sitzungsdatensatz beantwortet, wer den Lauf ausgeführt hat, wann er begann, welche Prozessberechtigung vorlag und ob jemand ihn widerrufen hat. Ein Aufrufdatensatz beantwortet, welchen Zugangsdatenpfad der Agent verwendete, welches Ziel er kontaktierte und ob der Aufruf über eine Sitzungsgenehmigung oder eine neue Genehmigung freigegeben wurde. Teams brauchen beides. Eine Sitzungsliste kann nicht beweisen, welche Aktion das Problem verursacht hat, während eine Ansammlung von Aufrufen ohne Prozesskontext nicht erklärt, wer sie gestartet hat.

Machen Sie die Integrität des Audits überprüfbar und nicht zu einem bloßen Schlagwort. Ein Hash-verkettetes Log sollte die Prüfung nicht bestehen, wenn jemand Datensätze in der gespeicherten Reihenfolge ändert, entfernt oder neu anordnet. Der Test ist einfach: Prüfen Sie eine bekannte Originalkopie, ändern Sie in einer Kopie ein Byte und prüfen Sie erneut. Der Prüfer sollte melden, dass die Kette nicht mehr valide ist, während die Originalkopie weiterhin erfolgreich geprüft wird. Führen Sie das in einem Test-Fixture durch, niemals durch Bearbeiten Ihres produktiven Audit-Speichers.

Sallyport erstellt seine Journals Sessions und Activity aus einem schreibgeschützten, verschlüsselten und Hash-verketteten Audit-Log. `sp audit verify` prüft diese Kette offline über dem Chiffretext, ohne einen Tresorschlüssel zu benötigen. Diese Trennung ist nützlich, wenn die Person, die Datensätze prüft, weder die vom Tresor geschützten Zugangsdaten noch die Aktionsdaten erhalten soll.

Logs machen außerdem einen häufigen Genehmigungsfehler sichtbar: eine Sitzung als Vorwand zu verwenden, nicht mehr hinzusehen. Prüfen Sie Läufe, die ungewöhnlich viele Aufrufe verwendeten, ein neues Ziel kontaktierten, deutlich länger als in der Aufgabenbeschreibung vorgesehen liefen oder Zugangsdaten außerhalb ihrer üblichen Kategorie verwendeten. Dafür brauchen Sie keine Regel-Engine. Eine wöchentliche menschliche Prüfung einer kleinen Stichprobe erkennt eine schleichende Ausweitung des Umfangs, bevor sie zur normalen Gewohnheit wird.

Wenn ein Agent sich schlecht verhält, sichern Sie Prozessidentität, Aufgabeneingabe, Sitzungsdatensatz, Aufrufsequenz und Logs des entfernten Dienstes, bevor Sie die Konfiguration ändern. Stellen Sie anschließend eine engere Frage als «Wurde der Agent kompromittiert?» War die Aktion durch den Berechtigungsumfang erlaubt? Passte die Genehmigungsstufe zum Wiederholungsrisiko? Lieferte die Aufforderung genug Informationen für eine Ablehnung? Hat sich der Prozess nach der Autorisierung geändert? Diese Antworten führen zu Verbesserungen. Ein allgemeines Verbot von Autonomie nicht.

## Ein enger Anfang ist besser als eine breite Ausnahme

Beginnen Sie mit einem Workflow, dessen Auswirkungen Sie ohne vage Formulierungen beschreiben können. Ordnen Sie den Zugangsdaten, die den größten Schaden verursachen können, zunächst eine Genehmigung pro Aufruf zu. Beobachten Sie mehrere reale Läufe, bevor Sie den routinemäßigen Teil in eine begrenzte Sitzung verschieben.

Bei einer Mac-basierten Agent-Konfiguration bewahrt Sallyport API- und SSH-Zugangsdaten in seinem verschlüsselten Tresor auf und führt die Aktion aus, statt das Geheimnis an den Agenten weiterzugeben. Das reduziert die Offenlegung der Zugangsdaten. Trotzdem müssen Sie die Genehmigungsgrenze mit derselben Sorgfalt wählen, denn die entfernte Aktion bleibt real.

Die erste Konfiguration sollte einen Entwickler leicht ungeduldig machen, nicht blind. Wenn jeder Lauf eine ganze Reihe von Aufforderungen für Build-Status-Abfragen erzeugt, müssen Umfang oder Aufgabengruppierung verbessert werden. Wenn ein Agent nach einer Genehmigung eine Stunde lang die Produktion verändern kann, ist die Sitzung zu breit. Passen Sie Zugangsdaten und Aufgabengrenze an, bevor Sie den Menschen aus dem Prozess nehmen.

Formulieren Sie die nächste Genehmigungsentscheidung in operativen Begriffen: Dieser signierte Prozess darf für diese Aufgabe bis zu seinem Ende diese folgenarmen Aufrufe ausführen. Diese anderen Zugangsdaten erfordern eine neue Entscheidung, weil jede Nutzung etwas verändern kann, das wir nicht ohne Weiteres rückgängig machen können. Dieser Satz gibt Prüfern unter Druck einen anwendbaren Maßstab. Alles Unklarere wird sich irgendwann in eine dauerhafte Ausnahme verwandeln.