MCP-Tools mit gefälschten Zugangsdaten sicher testen

MCP-Tools sicher zu testen bedeutet mehr, als ein Produktions-Token durch eine Zeichenfolge namens TEST_TOKEN zu ersetzen. Ein Tool kann den gefälschten Wert verarbeiten, eine freundliche Erfolgsmeldung zurückgeben und trotzdem beim ersten echten Berechtigungsproblem, bei einer verweigerten Freigabe, einem langsamen Anbieter oder einem nur teilweise ausgeführten Schreibvorgang scheitern.

Die Testumgebung muss dir zwei Dinge gleichzeitig beweisen: Das Tool sendet die beabsichtigte Anfrage, und ein Fehler im Test kann keine echte Auswirkung auf die Produktion haben. Wegwerfkonten und gefälschte Zugangsdaten lösen dabei unterschiedliche Teile des Problems. Behandle sie als getrennte Kontrollen.

Gefälschte Zugangsdaten testen die Verarbeitung, nicht die Berechtigung

Ein gefälschtes Zugangsdatenobjekt beweist nur, dass das Tool einen Wert im erwarteten Format korrekt verarbeitet. Es beweist nicht, dass der Anbieter die Zugangsdaten akzeptiert, dass sie die vorgesehenen Berechtigungsbereiche besitzen oder dass ein widerrufener Wert sauber fehlschlägt.

Diese Unterscheidung wird oft verwischt, weil Teams jedes Geheimnis außerhalb der Produktion als gefälschtes Geheimnis bezeichnen. Tatsächlich gibt es drei deutlich unterschiedliche Varianten:

• Eine synthetische Zeichenfolge existiert nur in einem lokalen Stub. Sie kann sich nirgendwo authentifizieren.
• Testzugangsdaten authentifizieren sich bei einem echten Anbieter, aber nur innerhalb eines Wegwerfmandanten oder -projekts.
• Eingeschränkte Produktionszugangsdaten können sich bei der Produktion authentifizieren, auch wenn ihr Berechtigungsbereich klein aussieht.

Die erste Variante gehört in Unit- und Vertragstests. Die zweite gehört in Integrationstests. Die dritte gehört nicht in eine automatisierte Testsuite für Agenten. Ein Zugangsdatenobjekt, das einen Produktionskundendatensatz lesen kann, hat bereits die Grenze überschritten, die du schützen wolltest.

Lass gefälschte Werte dem Format ähneln, das dein Code tatsächlich erhält. Wenn ein API-Client Tokens ohne Präfix oder mit zu geringer Länge ablehnt, verwende einen synthetischen Wert, der diese lokale Validierung besteht. Kopiere kein echtes Token und ändere ein einzelnes Zeichen. Menschen fügen Fixtures in Issue-Tracker, Terminalprotokolle und Chats ein. Ein beinahe echtes Geheimnis bringt das gesamte Risiko beim Umgang damit, aber keinen zusätzlichen Testnutzen.

Ein gutes Fixture benennt die Berechtigung, die es nicht besitzt. stub_token_no_network sagt zum Beispiel mehr aus als token123. Eine Testzugangsdatenreferenz wie billing_test_writer zeigt, dass ein Secret-Store den tatsächlichen Wert auflöst und nicht der Agent. Halte die Referenz stabil und tausche die zugrunde liegenden Testzugangsdaten bei Bedarf aus.

Verwechsle einen erfolgreichen Mock nicht mit einer Autorisierung. Wenn ein Stub 200 zurückgibt, hat er alles akzeptiert, was du in ihn einprogrammiert hast. Das liefert nützliche Hinweise zur Erstellung deiner eigenen Anfrage. Über das Berechtigungsmodell des Anbieters sagt es nichts aus.

Ungültige Eingaben, Ablehnungen und Betriebsfehler getrennt testen

Ein Agent braucht für ein falsches Argument, eine verweigerte Aktion und eine defekte Abhängigkeit jeweils andere Hinweise. Wenn dein MCP-Tool alle drei Fälle in request failed verwandelt, wiederholt der Agent Aktionen, die er abbrechen sollte, und gibt Aktionen auf, die er reparieren könnte.

Verwende ein kleines Vokabular für Ergebnisse und bewahre diese Einordnung im Tool-Ergebnis. Ich nutze fünf Klassen:

• Validierungsfehler: Der Agent hat ein ungültiges oder unvollständiges Argument geliefert. Er kann den Aufruf korrigieren.
• Authentifizierungsfehler: Die Zugangsdaten fehlen, sind abgelaufen, fehlerhaft formatiert oder widerrufen. Derselbe Aufruf wird durch eine Wiederholung nicht funktionieren.
• Autorisierungsablehnung: Die Identität wurde authentifiziert, besitzt aber keine Berechtigung, oder ein Mensch hat eine Freigabe verweigert. Der Agent darf die Grenze nicht durch Ausprobieren umgehen.
• Konflikt: Die Anfrage war gültig, kann aber auf den aktuellen Zustand der Ressource nicht angewendet werden. Der Agent muss möglicherweise zuerst den aktuellen Zustand abrufen.
• Betriebsfehler: Timeout, Verbindungsfehler, Ratenlimit oder Anbieterfehler. Eine Wiederholung kann sinnvoll sein, wenn die Aktion sicher wiederholbar ist.

HTTP definiert die bekannten Bestandteile dieser Trennung. RFC 9110 beschreibt 401 Unauthorized trotz des historisch verwirrenden Namens als Authentifizierungsaufforderung und 403 Forbidden als Ablehnung der Anfrage. Dein Anbieter verwendet diese Statuscodes möglicherweise nicht exakt so. Teste deshalb auch den Antworttext und dokumentierte Fehlercodes. Leite das Verhalten des Agenten nicht allein aus dem Statuscode ab.

Das Tool-Ergebnis des Model Context Protocol unterstützt neben dem Inhalt ein isError-Flag. Verwende es, wenn der Tool-Aufruf fehlgeschlagen ist, und ergänze die handlungsrelevante Kategorie im Text oder in strukturierten Inhalten, die dein Client erwartet. Ein Fehler auf Transportebene bei JSON-RPC und ein Tool-Fehler sind ebenfalls verschieden. Verwende JSON-RPC-Fehler für fehlerhafte Protokollanfragen oder nicht verfügbare Methoden. Gib ein normales tools/call-Ergebnis mit isError: true zurück, wenn das Tool ausgeführt wurde, die Aktion beim Upstream-Dienst aber fehlgeschlagen ist oder abgelehnt wurde.

Diese Antwortform gibt einem Agenten konkrete Hinweise:

{
  "jsonrpc": "2.0",
  "id": 42,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "authorization_rejected: identity billing_test_writer cannot create invoices in tenant test-acme. Request a role change or stop."
      }
    ],
    "isError": true
  }
}

Füge in dieses Ergebnis weder das Bearer-Token noch den Authorization-Header, die vollständige Upstream-Anfrage oder den unveränderten Fehler des Anbieters ein. Fehlermeldungen gehören zum Kontextfenster des Agenten und können daher von Systemen gespeichert werden, die du nicht kontrollierst. Die Meldung muss genug Details für das richtige Verhalten enthalten, aber kein forensisches Protokoll sein.

Wegwerfkonten brauchen eine klare Grenze

Ein Wegwerfkonto ist nur dann sicher, wenn es keinen Weg zu Produktionsressourcen gibt. Eine separate E-Mail-Adresse und die Kennzeichnung test schaffen diese Grenze nicht.

Beginne mit der stärksten Isolierungseinheit des Anbieters. Das kann eine eigene Organisation, ein eigener Mandant, ein Cloud-Projekt, eine Datenbank oder eine selbst gehostete Instanz sein. Lege das Testkonto dort an und prüfe, dass es nicht über eine Kennung, eine gemeinsame Rolle oder einen Standardkonfigurationswert in eine Produktionseinheit wechseln kann.

Gib dem Konto anschließend genau die Berechtigungen, die für den geplanten Test nötig sind. Wenn ein Tool in Tests Rechnungen erstellt, braucht seine Testidentität die Berechtigung, Testrechnungen zu erstellen und aufzulisten. Exportberechtigungen, Administratorzugriff oder Zugriff auf eine gemeinsame Zahlungskonfiguration braucht sie nicht. Breiter Testzugriff ist beliebt, weil er die Einrichtung verkürzt. Gleichzeitig wird dadurch unsichtbar, welche Berechtigungen das Tool tatsächlich benötigt.

Verwende für jede Ressource, die deine Suite erstellt, eine eindeutige Markierung des Testlaufs. Setze sie in ein unterstütztes Metadatenfeld, eine Beschreibung, ein Tag oder den Namen. Eine Markierung macht die Bereinigung sicherer und lässt übrig gebliebene Testartefakte erkennen. Lösche nicht alles, was zufällig in einem Testmandanten liegt. Ein anderer Entwickler könnte dort gerade einen Fehler reproduzieren.

Eine minimale Konfiguration kann so aussehen:

run_id: mcp-it-20250308-7f3c
account: [email protected]
allowed_tenant: test-acme
resource_prefix: mcp-it-20250308-7f3c-
cleanup_after_minutes: 90

Die Konfiguration verhindert einen alltäglichen, aber teuren Fehler: Ein Test Runner zeigt auf den falschen Mandanten, weil eine Umgebungsvariable aus der Shell eines Entwicklers die geprüfte Konfiguration überschreibt. Dein Setup-Code sollte vor der ersten Erstellung die aktuelle Mandantenidentität abrufen und mit allowed_tenant vergleichen. Bei einer Abweichung muss er vor dem ersten Schreibvorgang abbrechen.

Wegwerfbar bedeutet nicht anonym oder herrenlos. Weise einen Verantwortlichen zu, dokumentiere die Ausstellung der Zugangsdaten und lege den Ablauf bewusst fest. Eine vergessene Testidentität ist weiterhin eine Identität mit Zugriff.

Verträge anhand beobachtbarer Anfragen erstellen

Ein guter Vertragstest prüft die Anfrage, die dein Tool sendet, das Ergebnis, das es zurückgibt, und die Informationen, die es nicht preisgibt. Er prüft nicht nur, ob eine Funktion aufgerufen wurde.

Setze einen lokalen HTTP-Stub vor deinen Client und lass ihn Methode, Pfad, Header, Query-Parameter und Body untersuchen. Der Stub sollte unerwartete Felder ablehnen. Nachsichtige Mocks bringen einem Tool bei, versehentliche Argumente zu senden, bis ein echter Anbieter sie ablehnt.

Für ein Tool create_invoice kann ein fokussierter Test diesen Aufruf ausführen:

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "create_invoice",
    "arguments": {
      "tenant": "test-acme",
      "customer_id": "cus_mcp_it_7f3c",
      "amount_cents": 500,
      "currency": "USD"
    }
  }
}

Der Stub sollte POST /v1/invoices erwarten, bestätigen, dass der Authorization-Header den synthetischen Testwert enthält, und prüfen, dass die Anfrage die Laufmarkierung enthält. Er kann eine feste Kennung wie inv_mcp_it_001 zurückgeben. Das MCP-Ergebnis sollte Kennung und Status der Rechnung offenlegen, aber den Authorization-Header niemals wiederholen.

Schreibe für jedes sensible Anfragefeld mindestens eine negative Vertragsprüfung. Sende ein vom Aufrufer geliefertes Feld wie authorization, base_url, account_id oder tenant, falls dein Schema eines davon zulassen könnte. Bestätige, dass das Tool Werte ablehnt oder ignoriert, die eine Aktion zu einem anderen Konto umleiten könnten. Viele Leaks von Zugangsdaten beginnen als harmlos wirkende Möglichkeit, einen eigenen Endpunkt anzugeben.

Teste die Serialisierung der Anfrage anhand der Bytes, auf die es ankommt. Ein Anbieter kann ausgelassene Felder anders behandeln als null, leere Zeichenfolgen anders als fehlende Werte und Zahlen anders als numerische Zeichenfolgen. Agenten erzeugen unerwartete Argumentformen, vor allem wenn eine Tool-Beschreibung keine Einheiten nennt. Dein Schema sollte amount_cents statt amount verwenden, wenn der Anbieter die kleinste Währungseinheit erwartet.

Vertragstests sind auch der richtige Ort für saubere Logs. Erfasse das strukturierte Log-Ereignis und prüfe, dass es eine Zugangsdatenreferenz oder eine redigierte Markierung enthält, niemals das synthetische Geheimnis selbst. Ein gefälschtes Geheimnis wird zu einem echten Offenlegungsproblem, sobald sich Entwickler daran gewöhnen, es überall auszugeben.

Berechtigungen als Matrix statt als Happy Path testen

Eine einzige autorisierte Testidentität zeigt nicht, ob ein Tool Berechtigungen korrekt behandelt. Du brauchst mehrere Identitäten mit bewusst unterschiedlichen Rechten und eine Reihe von Fällen, die das erwartete Ergebnis benennen.

Halte die Matrix klein genug, um sie zu pflegen. Für ein Schreibtool sind diese Fälle meist sinnvoll:

Diese Matrix findet einen häufigen Fehler: Das Tool prüft, ob ein Token vorhanden ist, aber nicht, welchen Mandanten das Token tatsächlich repräsentiert. Der Happy Path funktioniert, weil die Schreibidentität weitreichenden Zugriff besitzt. Der Fehler zeigt sich, wenn ein Agent eine Mandantenkennung erhält und der Client sie verwendet, ohne sie an die ausgewählten Zugangsdaten zu binden.

Führe jeden Matrixfall nach Möglichkeit gegen den echten Wegwerfanbieter aus. Das Verhalten bei geerbten Rollen, Standardbereichen und verzögertem Widerruf unterscheidet sich oft von der Dokumentation. Halte die Fälle getrennt. Wenn ein Test eine Rolle erweitert, die ein anderer Test als nicht vorhanden erwartet, erzeugen parallele Läufe Fehler, die wie Autorisierungsprobleme aussehen.

Erzeuge verbotene Antworten nicht ausschließlich in einem Stub und erkläre die Suite damit für vollständig. Ein Stub bestätigt, dass dein Fehler-Mapping einen 403 erkennt. Die echte Testidentität bestätigt, dass Ausstellung der Zugangsdaten, Anbieter-Konfiguration und Tool-Routing eine tatsächliche Ablehnung erzeugen.

Eine Ausnahme ist sinnvoll: Teste Anbieterantworten, die sich nicht zuverlässig auslösen lassen, etwa fehlerhaftes JSON oder einen ungültigen Inhaltstyp. Dafür ist ein Stub zuständig. Es geht nicht um Reinheit, sondern darum zu wissen, welche Belege jeder Test liefert.

Schreibvorgänge brauchen vor dem Testcode einen Bereinigungsplan

Lege für jedes Tool, das den Zustand verändert, fest, wie der Test diesen Zustand entfernt oder neutralisiert, bevor du den Erfolgstest schreibst. Wenn du die Bereinigung nicht beschreiben kannst, wähle ein anderes Ziel oder eine andere Operation.

Bevorzuge Vorgänge, die Datensätze in einem kurzlebigen Testprojekt erstellen. Vermeide Testaufrufe, die E-Mails senden, eine Karte belasten, ein gemeinsames Geheimnis austauschen, eine Bereitstellung auslösen oder einen echten Dritten kontaktieren. Auch eine Sandbox des Anbieters kann Webhooks an einen Endpunkt senden, den du vor Jahren eingerichtet hast. Prüfe die Begleiteffekte, nicht nur die Bezeichnung der API.

Verwende eine eindeutige Laufmarkierung und bereinige in einem finally-Block oder einem entsprechenden Konstrukt. Die Bereinigung muss tolerieren, dass eine Ressource nie erstellt wurde, nach einer Wiederholung zweimal erstellt wurde oder ein Konto nur teilweise eingerichtet ist. Idempotente Bereinigung spart Zeit, wenn ein Test während der Einrichtung scheitert.

Ein lohnender Fehlerfall sieht so aus: Das Tool sendet eine Erstellungsanfrage. Der Anbieter erstellt den Datensatz, unterbricht aber die Verbindung, bevor er die Antwort zurückgibt. Der Agent sieht einen Betriebsfehler und wiederholt den Aufruf. Ohne Idempotenzwert erzeugt die Wiederholung ein Duplikat. Ohne Laufmarkierung kann die Bereinigung beide Datensätze nicht sicher finden.

Gib der Erstellungsanfrage einen Idempotenzwert, der aus Laufkennung und logischer Aktion abgeleitet wird, nicht aus dem Transportversuch. Erster Versuch und Wiederholung müssen denselben Wert verwenden. Teste anschließend den Fall der abgebrochenen Antwort mit einem Stub, der die erste Anfrage aufzeichnet, die Verbindung schließt und beim erneut empfangenen Idempotenzwert Erfolg zurückgibt. Prüfe, dass auf Anbieterseite nur ein Datensatz existiert.

Unterstützt der Anbieter keine Idempotenz, soll das Tool vor einer Wiederholung anhand einer eindeutigen externen Referenz nachsehen. Dieser Ansatz kann bei parallelen Vorgängen zu Wettläufen führen. Dokumentiere das verbleibende Risiko. Wiederhole Geldbewegungen oder unumkehrbare Schreibvorgänge nicht stillschweigend, nur weil ein generischer HTTP-Client POST für wiederholbar hält.

Timeouts und Ratenlimits zeigen schlechtes Agent-Verhalten

Ein Tool, das Erfolg und 403 korrekt behandelt, kann trotzdem Schaden anrichten, wenn seine Abhängigkeit langsam wird. Agenten wiederholen Aufrufe häufig, weil sie die Aufgabe abschließen wollen. Dein Tool muss ihnen eine begrenzte und wahrheitsgemäße Antwort geben.

Teste einen Verbindungs-Timeout, bevor eine Anfrage den Server erreicht, einen Antwort-Timeout, nachdem der Server die Anfrage erhalten hat, und eine Anbieterantwort mit 429. Diese Fälle unterscheiden sich. Beim ersten ist meist kein Seiteneffekt eingetreten. Beim zweiten kann der Server den Schreibvorgang abgeschlossen haben. Ein 429 kann eine Anweisung zur Wiederholung enthalten, aber verwende sie nur, wenn der Anbieter das Feld dokumentiert und dein Tool seine Bedeutung bewahrt.

Setze kurze Test-Timeouts, damit die Suite nutzbar bleibt, ersetze aber Produktions-Timeouts nicht durch Testwerte im Code. Injiziere eine Uhr oder eine Transportkonfiguration. Ein fest codierter Timeout von zwei Sekunden ist eine Testvereinfachung, die bei einer Bereitstellung zum Ausfall führt.

Deine Assertions sollten neben dem HTTP-Client auch das Verhalten gegenüber dem Agenten abdecken. Gib bei einem Ratenlimit einen Betriebsfehler zurück, der den Anbieter nennt und sagt, ob eine Wiederholung nach einer Wartezeit erlaubt ist. Bei einem Antwort-Timeout nach einem Schreibvorgang muss die Meldung sagen, dass das Ergebnis unbekannt ist, und den Aufrufer anweisen, die Operation über ihren Idempotenzwert oder die externe Referenz zu suchen. Den Fall als einfachen Fehler zu bezeichnen, lädt zu doppelten Schreibvorgängen ein.

Teste Wiederholungen nicht nur über eine Anzahl. Erfasse auch, ob die Wiederholung denselben Idempotenzwert verwendet, ob sie wie vorgesehen gewartet hat und ob sie nach dem konfigurierten Limit beendet wurde. Eine Wiederholungsschleife, die irgendwann endet, kann trotzdem eine Flut von Anfragen erzeugen, ein kleines Testkonto erschöpfen und den eigentlichen Fehler verdecken.

Eine verweigerte Freigabe darf das Ziel nicht verändern

Wenn ein Mensch Agent-Aktionen freigeben kann, teste den Ablehnungspfad gegen einen Endpunkt, an dem ein Seiteneffekt sichtbar wäre. Ein Bildschirm mit dem Hinweis „abgelehnt“ beweist nicht, dass die Ausführungsschicht angehalten wurde.

Richte ein Wegwerfziel mit einem Zähler, einem Markierungsdatensatz oder einer nur anhängbaren Liste von Testereignissen ein. Starte den Agent-Prozess, sende den Tool-Aufruf und verweigere die Sitzung oder den Aufruf. Frage das Ziel anschließend mit einer separaten Testbeobachteridentität direkt ab. Der erwartete Zählerstand bleibt unverändert.

Dieser Test entdeckt einen Fehler in der Reihenfolge: Das Tool startet die Anfrage an den Upstream-Dienst und fragt erst danach um Freigabe, während es auf die Antwort wartet. In einer Demonstration kann dieser Ablauf funktionieren, wenn der Anbieter langsam ist. Er verfehlt den Zweck der Freigabe. Die Autorisierungsentscheidung muss fallen, bevor der Aktions-Dispatcher die Netzwerkverbindung öffnet oder einen SSH-Helfer startet.

Teste einen neuen Agent-Prozess separat von einem zweiten Aufruf im selben Prozess. Für Systeme, die Autorisierung pro Lauf vergeben, sind das unterschiedliche Sicherheitsversprechen. Teste außerdem einen Prozess, dessen Signaturidentität von der erwarteten abweicht. Die Freigabeaufforderung muss genug Herkunftsinformationen zeigen, damit die freigebende Person den vorgesehenen Agenten von einem beliebigen lokalen Prozess unterscheiden kann.

In einem lokalen Mac-Workflow bewahrt Sallyport API- und SSH-Anmeldedaten in seinem verschlüsselten Tresor auf und kann eine Freigabe für jeden neuen Agent-Lauf oder für jede Verwendung eines ausgewählten Zugangsdatenobjekts verlangen. Teste diese Kontrollen an Wegwerf-Endpunkten. Sie sind kein Grund, Tests der vorgelagerten Berechtigungen auszulassen.

SSH-Tests brauchen ein Ziel, das entsorgt werden kann

SSH bringt Fehlerquellen mit, die HTTP-Beispiele verbergen: Host-Prüfung, Quoting von Befehlen, geerbte Umgebungsvariablen, Verhalten der Remote-Shell und Dateien, die nach einer unterbrochenen Verbindung zurückbleiben. Richte automatisierte SSH-Tests für Agenten niemals auf eine Entwickler-Workstation oder einen gemeinsam verwalteten Administrationshost.

Erstelle eine kontrollierte Testmaschine oder eine kurzlebige virtuelle Maschine mit einem eigenen Konto. Gib diesem Konto ein Home-Verzeichnis ohne nützliche Daten, nach Möglichkeit eine eingeschränkte Befehlssammlung und keine Zugangsdaten, mit denen andere Systeme erreicht werden können. Verwende einen eigenen Test-SSH-Schlüssel und entsorge ihn, wenn die Umgebung abläuft.

Teste Befehlsargumente, die eine naive Shell-Konstruktion brechen. Dazu gehören Leerzeichen, Anführungszeichen, Zeilenumbrüche, Pfade, die mit einem Bindestrich beginnen, und Daten, die wie Shell-Syntax aussehen. Das Tool sollte Argumente an den entfernten Befehl übergeben, ohne benutzergelieferte Werte zu einer Shell-Zeichenfolge zusammenzufügen. Wenn die entfernte Schnittstelle nur Shell-Text akzeptiert, beschränke die zulässige Befehlssyntax und lehne alles andere ab.

Ein sicherer Test kann das Ziel auffordern, eine Datei mit der Laufmarkierung zu erstellen und genau diese Datei anschließend zu lesen. Ein Ablehnungstest kann einen Pfad außerhalb des erlaubten Verzeichnisses des Testkontos anfordern und erwarten, dass das Ziel ihn verweigert. Ein Betriebstest kann die SSH-Verbindung nach Beginn des Befehls beenden und anschließend prüfen, ob der Remote-Prozess weiterlief.

Sammle Exit-Status, begrenzte Standardausgabe und begrenzte Standardfehlerausgabe. Gib einem Agenten niemals unbegrenzte Befehlsausgaben zurück. Große Ausgaben verbrauchen Kontext, und Befehlsausgaben enthalten oft Konfigurationswerte, die den Host nie verlassen sollten.

Audit-Belege müssen Agent-Aufruf und Seiteneffekt verbinden

Wenn ein Agententest fehlschlägt, musst du beantworten können, ob das Tool den Aufruf ausgeführt hat, ob der Anbieter ihn erhalten hat und ob die Bereinigung ihn entfernt hat. Eine Sammlung von Konsolentext beantwortet diese Fragen nicht zuverlässig.

Gib jedem Testlauf eine Kennung und führe sie durch MCP-Anfrage, Tool-Log, Anbietermetadaten und Bereinigungslog. Nimm keine Zugangsdaten in diese Kennung auf. Ein nützlicher Beleg enthält Toolname, Aktionskategorie, Zugangsdatenreferenz, Zielmandant, Request-Korrelationskennung, Ergebniskategorie und zurückgegebene Ressourcenkennung.

Halte Agent-Sitzungsdaten getrennt von Aktionsdaten. Eine Sitzung zeigt, welcher Prozess einen Lauf ausgeführt hat und wann du ihn widerrufen hast. Ein Aktionsdatensatz zeigt, welcher externe Aufruf stattgefunden hat. Die Verbindung über eine Korrelationskennung macht einen Ablehnungstest prüfbar: Du kannst zeigen, dass der Agent eine Aktion versucht hat, die Autorisierung sie verweigert hat und kein passender externer Aktionsdatensatz existiert.

Manipulationsnachweise sind wichtig, wenn du Testergebnisse zur Prüfung einer neuen Tool-Grenze nutzt. Sallyport erstellt seine Sitzungs- und Aktivitätsjournale aus einem verschlüsselten, Hash-verketteten Audit-Log. Mit sp audit verify lässt sich diese Kette offline und ohne Tresorschlüssel prüfen. Das ersetzt keine Anbieterlogs, gibt lokalen Tests aber eine Möglichkeit, veränderte Aktionsverläufe zu erkennen.

Behandle Audit-Ausgaben nicht als Ablage für Geheimnisse. Protokolliere Zugangsdatenreferenzen und redigierte Attribute und prüfe diese Regeln in Tests. Der Audit-Trail soll helfen, eine Aktion zu rekonstruieren, darf aber nicht zum einfachsten Ort werden, um den Zugriff zu stehlen, der die Aktion ermöglicht hat.

Ein Release-Kandidat erhält nur schrittweise Produktionszugriff

Ein Tool sollte zunehmend realistische Grenzen durchlaufen: lokale synthetische Stubs, einen echten Wegwerfanbieter, verweigerte und abgelaufene Identitäten, injizierte Fehler und einen Test der menschlichen Freigabe, falls der Workflow eine solche verwendet. Wer direkt in die Produktion springt, weil sich die Sandbox unterscheidet, entdeckt sein Sicherheitsverhalten erst unter Druck.

Halte eine kurze Release-Suite bereit, die bei jeder Änderung läuft, und eine tiefere Suite, die seltener Wegwerfressourcen einrichtet. Die kurze Suite sollte Tool-Schema, Anfrageerstellung, Redigierung und typische Fehler abdecken. Die tiefere Suite sollte echte Berechtigungsbereiche, den Lebenszyklus der Bereinigung, Widerruf und Zielisolierung prüfen.

Bevor du eine neue Aktion für die Produktion freigibst, untersuche die Belege eines absichtlich verweigerten Aufrufs und eines absichtlich unklaren Schreib-Timeouts. Diese Fälle zeigen, ob das Tool eine Grenze respektiert und einem Agenten die Wahrheit sagt, wenn der Anbieter möglicherweise gehandelt hat. Erfolgspfade lassen sich leicht vorbereiten. Bei Ablehnung und Unsicherheit entscheidet sich, ob Produktionszugriff kontrolliert oder leichtfertig erfolgt.