# Generische HTTP-Tools löschen die Berechtigungsgrenze

Ein generischer HTTP-Aufruf sieht für den Host eines Agenten wie ein einzelnes Tool aus. In der Praxis kann er Tausende Fähigkeiten enthalten. Werden URL, Zugangsdaten, Methode, Header oder Body geändert, kann dieselbe Funktion eine Statusseite lesen, Kundendaten exportieren, ein Signaturgeheimnis wechseln oder eine Produktionsressource löschen.

Diese Diskrepanz macht die Berechtigung auf Tool-Ebene zu einer schwachen Sicherheitsgrenze. Die Freigabe von `http_request` sagt nicht, was der Agent tun darf. Die sinnvolle Entscheidung liegt eine Ebene tiefer. Dort kann das System bestimmte Zugangsdaten an ein aufgelöstes Ziel, eine erlaubte Methode und eingeschränkte Anfragedetails binden.

Der Unterschied zählt auch dann, wenn sich der Agent korrekt verhält. Prompts enthalten Fehler, abgerufener Text kann feindliche Anweisungen enthalten und ein weitreichendes Tool kann einen kleinen Planungsfehler in eine echte API-Aktion verwandeln. Ein freundlicherer Tool-Name ändert daran nichts. Autorisiert werden muss die Aktion, die das Netzwerk durchquert.

## Ein Aufruf-Tool enthält viele Fähigkeiten

Ein Tool ist nur dann eine Fähigkeitsgrenze, wenn seine Eingaben seine Befugnisse nicht grundlegend verändern können. Eine Wetterabfrage mit festem Anbieter, fester GET-Methode und festem Antwortformat kommt einer einzelnen Fähigkeit nahe. Eine Funktion, die jede URL, jedes Verb, beliebige Header und einen Body akzeptiert, ist ein programmierbarer Netzwerkclient.

Nehmen wir ein Schema mit fünf gewöhnlichen Feldern: `url`, `method`, `headers`, `body` und `credential_name`. Der Agentenhost kann es als einen Eintrag in der Tool-Liste anzeigen. Dennoch verdienen `GET /projects/42` mit einem Lesetoken und `DELETE /projects/42` mit einem Administratortoken nicht dieselbe Entscheidung. Das gilt ebenso für eine öffentliche API im Vergleich zu einem Dienst, dessen Adresse in einem privaten Netz liegt.

Die Tool-Annotationen des Model Context Protocol beheben diesen Zusammenbruch nicht. Die MCP-Toolspezifikation beschreibt Angaben zu Lesezugriff und destruktivem Verhalten als Hinweise. Clients sollen ihnen nicht vertrauen, wenn sie nicht von vertrauenswürdigen Servern stammen. Ein generischer Client kann `readOnlyHint` auch keinen immer zutreffenden Wert geben, weil sein Verhalten von noch unbekannten Argumenten abhängt.

Teams vermischen häufig zwei Begriffe: Die Tool-Auswahl bestimmt, welche Implementierung ausgeführt wird. Die Autorisierung einer Aktion bestimmt, welcher externe Effekt eintreten darf. Genehmigt der Host nur den Namen der Implementierung, erbt jede sachlich andere Anfrage diese Freigabe. Hinter einer ordentlichen Tool-Auswahl kann so ein fast unbeschränkter ausgehender Kanal stehen.

Jede API-Operation in ein eigenes Tool zu zerlegen, kann Beschreibung und Planung verbessern, löst aber nicht die gesamte Sicherheitsfrage. Generierte Tools brauchen weiterhin eine Kontrollstelle, Zugangsdaten behalten ihre eigenen Befugnisse und Weiterleitungen können eine scheinbar enge Operation an ein anderes Ziel führen. Spezifische Tools helfen der Bedienung. Berechtigungen müssen für die endgültige Anfrage gelten.

## Eine Berechtigung braucht vier Koordinaten

Eine belastbare HTTP-Entscheidung hat vier Koordinaten: Zugangsdaten, aufgelöstes Ziel, Methode und Anfragedetails. Fehlt eine davon, kann eine Anfrage weiterhin genehmigt aussehen und zugleich ihre Wirkung ändern.

Die Zugangsdaten bestimmen die ausgeübten Befugnisse. Ein Deployment- und ein Abrechnungstoken können denselben Host und Pfad nutzen, aber völlig verschiedene Rechte tragen. Das Ziel bestimmt, wo diese Befugnisse vorgelegt werden dürfen. Die Methode beschreibt die grobe HTTP-Absicht. Pfad, Abfrage, ausgewählte Header, Inhaltstyp und Body-Felder legen die eigentliche Operation fest.

Ein kompakter Autorisierungseintrag kann so aussehen:

```yaml
credential: issue-tracker-read
origin: https://api.example.test:443
path_prefix: /v2/issues/
methods:
  - GET
redirects: deny
headers:
  allow:
    - Accept
query:
  deny:
    - include_deleted
body: forbidden
```

Dieses Fragment verhindert mehrere Fehler zugleich. Der Agent kann keine mächtigeren Zugangsdaten einsetzen, sie nicht an einen anderen Origin senden, den Lesezugriff nicht in POST ändern, keiner Weiterleitung folgen, keinen Authentifizierungsheader hinzufügen, keine gelöschten Datensätze über den Parameter anfordern und keinen Body in eine erwartete Leseoperation schmuggeln.

Das Richtlinienobjekt ist keine universelle Vorlage. Manche APIs brauchen genaue Pfade, andere eine Mandantenkennung im Pfad und wieder andere beschreiben eine Aktion im POST-Body. Entscheidend ist die Form: Nach Parsing und Normalisierung werden alle vier Koordinaten gemeinsam geprüft. Erst bei Erfolg werden die Zugangsdaten eingefügt.

Lassen Sie den Agenten das eigentliche Geheimnis nicht über `headers` liefern. Er soll Zugangsdaten über einen undurchsichtigen Namen referenzieren. Ein vertrauenswürdiger Executor fügt Bearer-Token, Basic-Zugangsdaten oder eigene Header erst nach der Autorisierung ein. Sonst kann der Agent ein Geheimnis in ein anderes Feld, ein Protokoll oder an ein zweites Ziel kopieren und die Zielregel bleibt nur Fassade.

## Zugangsdaten bestimmen die Befugnisse

Zugangsdaten sollten getrennte Freigaben mit den geringsten Rechten sein, die die Ziel-API unterstützt. Ein generisches HTTP-Tool wird deutlich weniger gefährlich, wenn der Executor zwischen benannten, eingeschränkten Zugangsdaten auswählt, statt ein organisationsweites Token zu halten.

OAuth-Scopes helfen, doch Scope und Audience beantworten verschiedene Fragen. Ein Scope kann das Lesen von Kontakten erlauben. Die Audience bestimmt, welcher Ressourcenserver das Token akzeptieren soll. RFC 8707 definiert den OAuth-Parameter `resource`, mit dem ein Client ein Token für eine bestimmte geschützte Ressource anfordert, und empfiehlt die Beschränkung der Audience. Das Sicherheitsargument ist praktisch: Ein einer Ressource vorgelegtes Token darf bei einer anderen nicht funktionieren.

Die aktuelle MCP-Autorisierungsspezifikation nutzt dieselbe Trennung. MCP-Server dürfen nur für sie bestimmte Tokens akzeptieren und ein eingehendes MCP-Token nicht an eine nachgelagerte API weiterreichen. Ruft ein MCP-Server eine andere API auf, handelt er als eigener OAuth-Client und verwendet ein separates Token. Ein generischer HTTP-Executor sollte diese klare Grenze erhalten, auch wenn der Agent keinen OAuth-Ablauf sieht.

API-Schlüssel bieten oft schwächere eingebaute Kontrollen. Behandeln Sie trotzdem jeden Schlüssel als eigene Befugnis. Halten Sie fest, welche Origins ihn empfangen dürfen, in welcher Header-Form der Executor ihn einfügt, wann er abläuft und wer ihn wechselt. Ein Tresoreintrag namens `staging` ist nicht allein wegen seines Namens harmlos. Prüfen Sie seine tatsächlichen Rechte beim Zieldienst.

Die Auswahl der Zugangsdaten gehört auch in die Freigabeanzeige. Ein Hinweis wie `POST api.example.test` zeigt nicht, ob ein Testschlüssel oder das Token eines Kontoinhabers verwendet wird. Zeigen Sie eine lesbare Bezeichnung und das betreffende Konto oder den Mandanten, aber niemals das Geheimnis. Kann der Executor diesen Kontext nicht bestimmen, ist die Freigabe für eine stille Wiederverwendung zu unklar.

Geheimnisse vom Modell fernzuhalten, reduziert versehentliche Offenlegung, schränkt aber allein ihre Nutzung nicht ein. Ein Agent kann ein Geheimnis missbrauchen, ohne seine Bytes zu sehen, wenn ein zu weit gefasster Executor es beliebigen Anfragen hinzufügt. Geheimhaltung und minimale Befugnisse lösen unterschiedliche Probleme. Beides ist nötig.

## Das Ziel ist der aufgelöste Endpunkt

Eine URL-Zeichenfolge einmal zu prüfen, ist keine Zielkontrolle. Der Executor muss die URL parsen und normalisieren, den Host auflösen, Netzwerkregeln anwenden und die Entscheidung bei jeder Weiterleitung wiederholen, bevor er Zugangsdaten anhängt.

Beginnen Sie mit exaktem Schema, Host und effektivem Port. `https://api.example.test` und `https://api.example.test:8443` sind unterschiedliche Origins. Lehnen Sie Nutzerinformationen in URLs, mehrdeutige Codierungen, nicht unterstützte Schemas und Hostnamen ab, die nur wie ein erlaubtes Suffix aussehen. Eine Prüfung, die `api.example.test.attacker.invalid` akzeptiert, ist keine Positivliste.

Lösen Sie dann DNS auf und prüfen Sie jede zurückgegebene Adresse. Ein öffentlich wirkender Name kann auf Loopback, Link-local, einen privaten Bereich oder Metadaten einer Cloud-Instanz zeigen. Die Auflösung kann sich auch zwischen Prüfung und Verbindung ändern. Die prüfende Komponente sollte die Verbindung kontrollieren und die tatsächlich genutzte Adresse bestätigen, statt die URL an einen zweiten Client mit neuer Auflösung zu geben.

Das Server Side Request Forgery Prevention Cheat Sheet von OWASP empfiehlt bekannte vertrauenswürdige Ziele per Positivliste, wenn die Anwendung sie bestimmen kann. Es rät außerdem, automatische Weiterleitungen abzuschalten, weil sie die Eingabeprüfung umgehen können. Für Agenten-Tools passt das besonders gut: Die URL kommt oft vom Modell und die Anfrage kann Zugangsdaten tragen, die nur das erste Ziel erhalten sollte.

Weiterleitungen erfordern eine neue Autorisierungsentscheidung. RFC 9110 fordert bei automatischen Weiterleitungen unsicherer Methoden Vorsicht und empfiehlt, ressourcenbezogene Felder wie Authorization und Cookie zu entfernen. Ein sicherer Executor kann einfacher vorgehen: Authentifizierte Weiterleitungen standardmäßig ablehnen oder das neue Ziel als neue Aktion anzeigen und Zugangsdaten erst nach erneuter Prüfung einfügen.

Pfadkontrollen bleiben innerhalb eines erlaubten Origin wichtig. Mandantenfähige Gateways, gemeinsam genutzte SaaS-Hosts und Verwaltungsrouten können hinter demselben Namen liegen. RFC 8707 weist darauf hin, dass ein mandantenkennzeichnender Pfad Teil der Ressourcenkennung sein kann. Eine Origin-Liste ohne Pfad- oder Mandantenbeschränkung kann viel weiter reichen als erwartet.

## HTTP-Methoden sind Signale, keine Urteile

Methodenbeschränkungen verhindern viele Fehler, aber der Methodenname beweist keine Harmlosigkeit. RFC 9110 definiert GET, HEAD, OPTIONS und TRACE als sicher, weil ihre festgelegte Semantik im Wesentlichen lesend ist. PUT, DELETE und sichere Methoden gelten als idempotent: Eine Wiederholung hat denselben beabsichtigten Effekt wie ein einzelner Aufruf.

Sicher und idempotent sind keine Synonyme. DELETE kann idempotent sein und trotzdem eine Ressource zerstören. POST ist gewöhnlich weder sicher noch idempotent, doch eine API kann POST für eine reine Suche nutzen, deren Abfrage zu lang für eine URL ist. Ein Freigabesystem, das Risiko auf GET gegen POST reduziert, stuft beide Fälle falsch ein.

Reale APIs verletzen manchmal die Methodensemantik. RFC 9110 warnt ausdrücklich vor Ressourcen, die Aktionen wie Löschen in eine GET-Abfrage legen, und verlangt vom Betreiber, unsicheres Verhalten über sichere Methoden zu verhindern. Der Executor kann nicht annehmen, dass jeder Dienst diese Regel einhält. Wenn `GET /jobs?id=7&action=cancel` Zustand ändert, schafft die Freigabe aller GET-Anfragen kein reines Leserecht.

Nutzen Sie die Methode als einen Eingangswert. Verbinden Sie sie mit dem Pfad und bei Bedarf mit operationsspezifischen Einschränkungen. Für eine gut beschriebene API liefert eine OpenAPI-Operation eine nützliche Karte: Die OpenAPI-Spezifikation erlaubt Sicherheitsanforderungen je Operation und OAuth-Einträge führen nötige Scopes auf. Importieren Sie diese Angaben als Konfiguration und prüfen Sie sie gegen das, was der Dienst wirklich ausstellt und akzeptiert. Eine Beschreibungsdatei erzwingt selbst nichts.

Auch Wiederholungen gehören zu dieser Entscheidung. Ein Netzwerk-Timeout nach POST sagt nicht, ob der Server die Aktion angewandt hat. Wiederholen Sie eine unsichere, nicht idempotente Anfrage nicht automatisch, sofern die API keinen Idempotenzmechanismus bietet oder der Client weiß, dass der erste Versuch nicht wirkte. Idempotenz kann die Wiederholung betrieblich sicherer machen, autorisiert aber nicht die ursprüngliche Aktion.

## Anfragedetails bestimmen die echte Wirkung

Zwei Anfragen mit denselben Zugangsdaten, demselben Origin, Pfad und derselben Methode können gegensätzlich wirken. Body, Abfrage und ausgewählte Header enthalten oft die wirklich entscheidende Operation.

Ein Abrechnungsendpunkt kann `POST /v1/subscriptions/update` sowohl zur Verringerung von Plätzen als auch zum Wechsel auf einen teuren Tarif verwenden. Ein Repository-Endpunkt kann eine Mutationsroute mit dem Feld `operation` zum Archivieren, Übertragen oder Löschen nutzen. Eine Suche kann bei `include_deleted=true` verborgene oder gelöschte Datensätze liefern. Wer die Route ohne diese Felder freigibt, erlaubt alle implementierten Modi.

Header verdienen dieselbe Skepsis. Der Executor sollte `Authorization`, `Proxy-Authorization`, `Host` und jeden eigenen Zugangsdaten-Header kontrollieren. Versuche des Agenten, diese zu setzen, sollte er gewöhnlich ablehnen. Header zur Kontoauswahl, Nutzervertretung, Methodenüberschreibung, asynchronen Ausführung oder bedingten Schreibsteuerung können Befugnis oder Wirkung ändern. Beliebige Header weiterzuleiten, versteckt ein zweites generisches Tool im ersten.

Der Inhaltstyp steuert das Parsing. Prüft die Richtlinie JSON, während der Client Formulardaten, Multipart-Inhalte oder komprimierte Bytes senden darf, kann der Agent das empfindliche Feld am Parser vorbeiführen. Erzwingen Sie den angegebenen Typ, setzen Sie Größenlimits vor dem Puffern, lehnen Sie doppelte oder mehrdeutige Felder ab und autorisieren Sie dieselben Bytes, die gesendet werden. Ein Objekt zu prüfen und ein anderes zu serialisieren, schafft Lücken.

Auch die Antwortbehandlung gehört zur Grenze, obwohl sie keine Berechtigungskoordinate für den ausgehenden Effekt ist. Begrenzen Sie die Größe, klassifizieren Sie Inhaltstypen und behandeln Sie zurückgegebene Anweisungen als nicht vertrauenswürdige Daten. Ein erlaubtes GET kann eine Seite mit Prompt-Injection, Geheimnissen oder riesiger Nutzlast abrufen. Die Ausgangsfreigabe macht die Antwort nicht sicher für den Agenten.

Exakte Body-Schemas sind teuer in der Pflege. Konzentrieren Sie die Arbeit auf besonders mächtige Routen. Bei Lesezugriff mit geringem Risiko können ein Body-Verbot und beschränkte Abfragenamen reichen. Bei Kontoänderungen, Deployments, Geheimniswechseln, Geldbewegungen oder Löschungen sollten Objekt, Mandant, Betrag, Umgebung und gewünschter Übergang geprüft werden. Bietet die API einen engeren Endpunkt oder Zugang, ist dieser einer komplizierten lokalen Regel vorzuziehen.

## Die Freigabe muss die aufgelöste Aktion beschreiben

Eine brauchbare Freigabe zeigt, was der vertrauenswürdige Executor nach der Normalisierung senden wird, nicht den vom Modell vorgeschlagenen Tool-Aufruf. Prüfende brauchen Bezeichnung der Zugangsdaten, Konto oder Mandant, aufgelöstes Ziel, Methode, Pfad, relevante Felder und das Verhalten bei Weiterleitungen.

Das bedeutet nicht, rohes JSON in einen Dialog zu kippen. Eine vollständige Nutzlast versteckt das gefährliche Feld zwischen Zeitstempeln und Standardwerten. Zeigen Sie zuerst eine Operationsübersicht und danach die kanonische Anfrage. Eine Deployment-Freigabe kann mitteilen, dass `production-deployer` die Version `2026.07.24` im Produktionsmandanten erstellt, gefolgt von Host, POST-Pfad und Body-Differenz.

Binden Sie die Freigabe an einen Hash der kanonischen Aktion. Ändern sich Host, Methode, Pfad, geschützte Header oder Body nach dem Klick, berechnen Sie einen anderen Hash und verlangen eine neue Entscheidung. Das schließt eine häufige Lücke zwischen Prüfung und Nutzung, bei der die Oberfläche ein Objekt freigibt und Middleware später einer Weiterleitung folgt, Vorgaben ergänzt oder den Body verändert.

Wählen Sie die Wiederverwendungsgrenze bewusst. Eine Sitzungsfreigabe kann für wiederholtes Lesen mit engen Zugangsdaten und engem Ziel passen. Zugangsdaten, die Ressourcen löschen können, erfordern eine Freigabe pro Aufruf oder eine viel enger vorab genehmigte Operation. Ersetzen Sie enge Rechte nicht durch wiederholte Dialoge. Menschen klicken laute, gleich aussehende Hinweise bald ungelesen weg.

Fehlt notwendiger Kontext, muss die Entscheidung standardmäßig ablehnen. Ein nicht aufgelöster Host, unbekannter Inhaltstyp, eine unbekannte Methodenüberschreibung oder ein nicht parsbarer Body sind keine Anfragen mit geringem Risiko. Das System kann diese Aktionen nicht präzise beschreiben.

## Ein harmloser Plan kann zum gefährlichen Aufruf werden

Der Fehler beginnt meist mit einer gewöhnlichen Aufgabe und einer Anfrage, deren Bedeutung sich über mehrere Schichten ändert. Angenommen, ein Agent soll ein Ticket lesen und einen kurzen Status veröffentlichen. Der Host genehmigt den generischen Client für die Sitzung, weil beide Operationen denselben Projektdienst verwenden.

Die Lesezugangsdaten scheitern an POST, also wählt der Planer einen anderen Tresoreintrag, dessen Beschreibung Projektautomatisierung erwähnt. Dieses Token kann auch Webhooks verwalten. Ein abgerufener Kommentar fordert den Agenten auf, einen externen Callback zu informieren, und der Planer übergibt dessen URL als Statusziel. Das Tool hat weiter seine Sitzungsfreigabe, der Name klingt passend und die Methode bleibt POST. Die Tool-Berechtigung erkennt keinen Grenzübertritt.

Der erste Callback antwortet mit einer 307-Weiterleitung an eine private Adresse. Eine bequeme HTTP-Bibliothek bewahrt bei diesem Status den POST-Body. Sie entfernt vielleicht einen automatisch erzeugten Authorization-Header, doch ein vom aufrufenden Code gesetzter eigener Header kann ohne ausdrückliche Behandlung erhalten bleiben. Die Anfrage trägt nun Projektbefugnisse und Ticketinhalt zu einem ungeprüften Ziel. Selbst wenn der private Dienst die Zugangsdaten ablehnt, kann der Body Daten offenlegen oder eine unauthentifizierte Aktion auslösen.

Vier abgestimmte Kontrollen stoppen die Folge an verschiedenen Stellen. Die Lesezugangsdaten dürfen POST nicht autorisieren. Die Automatisierungsdaten dürfen keinen unbekannten Callback-Host erreichen. Die Weiterleitung braucht eine neue Zielentscheidung. Body-Regeln lehnen beliebige Callback-Ziele ab. Keine einzelne Kontrolle trägt die gesamte Abwehr, und freundliche Namen tragen gar nichts dazu bei.

Darum rate ich von einer einmaligen Sitzungsfreigabe für einen generischen Client ab. Das Muster ist beliebt, weil wiederholte Dialoge stören und ein stabiler Tool-Name stabiles Risiko zu beschreiben scheint. Das tut er nicht. Begrenzen Sie die Sitzung auf Zugangsdaten, Ziel und eingeschränkte Operationen, und fragen Sie bei jeder geänderten Koordinate erneut.

Dieselbe Folge kann ohne feindlichen Kommentar scheitern. Ein Agent kann einen Endpunkt aus alter Dokumentation ableiten, eine URL aus einer Fehlermeldung kopieren oder nach einem 403 ähnlich benannte Zugangsdaten wählen. Das sind normale Wiederherstellungsversuche eines Planers. Der Sicherheitsentwurf muss sie erwarten und innerhalb der ursprünglichen Freigabe halten.

Die Kanonisierung muss vor dem Vergleich stattfinden. Decodieren Sie prozentcodierte Pfadsegmente nach einer dokumentierten Regel, lehnen Sie Punktsegmente außerhalb des erlaubten Präfixes ab, normalisieren Sie den effektiven Port und bestimmen Sie die Behandlung wiederholter Abfragenamen. Sieht die Richtlinie `/v2/issues/%2e%2e/admin` als Ticketpfad und der Server löst ihn zu `/v2/admin` auf, autorisieren beide verschiedene Ressourcen. Lehnen Sie mehrdeutige Formen ab, statt jeden Vermittler zu erraten.

Fügen Sie Zugangsdaten nach dieser Arbeit und möglichst nah an der Übertragung ein. Bauen und autorisieren Sie die kanonische Anfrage, binden Sie den Hash, öffnen Sie die genehmigte Verbindung und fügen Sie erst dann das Geheimnis im vertrauenswürdigen Executor ein. Kann Middleware danach Host, Methode oder Body umschreiben, muss ihr Ergebnis in die Autorisierung einfließen oder ihre Freiheit entfallen.

Auch Fehler brauchen einen geschlossenen Weg. Erhalten die gewählten Zugangsdaten 401 oder 403, geben Sie das Ergebnis an den Agenten zurück, ohne automatisch alle Tresoreinträge zu testen. Ein Fallback macht aus einem engen Fehler eine Erkundung von Rechten. Der nächste Versuch muss andere Zugangsdaten ausdrücklich nennen und mit deren Befugnissen und Kontokontext neu geprüft werden.

Behandeln Sie Fehlermeldungen des Zieldienstes ebenfalls als Daten. APIs geben häufig URLs, Operationsnamen oder empfohlene Wiederholungen zurück. Der Planer darf diesen Text für den nächsten Aufruf nutzen, doch er erhält durch einen genehmigten Absender keine Befugnisse. Die nächste Anfrage durchläuft dieselben Ziel- und Detailprüfungen.

Testen Sie dieses Verhalten als Folge, nicht nur mit einzelnen Anfragen. Beginnen Sie mit einem erlaubten Lesezugriff, liefern Sie eine präparierte Weiterleitung oder Fehlerempfehlung, lassen Sie den Planer die Fortsetzung bilden und prüfen Sie, dass die Sitzung nichts erweitert. Lassen Sie dann die erwarteten Zugangsdaten scheitern und bestätigen Sie, dass der Executor nicht still ausweicht. Solche Tests finden vererbte Rechte, die ein Unit-Test einer einzelnen Regel übersieht.

## Protokolle müssen Entscheidung und Aufruf festhalten

Tool-Aufrufprotokolle sind für Vorfallanalysen zu grob. Der Eintrag, ein Agent habe `http_request` aufgerufen, lässt die zentralen Fragen offen: Welche Zugangsdaten wurden verwendet, wohin ging die Anfrage, welche Operation war erlaubt und entsprach das Gesendete der Freigabe?

Protokollieren Sie Sitzungs- oder Prozessidentität, Aufruf- und Zugangsdatenkennung, kanonisches Ziel, aufgelöste Adresse, Methode, redigierte Zusammenfassung, Richtlinienversion, genehmigende Identität, Aktionshash, Antwortstatus, Dauer und Ergebnis. Geheime Bytes und empfindliche Antwortkörper gehören nicht in gewöhnliche Logs. Für beweisrelevante Felder speichern Sie einen Hash oder verschlüsseln sie unter eigenen Zugriffskontrollen.

Protokollieren Sie Ablehnungen ebenso wie Erfolge. Wiederholte abgelehnte Versuche gegen private Adressen oder andere Hosts können Prompt-Injection oder einen fehlerhaften Planer zeigen, bevor etwas nach außen wirkt. Unterscheiden Sie Richtlinienablehnung, menschliche Ablehnung, Netzwerkfehler, Dienstablehnung und lokalen Abbruch, damit eine gescheiterte Verbindung nicht als blockierte Aktion gilt.

Der handelnde Agent darf Belege nicht einfach umschreiben können. Nur anhängbarer Speicher, begrenzte Schreiber und Integritätsprüfungen halten das Protokoll nach einem fraglichen Prozess oder Rechner brauchbar. Sallyport zeichnet Sitzungen und einzelne Aufrufe in einem verschlüsselten, hashverketteten Audit-Log auf, das der Schreiber nicht lesen kann. `sp audit verify` prüft die Chiffretextkette offline ohne Schlüssel. API- und SSH-Zugangsdaten bleiben in einem verschlüsselten Tresor, während die App Aktionen ausführt, ohne Geheimnisse an den Agenten zu geben.

## Ersetzen Sie die breite Freigabe im Executor

Eine generische HTTP-Oberfläche kann ohne generische Befugnisse bleiben. Verschieben Sie Einfügen und Durchsetzung in einen vertrauenswürdigen Executor. Das Modell liefert dann eine Anfrage ohne Zugangsdaten und eine undurchsichtige Referenz.

Eine praktische Migration beginnt mit echten statt gedachten Aufrufen. Gruppieren Sie jüngere Anfragen nach Zugangsdaten, Origin, Methode und Operation. Breite Zugangsdaten und Ziele, die nie gemeinsam vorkommen, sind Kandidaten für eine Trennung. Routen mit mehreren destruktiven Modi in einem Body brauchen eigene Einschränkungen oder separate Zugangsdaten beim Dienst.

Bewerten Sie den bestehenden Verkehr danach zunächst nur berichtend. Kanonisieren Sie jede Anfrage, lösen Sie das Ziel auf und zeigen Sie, ob die geplante Freigabe sie erlauben würde, ohne die Ausführung schon zu ändern. Prüfen Sie überraschende Treffer. Eine Regel für das Lesen von Tickets kann über einen gemeinsamen Host auch Exporte, gelöschte Einträge oder andere Mandanten zulassen.

Erzwingen Sie zuerst die einfachen Grenzen: Zugangsdaten im Besitz des Executors, exakte HTTPS-Origins, keine automatischen Weiterleitungen, ausdrückliche Methoden und Ablehnung privater Adressen, sofern keine bestimmte Integration sie braucht. Ergänzen Sie Pfad-, Abfrage-, Header- und Body-Regeln für folgenreiche Operationen. Behalten Sie einen Ausnahmeweg mit Freigabe pro Aufruf und auffälligem Audit-Eintrag, aber fallen Sie nicht still auf das alte Tool zurück.

Testen Sie die Grenze schließlich mit Varianten bekannter guter Anfragen. Ändern Sie Host-Suffix, Port, DNS-Antwort, Weiterleitungsziel, Zugangsdatenreferenz, Methode, Inhaltstyp, Mandantenfeld, Operationsfeld und codierten Pfad. Jede Variante muss einer beabsichtigten Freigabe entsprechen oder vor dem Einfügen der Zugangsdaten scheitern. Prüfen Sie auch, dass protokollierte, genehmigte und gesendete Bytes denselben Aktionshash teilen.

Die Tool-Liste hilft dem Agenten weiterhin bei der Wahl sinnvoller Operationen. Sie ist nur der falsche Ort, die Autorisierung zu beenden. Behalten Sie die bequeme Aufrufoberfläche, wenn Entwickler sie mögen, aber lassen Sie jeden Netzwerkeffekt erst dann eine Berechtigung erhalten, wenn Zugangsdaten, Ziel, Methode und Details bekannt sind.