# HTTP-Authentifizierung für KI-Agenten: Sichere Muster für Zugangsdaten

Ein KI-Agent sollte eine HTTP-Aktion anfordern können, ohne jemals die Zugangsdaten zu besitzen, die diese Aktion ermöglichen. Diese Regel ist wichtiger als die Frage, ob die Anfrage einen Bearer-Token, Basic Authentication oder einen Anbieter-Header verwendet. Sobald ein Geheimnis in den Agentenkontext gelangt, kann es über einen Prompt, eine Tool-Spur, einen erzeugten Shell-Befehl, eine Repository-Datei oder eine spätere Zusammenfassung durchsickern, die niemand aufbewahren wollte.

HTTP-Authentifizierungsmuster bleiben wichtig, weil jedes Muster beeinflusst, was gestohlen, wiederverwendet, versehentlich weitergeleitet und geprüft werden kann. Das richtige Design beginnt mit dem vom API verlangten Verfahren. Danach wird die Zugangsinformation auf einen vertrauenswürdigen Executor begrenzt, der im Namen des Agenten eine eng definierte Anfrage sendet.

## Agenten verwandeln gewöhnliche Zugangsdaten in kopierbare Daten

Ein unbeaufsichtigter Agent erhöht das Risiko eines ansonsten normalen API-Zugangsmittels, weil er so viele Formen von Text liest und schreibt. Ein Entwickler bewahrt einen Token vielleicht in einem lokalen Zugangsdaten-Speicher auf und fügt ihn in eine einzelne Anfrage ein. Ein Agent kann Umgebungsvariablen prüfen, Debug-Ausgaben schreiben, einen curl-Befehl zusammenstellen, Konfigurationsdateien anlegen und einem Menschen über seine Arbeit berichten. Jeder dieser Vorgänge schafft einen weiteren Ort, an dem ein wiederverwendbares Geheimnis landen kann.

Der gefährliche Ablauf wirkt anfangs oft harmlos:

1. Ein Task-Runner legt `PAYMENTS_TOKEN` in der Prozessumgebung des Agenten ab.
2. Der Agent führt einen Diagnosebefehl aus, der seine Umgebung ausgibt oder ein Shell-Skript schreibt.
3. Das Skript gelangt in ein Repository, ein CI-Artefakt, den Terminalverlauf oder einen weiteren Agenten-Toolaufruf.
4. Jemand findet den Token später und sendet gültige Anfragen, bis er abläuft oder ein Administrator ihn widerruft.

Der Token musste keinem besonders raffinierten Angreifer in die Hände fallen. Er musste nur an einer Stelle zu Text werden, die dafür gedacht ist, Text zu kopieren.

Verwechseln Sie Zugriffskontrolle für den Agenten nicht mit der Vertraulichkeit von Zugangsdaten. Eine Sandbox kann verhindern, dass ein Agent Dateien außerhalb eines Verzeichnisses öffnet. Das hilft nicht, wenn das Geheimnis bereits im Modellkontext, in Befehlsargumenten oder in einem Tool-Ergebnis auftaucht. Ebenso sagt eine Freigabeaufforderung, die fragt, ob der Agent `curl` ausführen darf, wenig aus, wenn der Agent Host, Pfad, Body und geerbten Authorization-Header frei bestimmen kann.

Darum braucht HTTP-Authentifizierung für KI-Agenten zwei getrennte Grenzen. Der Agent benötigt die Erlaubnis, eine Anfrage vorzuschlagen. Eine vertrauenswürdige Komponente muss die Zugangsdaten verwahren und die Anfrage senden dürfen. Werden diese Grenzen zusammengelegt, erhält der Agent ein kopierbares Geheimnis. Spätere Kontrollen hängen dann davon ab, dass der Agent perfekt damit umgeht. Das ist eine unvernünftige Annahme.

Ein einfacher Test hilft: Könnten Sie das vollständige Agentenprotokoll in ein Ticketsystem kopieren, ohne die Zugangsdaten zu widerrufen? Wenn die Antwort nein lautet, hat das Geheimnis die falsche Grenze überschritten.

## Bearer-Tokens sind einfach zu senden und leicht wiederzuverwenden

Ein Bearer-Token gewährt jedem Zugriff, der ihn vorlegt. Ein Agent darf ihn daher nur erhalten, wenn Sie akzeptieren, dass ein Protokoll-Leck zu einem API-Zugriffsleck werden kann. RFC 6750 beschreibt die Verwendung von Bearer-Tokens im `Authorization`-Request-Header:

```http
GET /v1/projects/alpha/releases HTTP/1.1
Host: api.example.test
Authorization: Bearer eyJhbGciOi...
Accept: application/json
```

Der Server muss nicht nachweisen, dass der Absender der vorgesehene Agent, der ursprüngliche Benutzer oder der ursprüngliche Rechner ist. Er prüft, ob der vorgelegte Token gültig und autorisiert ist. Dadurch bleiben HTTP-Clients einfach. Gleichzeitig macht diese Eigenschaft kopierte Tokens für jeden nützlich, der sie besitzt.

RFC 6750 erlaubt unter eingeschränkten Bedingungen, Bearer-Tokens in einem Form-Body zu senden, und beschreibt die Verwendung in URI-Abfragen für ältere Fälle. Legen Sie sie nicht in Query-Strings. URLs gelangen leichter als erwartet in den Browserverlauf, Proxy-Logs, Analysesysteme, Referrer-Header, Support-Tickets und Anwendungsprotokolle. Der Standard selbst warnt, dass der Transport in einer URI mit hoher Wahrscheinlichkeit zur Offenlegung führt. Es gibt keinen guten Grund, das Geheimnis eines Agenten zu einem Bestandteil einer URL zu machen.

Bearer-Tokens passen nur dann gut zu Agenten, wenn das umgebende Zugangsdaten-Design den Schaden begrenzt. Bevorzugen Sie Tokens mit einer vorgesehenen API-Zielgruppe, engen Berechtigungen, kurzer Gültigkeit und einer eigenen Identität für den ausführenden Dienst. Ein API-Token, der jedes Projekt verwalten, alle Kundendaten lesen kann und nie abläuft, ist ein Produktions-Hauptschlüssel mit freundlicherem Namen.

Das übliche Argument dafür, einem Agenten einen Bearer-Token zu geben, lautet Geschwindigkeit: eine Umgebungsvariable, ein HTTP-Client, keine zusätzliche Komponente. Im Demo funktioniert das, deshalb ist es beliebt. Sobald der Agent Debugging, Delegation, lang laufende Aufgaben oder Zugriff auf mehrere Dienste benötigt, scheitert das Modell. Ein in den Kontext kopierter Token lässt sich schwerer gezielt widerrufen, weil Sie nicht mehr wissen, an wie viele Stellen er gelangt ist.

Eine weitere Falle: Ein Token mit einem einschränkenden Namen kann trotzdem weitreichende tatsächliche Rechte besitzen. Lesen Sie die Dokumentation des Anbieters zum tatsächlichen Scope-Modell. Manche Dienste verwenden Endpunkt-Scopes. Andere vergeben Rechte auf Organisations-, Projekt-, Repository- oder Kontoebene. Einige API-Tokens übernehmen stillschweigend alle Rechte des Benutzers, der sie erstellt hat. Die Bezeichnung des Tokens sagt nichts über seine Begrenzung aus.

Ein Vermittler kann den Bearer-Token verwahren und den Header erst erstellen, nachdem er das gewünschte Ziel geprüft hat. Der Agent sollte Absicht und Anfragedaten übermitteln, etwa „Erstelle mit diesem Body ein Release im Projekt alpha“, nicht den eigentlichen `Authorization`-Header. Der Executor fügt das Geheimnis nach der Prüfung ein und entfernt es, bevor er irgendeinen Datensatz an den Agenten zurückgibt.

## Basic Authentication braucht eine eigene Dienstidentität

Basic Authentication kann für ein eng begrenztes Dienstkonto über TLS vertretbar sein. Sie eignet sich jedoch schlecht, um einem Agenten den Benutzernamen und das Passwort eines Menschen zu geben. RFC 7617 legt als Übertragungsformat eine Base64-Kodierung von `user-id:password` im Authorization-Header fest:

```http
Authorization: Basic YWdlbnQtcmVsZWFzZXI6czNjcjN0LXZhbHVl
```

Jeder, der diesen Wert lesen kann, kann ihn dekodieren. Base64 ändert die Darstellung, schützt den Wert aber nicht. TLS schützt die Verbindung zwischen Client und Server. Es schützt die Zugangsdaten jedoch nicht, nachdem ein Agent, ein lokaler Prozess, ein Debug-Log oder ein Proxy den Header kopiert hat.

Viele API-Anbieter verwenden Basic Authentication mit einem API-Token als Passwort und einem festen oder ignorierten Benutzernamen. Dadurch wird das Verfahren nicht zu einer schwächeren Form der Bearer-Authentifizierung. Es entsteht eine ähnliche Gefahr der Wiederverwendung sowie einige praktische Zusatzrisiken. Ein Client oder Logger kann den dekodierten Benutzernamen, den ursprünglichen Header oder beides speichern. Ein Entwickler könnte ein echtes Kontopasswort wiederverwenden, weil das Protokoll das zweite Feld «Passwort» nennt. Genau diese Zugangsdaten sollten Sie keinem autonomen Prozess überlassen.

Wenn Basic Authentication unvermeidbar ist, erstellen Sie ein eigenes Konto für den Executor. Geben Sie ihm nur die für die betreffende Anfragenfamilie erforderlichen Rechte. Verwenden Sie kein persönliches Konto, kein Administratorkonto und keine Zugangsdaten, die von unabhängigen Automatisierungen gemeinsam genutzt werden. Eine Dienstidentität ermöglicht Widerruf und Untersuchung, ohne eine Person auszusperren oder alle Jobs gleichzeitig zu unterbrechen.

Behandeln Sie die Zeichenkodierung bewusst. RFC 7617 beschreibt ein Kompatibilitätsproblem beim Zeichensatz von Benutzername und Passwort und erlaubt es Servern, UTF-8 anzukündigen. Wenn ein Anbieter nur gewöhnliche ASCII-Werte unterstützt, halten Sie maschinelle Zugangsdaten innerhalb dieses Zeichensatzes. Erfinden Sie keine eigene Kodierung in einem Agenten-Prompt. Dadurch entstünde eine weitere uneinheitliche Stelle, an der ein Geheimnis verändert und protokolliert werden kann.

Der Request-Executor sollte den Basic-Header selbst aus geschützten Feldern erstellen. Der Agent kann eine freigegebene Operation auswählen und nicht vertrauliche Parameter liefern. Er sollte den Base64-Wert nicht erstellen und niemals eine dekodierte Zugangsinformation in einer Fehlermeldung sehen. Eine sichere Fehlermeldung sagt, dass die Authentifizierung für die ausgewählte Zugangsdatenreferenz fehlgeschlagen ist. Sie gibt weder den Header aus noch verrät sie dem Agenten, welcher Teil des Passworts übereinstimmte.

## Benutzerdefinierte Header brauchen die genaue Semantik des Anbieters

Ein benutzerdefinierter Authentifizierungs-Header ist nur so sicher wie die dokumentierten Prüfregeln der API und der Umgang mit seinem Wert. Häufige Beispiele sind `X-API-Key`, `Api-Key` oder ein anbieterspezifischer Header. Manche Anbieter erwarten einen statischen API-Key. Andere verlangen eine signierte Anfrage mit Zeitstempel, Nonce, kanonischem Pfad und Body-Digest. Behandeln Sie nicht alle benutzerdefinierten Header als austauschbar. So werden Authentifizierungen fehlerhaft und Zugangsdaten gelangen versehentlich an zu viele Stellen.

Befolgen Sie zunächst exakt die Spezifikation des Anbieters. Headernamen sind unter HTTP unabhängig von Groß- und Kleinschreibung, Headerwerte und Signaturdaten müssen es jedoch nicht sein. Ein Signaturverfahren kann eine bestimmte Reihenfolge der Kanonisierung, exakte Body-Bytes und ein begrenztes Zeitfenster verlangen. Wenn der Executor JSON einliest und vor der Signierung neu serialisiert, kann ein gültig aussehendes JSON mit einer anderen Bytefolge entstehen. Der Anbieter weist die Anfrage dann zurück. Oft reagieren Teams darauf, die Signaturprüfung abzuschalten oder großzügige Wiederholungen einzubauen. Korrigieren Sie stattdessen die Behandlung der Bytes.

Unterscheiden Sie außerdem zwischen einem Header zur Authentifizierung und einem Header zur Identifikation eines Clients. `User-Agent`, Request-IDs und Anwendungskennungen helfen einem Anbieter bei der Beobachtung des Datenverkehrs, beweisen normalerweise aber keine Berechtigung. Umgekehrt kann ein `X-API-Key` genauso leicht wiederverwendbar sein wie `Authorization: Bearer`. Beurteilen Sie die Sensibilität nicht danach, ob der Name das Wort «authorization» enthält.

Verhindern Sie, dass der Agent Header einschleusen kann. Er sollte keine frei definierte Menge ausgehender Header erhalten, wenn ein geschützter Executor zugleich Zugangsdaten einfügt. Eine freie Header-Map ermöglicht einen zweiten `Authorization`-Header, das Überschreiben eines erwarteten Content-Type, einen nicht freigegebenen Identitäts-Header oder Einfluss auf einen nachgelagerten Proxy, den der Prüfer nicht gesehen hat.

Verwenden Sie einen Anfragevertrag mit benannten, typisierten Feldern. Zum Beispiel:

```json
{
  "credential_ref": "release-service",
  "method": "POST",
  "url": "https://api.example.test/v1/projects/alpha/releases",
  "headers": {
    "accept": "application/json"
  },
  "body": {
    "version": "2025.06.0",
    "notes": "Fix parser crash on empty input"
  }
}
```

Der Executor, nicht der Agent, ordnet `credential_ref` dem benutzerdefinierten Header oder Signaturverfahren des Anbieters zu. Er sollte Versuche ablehnen, `authorization`, `cookie`, den Zugangsdaten-Header des Anbieters, `host` oder eine doppelte Variante dieser Namen zu setzen. Auch `Content-Length` sollte er selbst verwalten, weil der HTTP-Client den Wert aus den endgültigen Bytes berechnen muss.

Für die dem Agenten angezeigte Antwort gilt dieselbe Disziplin. Eine HTTP-Antwort kann `Set-Cookie`, Diagnosedaten oder zurückgesendete Details der Anfrage enthalten. Geben Sie den Status, ausgewählte sichere Antwort-Header und den für die Aufgabe erforderlichen Body zurück. Bewahren Sie rohe Header und Spuren, wenn Operatoren sie benötigen, in einem geschützten Audit-Speicher auf.

## Wählen Sie das vom Anbieter verlangte Verfahren und begrenzen Sie dann den Schaden

Bei einer API eines Drittanbieters wählen Sie das Authentifizierungsverfahren selten selbst. Der Anbieter hat es bereits festgelegt. Sie entscheiden aber, ob die Zugangsdaten weitreichend oder eng begrenzt sind, wo sie liegen, welche Anfragen sie verwenden dürfen und was geschieht, wenn sich der Agent merkwürdig verhält.

Nutzen Sie diesen Vergleich für den Entwurf der Grenze:

| Muster | Was der Client sendet | Hauptrisiko bei Kopie | Sinnvoller Umgang mit dem Agenten |
|---|---|---|---|
| Bearer-Token | Einen Token in `Authorization` | Direkte Wiederverwendung durch den Empfänger | Im Executor verwahren und Umfang und Gültigkeit begrenzen |
| Basic Authentication | Base64 aus Benutzername und Passwort oder Token | Dekodierung mit anschließender direkter Wiederverwendung | Eine eigene Dienstidentität im Executor verwenden |
| Statischer benutzerdefinierter Header | Einen vom Anbieter definierten geheimen Header | Meist direkte Wiederverwendung | Nur für freigegebene Hosts und Pfade einfügen |
| Signierter benutzerdefinierter Header | Signatur mit Zeitstempel und Anfragedaten | Wiederverwendung kann scheitern, Signaturmaterial bleibt aber sensibel | Geheimnis und Kanonisierung im Executor halten |

Signierte Anfragen verdienen eine wichtige Einschränkung. Zeitstempel und Nonce können eine einfache Wiederverwendung an der API-Grenze erschweren. Sie machen das Signaturgeheimnis aber nicht sicher für den Agentenkontext. Ein Agent, der auf das Geheimnis zugreifen kann, kann eine neue schädliche Anfrage signieren. Wenn die Signaturimplementierung beliebige Methode, Hosts, Pfade und Bodies des Agenten akzeptiert, signiert sie zuverlässig Aktionen, die Sie nicht autorisieren wollten.

Der Umfang sollte zur Aktion passen, nicht zu einer vorgestellten späteren Verwendung. Ein Agent zum Veröffentlichen von Releases benötigt möglicherweise das Recht, in einem Projekt ein Release zu erstellen. Er braucht keine Berechtigung, Projekte zu löschen, Abrechnungen zu ändern, alle Artefakte zu lesen oder Benutzer einzuladen. Kann ein Anbieter keine passend begrenzten Zugangsdaten ausstellen, setzen Sie einen engeren, von Ihnen kontrollierten Dienst vor die Anbieter-API oder behalten Sie für gefährliche Aufrufe eine menschliche Freigabe bei.

Lösen Sie zu weit gefasste Scopes nicht mit einer langen Erlaubnisliste in natürlicher Sprache. «Verwende den Token nur für Releases» ist ein Hinweis, aber kein Durchsetzungspunkt. Setzen Sie die Begrenzung dort um, wo die Anfrage zusammengesetzt wird: erwarteter Ursprung, erlaubte Methode, Pfadmuster, Header-Menge, Body-Schema und maximale Antwortgröße. Diese Einschränkungen machen die Zugangsdaten außerhalb ihrer vorgesehenen Aufgabe weniger nützlich.

## Vermittlung hält Geheimnisse aus dem Agentenkontext heraus

Vermittelte HTTP-Aufrufe funktionieren, wenn der Inhaber des Geheimnisses die Anfrage ausführt, statt dem Agenten ein Geheimnis zur Ausführung zurückzugeben. Die beiden Designs lassen sich leicht verwechseln, weil beide dem Agenten ein Tool namens `http_request` geben können. Der Datenfluss zeigt, welches Design Sie tatsächlich gebaut haben.

Im unsicheren Design ruft das Tool einen Token ab und gibt ihn an den Agenten weiter, vielleicht als Umgebungsvariable, Platzhalter oder «temporäre» Zugangsdaten. Die nächste Aktion des Agenten sendet die Anfrage. Der Token hat damit bereits ein System erreicht, das Text analysiert, verändert und wiederholt.

Im vermittelten Design sendet der Agent eine strukturierte Anfrage an einen Executor. Der Executor prüft sie gegen die erlaubte Form, ruft die ausgewählten Zugangsdaten aus dem geschützten Speicher ab, fügt das richtige Authentifizierungsmaterial ein, sendet die Anfrage, protokolliert die Aktion und gibt ein begrenztes Ergebnis zurück. Der Agent erhält weder den geheimen Wert noch eine kodierte Form davon oder einen Shell-Befehl, der ihn enthält.

Dieser Unterschied verändert auch die Reaktion auf Vorfälle. Wenn Sie vermuten, dass eine Agentensitzung aus dem Ruder gelaufen ist, können Sie ihre Fähigkeit stoppen, Aktionen anzufordern, ohne sofort jede Zugangsinformation auszutauschen. Wenn ein Geheimnis selbst entkommen sein könnte, müssen Sie es trotzdem ersetzen. Der Widerruf einer Sitzung und der Austausch von Zugangsdaten lösen unterschiedliche Probleme. Teams verlieren Zeit, wenn sie beide wie dieselbe Schaltfläche behandeln.

Ein praktischer Executor sollte mehrere Anfrageformen standardmäßig ablehnen:

- Absolute URLs zu einem nicht freigegebenen Ursprung, einschließlich ähnlich aussehender Subdomains.
- Anfragen mit vom Benutzer gesetzten `Authorization`-, `Cookie`-, Proxy- oder anbieterspezifischen Zugangsdaten-Headern.
- Weiterleitungen, die eine authentifizierte Anfrage an einen anderen Ursprung tragen könnten.
- Methoden außerhalb der vorgesehenen Verwendung der Zugangsdaten, besonders destruktive Methoden.
- Bodies, die größer als erwartet sind oder nicht dem vorgesehenen Format des Endpunkts entsprechen.

Sallyport setzt dieses Verwahrungsmodell unter macOS um: Der verschlüsselte Tresor enthält API- und SSH-Zugangsdaten, während ein MCP-Agent die App bittet, HTTP-Aufrufe auszuführen, statt die Zugangswerte zu erhalten.

Verwechseln Sie Vermittlung nicht mit einer allgemeingültigen Policy-Engine. Sie kann nicht feststellen, ob «veraltete Testressourcen löschen» in einem bestimmten Produktionskonto richtig ist. Sie kann sicherstellen, dass eine Anfrage innerhalb einer definierten technischen Grenze bleibt und die Zugangsdaten außerhalb des Agentenkontexts bleiben. Menschliche Prüfung, begrenzte Konten und anwendungsspezifische Schutzmaßnahmen entscheiden weiterhin, ob die Aktion selbst eine Freigabe verdient.

## Die Anfragegrenze muss Weiterleitungen, DNS und Antworten einschließen

Die Freigabe von `https://api.example.test` allein ist zu weit gefasst, weil eine Anfrage mit Zugangsdaten mehr als einen Hostnamen enthält. Der Executor muss jede Stelle kontrollieren, an der ein Agent das effektive Ziel oder die Bedeutung der Anfrage verändern kann.

Beginnen Sie mit einem exakten Ursprung: Schema, Hostname und Port. Für normale Internet-API-Zugangsdaten sollte HTTPS vorgeschrieben sein. RFC 9110 definiert Regeln für Request-Target und Authority. Anwendungscode muss aber weiterhin eigene Zielregeln durchsetzen. Geben Sie Hosts nicht nur anhand eines Suffixes frei. Eine Prüfung wie «Hostname endet mit `example.test`» könnte `notexample.test` akzeptieren. Eine lose Teilstring-Prüfung ist noch schlechter. Vergleichen Sie geparste Hostnamen mit einer exakten Allowlist oder einer bewusst entworfenen Subdomain-Regel.

Begrenzen Sie danach Methoden und Pfade. Wenn der Agent Releases erstellen soll, erlauben Sie genau die benötigte `POST`-Pfadfamilie. Fügen Sie nicht `DELETE` hinzu, nur weil es beim Aufräumen nützlich sein könnte. Erlauben Sie keine beliebigen versionierten Pfade, ohne zu prüfen, ob eine spätere API-Version ein anderes Verhalten bietet. Auch die Normalisierung des Pfads ist wichtig. Parsen Sie die URL vor dem Vergleich und lehnen Sie überraschende Kodierungen, Punktsegmente oder doppelte Trennzeichen ab, wenn Ihre Vergleichslogik damit nicht verlässlich umgeht.

Das Verhalten bei Weiterleitungen muss ausdrücklich festgelegt werden. HTTP-Bibliotheken unterscheiden sich, und ein Bibliotheks-Upgrade kann Standardeinstellungen ändern. Bei authentifizierten Aufrufen ist die sicherste Voreinstellung, Weiterleitungen abzulehnen und das Ziel dem Agenten zu melden. Wenn ein Anbieter tatsächlich eine Weiterleitung benötigt, erlauben Sie nur den konkret erwarteten Zielursprung und bauen Sie die Anfrage unter denselben Einschränkungen neu auf. Gehen Sie nie davon aus, dass ein Client Zugangsdaten bei offenen Weiterleitungen zuverlässig entfernt.

DNS schafft eine zweite Zielprüfung. Ein vertrauenswürdiger Hostname kann auf wechselnde Adressen zeigen, und interne Systeme können Namen besitzen, die in sensible Netzwerke führen. Wenn der Executor auf einem Entwicklerrechner läuft, kann beliebiges ausgehendes HTTP zu lokalen Verwaltungsdiensten oder Cloud-Metadaten-Endpunkten führen. Begrenzen Sie freigegebene Ursprünge vor dem Verbindungsaufbau, akzeptieren Sie keine vom Agenten kontrollierten Proxy-Einstellungen und lassen Sie den Agenten weder Netzwerkschnittstelle noch Resolver auswählen.

Begrenzen und filtern Sie schließlich die Antwort. Ein Agent braucht keinen Download von mehreren Megabytes, um zu erfahren, dass die Erstellung eines Releases erfolgreich war. Große Bodies verbrauchen Kontext und können Anweisungen aus einem nicht vertrauenswürdigen Dienst in die Überlegungen des Agenten einschleusen. Geben Sie nach Möglichkeit nur die für die nächste Aktion benötigten Felder zurück. Kennzeichnen Sie entfernten Text im Tool-Vertrag als Daten und lassen Sie Antwortinhalte niemals die Autorisierungsregeln des Executors ändern.

## Die Freigabe sollte den aufrufenden Prozess und die konkrete Aktion nennen

Ein menschlicher Klick auf «Freigeben» ist nur dann wertvoll, wenn er genügend Informationen für eine Entscheidung liefert. «Agentenzugriff auf API erlauben» ist eine pauschale Berechtigung, die sich als Nachfrage tarnt. Sie fördert Freigabemüdigkeit, weil die Person nicht erkennen kann, welcher lokale Prozess gefragt hat, welche Zugangsdaten verwendet werden sollen oder was gesendet wird.

Identifizieren Sie den aufrufenden Prozess so, dass ein Operator ihn erkennen kann. Unter macOS ist die Codesignatur oft aussagekräftiger als ein veränderlicher Prozessname. Ein Prozess namens `agent` kann ein legitimes Entwicklerwerkzeug oder eine fremde Binärdatei sein, die denselben Namen gewählt hat. Prozesslinie, Pfad der ausführbaren Datei und Signaturinformationen liefern bessere Hinweise. Keine dieser Angaben ersetzt jedoch eine begrenzte Aktionsanfrage.

Sitzungsfreigabe und Anfragefreigabe behandeln unterschiedliche Zielkonflikte. Eine Sitzungsfreigabe reduziert wiederholte Unterbrechungen bei einem bekannten Agentenlauf. Sie eignet sich für risikoarme, wiederholte Vorgänge, solange Zugangsdaten und Anfragegrenze eng bleiben. Eine Anfragefreigabe passt zu irreversiblen oder sensiblen Aktionen, etwa einer externen Veröffentlichung, Änderungen an Zugriffseinstellungen oder dem Schreiben von Daten, das ein anderes System auslöst.

Vermeiden Sie ein Freigabedesign, bei dem eine Person für jeden Aufruf einen langen rohen HTTP-Dump prüfen soll. Nach der dritten Unterbrechung werden Menschen ihn ungelesen freigeben. Zeigen Sie eine kurze Zusammenfassung: Dienstidentität, Methode, Ziel, Pfad, wichtige Body-Felder und jede vom API dokumentierte Nebenwirkung. Bewahren Sie die vollständigen Anfragedetails für spätere Untersuchungen im Audit-Eintrag auf.

Unterscheiden Sie außerdem zwischen der Erlaubnis, eine Sitzung zu starten, und der Erlaubnis, sie am Leben zu halten. Wenn ein Agentenprozess endet, darf ein Ersatzprozess die Freigabe nicht allein deshalb übernehmen, weil er denselben Namen trägt. Widerruft ein Benutzer eine Sitzung, muss der Executor Anfragen dieses Prozesses sofort ablehnen. Eine Benutzeroberfläche, die «widerrufen» anzeigt, während ein bereits autorisierter Client weiter Anfragen sendet, ist schlimmer als keine Widerrufsfunktion, weil sie falsches Vertrauen erzeugt.

## Audit-Aufzeichnungen müssen nach dem Ende des Agenten beantworten, was geschah

Ein brauchbarer Audit-Trail ermöglicht einem Operator zu beantworten, wer einen Aufruf angefordert hat, welche Zugangsdatenreferenz der Executor verwendet hat, wohin die Anfrage ging, was der Executor erlaubt hat und was der entfernte Dienst zurückgab. Der rohe geheime Wert ist dafür nicht nötig. Ihn aufzuzeichnen würde vielmehr einen zweiten geheimen Speicher schaffen, der sich als Beobachtbarkeit tarnt.

Bewahren Sie für jeden Aufruf Sitzungs- oder Prozessidentität, Zeitpunkt, ausgewählte Zugangsdatenreferenz, HTTP-Methode, freigegebenen Ursprung, Pfad, eine geschützte Darstellung relevanter Anfragedaten, Antwortstatus und die erlaubende oder ablehnende Entscheidung auf. Halten Sie nach jeder erlaubten Weiterleitung das tatsächliche endgültige Ziel fest. Protokollieren Sie auch Fehler. Wiederholte abgelehnte Versuche gegen einen ungewöhnlichen Pfad weisen oft auf eine fehlerhafte Agentenanweisung oder einen Versuch hin, die Grenze zu umgehen.

Manipulationsnachweise verändern, wie stark Sie dem Protokoll vertrauen können. Eine hashverkettete Logdatei verknüpft jeden Eintrag mit früheren Einträgen, sodass spätere Änderungen oder Löschungen bei einer Prüfung erkennbar werden. Sie beweist nicht, dass der ursprüngliche Executor eine kluge Autorisierungsentscheidung getroffen hat, und macht einen kompromittierten Host nicht vertrauenswürdig. Sie erschwert jedoch das stille Ändern der Vergangenheit. Genau diese Eigenschaft wird bei der Untersuchung eines Vorfalls benötigt.

Halten Sie Audit-Aufzeichnungen vom normalen Arbeitskontext des Agenten getrennt. Der Agent kann eine Zusammenfassung wie `201 Created, release id r-4821` erhalten. Ein Operator benötigt vielleicht einen umfangreicheren Datensatz mit Pfad und Entscheidungsmetadaten. Keine der beiden Seiten sollte nur deshalb den rohen Authorization-Header erhalten, weil Protokollierung aktiviert ist.

In Sallyport werden die Sitzungs- und Aktivitätsjournale aus einem verschlüsselten, hashverketteten Audit-Log erzeugt. Mit `sp audit verify` kann diese Kette offline geprüft werden, ohne den Tresor zu entsperren. Das ist für Prüfungen sinnvoll, weil die Verifizierung keine Offenlegung der Zugangsdaten erfordert, die die Aufrufe autorisiert haben.

## Testen Sie Fehlerpfade, bevor Sie Produktionszugriff gewähren

Eine Zugangsdaten-Grenze, die nur im Erfolgsfall funktioniert, ist noch nicht für den Produktionseinsatz bereit. Erstellen Sie eine kleine Test-API oder verwenden Sie ein Nichtproduktionskonto. Lassen Sie den Executor dann beweisen, dass er Situationen ablehnt, die Zugangsdaten offenlegen oder missbrauchen würden.

Verwenden Sie eine Testabfolge wie diese:

1. Fordern Sie einen freigegebenen `GET`-Endpunkt an und prüfen Sie, dass der Agent den erwarteten Body, aber keinen Header mit Zugangsdaten erhält.
2. Übergeben Sie vom Agenten einen `Authorization`-Header und prüfen Sie, dass der Executor ihn ablehnt, statt Header stillschweigend zusammenzuführen oder zu ersetzen.
3. Ändern Sie die URL zu einem nicht freigegebenen Host und zu einer täuschend ähnlichen Variante. Prüfen Sie, dass beide Anfragen vor jedem Netzwerkaufruf scheitern.
4. Lassen Sie die Test-API eine ursprungsübergreifende `302`-Antwort zurückgeben und prüfen Sie, dass der Executor stoppt, statt Authentifizierungsdaten weiterzuleiten.
5. Widerrufen Sie die Agentensitzung während eines Laufs und prüfen Sie, dass spätere Aufrufe scheitern, während die Audit-Prüfung weiterhin erfolgreich ist.

Untersuchen Sie nach dem Lauf Prozessumgebungen, temporäre Verzeichnisse, Shell-Historie, erzeugte Dateien, Absturzberichte und Testprotokolle. Suchen Sie nach einer bekannten Test-Zugangsdatenfolge. Diese Übung findet überraschend viele Lecks in Wrapper-Skripten und Debug-Modi, die reine Anfragetests nicht entdecken.

Testen Sie auch Fehler des Anbieters. Eine API kann einen Body zurückgeben, der ungültige Header-Inhalte, eine Trace-ID oder den Hinweis enthält, es mit einem anderen Endpunkt zu versuchen. Prüfen Sie, dass der Ergebnisfilter kein zugangsdatenähnliches Material an den Agenten weitergibt und die Wiederholungslogik eine abgelehnte Anfrage nicht in eine Flut von Versuchen verwandeln kann. Begrenzen Sie Wiederholungen auf Fehler, bei denen die API-Dokumentation sie für angemessen erklärt, und lassen Sie Methode und Ziel unverändert.

Die erste Produktionszugangsinformation sollte so eng begrenzt sein, dass ein fehlgeschlagener Test ärgerlich, aber nicht katastrophal wäre. Wenn Ihr Team nicht genau erklären kann, welche Anfrageformen autorisiert werden und wie ein aktiver Agentenlauf widerrufen wird, sind die Zugangsdaten für den autonomen Einsatz noch zu weitreichend.