Datei-Uploads von KI-Agenten brauchen klare Grenzen

Ein Upload-Endpunkt ist ein ausgehender Datenkanal, auch wenn Entwickler ihn als Anhangsfunktion bezeichnen. Sobald ein KI-Agent ein Log, einen Export, einen Screenshot oder eine Kundendatei anhängen kann, kann eine vage Anweisung wie «Sende das an den Support» zu einer nicht rückgängig zu machenden Offenlegung werden.

Uploads durch KI-Agenten brauchen klare Grenzen für Bytes, Inhalte und Empfänger. Verankere diese Grenzen in der Aktion, die den Upload ausführt, nicht im Agenten-Prompt und auch nicht in der Fähigkeit eines Reviewers, an einem hektischen Arbeitstag am Ende einen verdächtigen Dateinamen zu erkennen.

Eine Upload-Aktion muss festlegen, was den Dienst verlassen darf

Ein sicherer Upload-Workflow beginnt damit, jede Datei als Objekt mit einem festgelegten Zweck zu behandeln. Der Zweck bestimmt die maximale Größe, akzeptierte Formate, zulässigen Empfänger, erwartete Aufbewahrungsdauer und die Frage, ob ein Mensch den Versand genehmigen muss. Wenn deine API einen beliebigen Multipart-Body und eine vom Aufrufer gelieferte URL akzeptiert, hast du eine allgemeine Route zur Datenexfiltration mit einer angenehmen Entwickleroberfläche geschaffen.

Verwechselt wird oft der Empfang von Dateien durch einen nicht vertrauenswürdigen Client mit dem Versand von Dateien im Auftrag eines Agenten. Klassische Upload-Empfehlungen konzentrieren sich darauf, den eigenen Server vor schädlichen Dateien zu schützen. Diese Absicherung brauchen Uploads durch Agenten ebenfalls. Das unmittelbarere Risiko besteht jedoch darin, Daten vor einem zu weit gefassten Versand zu schützen. Ein PDF kann vollkommen sicher zu analysieren und trotzdem für die Zustellung an ein Ticketsystem ungeeignet sein.

Definiere benannte Upload-Zwecke statt einer allgemeinen Aktion wie upload_file. Ein Zweck wie diagnostic_bundle kann ein komprimiertes Supportpaket an genau einen Supportempfänger erlauben. Ein Zweck wie invoice_export kann eine CSV-Datei an den Empfänger der Buchhaltung senden. Keiner dieser Zwecke sollte in derselben Anfrage einen Pfad, eine Empfänger-URL und eine beliebige Datei akzeptieren.

Ein kleiner Vertrag macht die Grenze sichtbar:

{
  "purpose": "diagnostic_bundle",
  "file_path": "/private/tmp/app-diagnostics-2025-03-08.zip",
  "destination_id": "support-case",
  "case_reference": "CASE-1842"
}

Der Aufrufer wählt einen genehmigten Zweck und liefert die Metadaten, die für die Geschäftsaktion erforderlich sind. Der Upload-Dienst ordnet support-case einem Empfänger zu, den er selbst verwaltet. Er erlaubt dem Aufrufer nicht, diesen Empfänger durch eine URL zu ersetzen, die in einem Ticketkommentar, Dokument oder Tool-Ergebnis eingebettet ist.

Auch Dateipfade müssen kontrolliert werden. Ein Agent sollte Dateien nur aus festgelegten Staging-Verzeichnissen auswählen dürfen. Alternativ kann der Dienst den Anhang selbst aus bekannten Eingaben erzeugen. Wenn ein Agent jeden lesbaren Pfad benennen darf, wird aus der Bitte, Diagnosedaten anzuhängen, eine Bitte, Konfigurationsdateien, SSH-Material, Browserdaten oder den Export eines anderen Benutzers zu lesen.

Größenlimits brauchen zwei Messwerte

Ein Dateilimit sollte einen zu großen Body ablehnen, bevor dein Dienst ihn speichert, scannt oder weiterleitet. Erzwinge das Limit am HTTP-Rand anhand von Content-Length, sofern vorhanden, und zähle beim Lesen zusätzlich die Bytes, weil ein Client den Header weglassen oder falsche Angaben machen kann.

Das Limit muss zum Zweck passen. Ein Limit von 25 MB für eine Kunden-CSV und ein Limit von 25 MB für ein komprimiertes Diagnosepaket sind keine gleichwertigen Entscheidungen. Die CSV kann beim Einlesen durch einen Parser eine wesentlich größere Speicherbelegung verursachen. Das Archiv kann auf ein Vielfaches seiner Übertragungsgröße entpackt werden. Lege deshalb sowohl ein Limit für die Übertragungsgröße als auch eines für die verarbeitete Größe fest.

Erlaube einem Agenten nicht, eine abgelehnte Datei in viele zulässige Anfragen aufzuteilen, sofern der Empfänger Chunked-Uploads nicht ausdrücklich unterstützt und dein Dienst die Gesamtsumme überwacht. Andernfalls wird aus einer 10-MB-Regel eine Übertragung mit 100 Teilen, ohne dass der erwartete Schutz bestehen bleibt.

Lehne frühzeitig ab und gib eine Antwort zurück, mit der sich der Agent sicher erholen kann:

{
  "error": "attachment_too_large",
  "purpose": "diagnostic_bundle",
  "observed_bytes": 12582911,
  "max_bytes": 8388608,
  "safe_alternatives": [
    "create_redacted_diagnostic_bundle",
    "attach_selected_log_window"
  ]
}

Diese Antwort ist wichtig. Wenn die Ablehnung nur «Upload fehlgeschlagen» lautet, versucht ein Agent möglicherweise ein anderes Ziel, komprimiert die Datei oder wiederholt den Versuch immer wieder. Zeige ihm, welche Aktion als Nächstes erlaubt ist, ohne die abgelehnte Datei durch eine Debug-Meldung offenzulegen.

Puffern ist eine weitere stille Fehlerquelle. Viele Frameworks parsen eine Multipart-Anfrage in den Speicher oder ein temporäres Verzeichnis, bevor der Anwendungscode die Größe sieht. Konfiguriere Webserver, Framework-Parser, Reverse-Proxy und Anwendungsleser so, dass sie sich auf ein Limit einigen. Das kleinste Limit gewinnt. Eine unerwartet größere Schicht kann aber trotzdem Speicherplatz belegen, bevor die kleinere Schicht die Anfrage ablehnt.

Miss die Größe auch nach der Verarbeitung, etwa nach Textnormalisierung, Bildkonvertierung, Dokumentextraktion und dem Entpacken von Archiven. Ein Limit, das nur den ursprünglichen Anhang erfasst, kontrolliert weder den Ressourcenverbrauch noch das Offenlegungspotenzial des Materials, das du später erzeugst.

Dateiname und MIME-Header beweisen fast nichts

Prüfungen des Dateityps brauchen unabhängige Belege, weil Dateierweiterung und Content-Type vom Absender stammen. Ein Agent kann eine irreführende Kennzeichnung ohne böse Absicht weiterleiten. Ein Supporttool kann jeden Anhang als application/octet-stream bezeichnen. In beiden Fällen muss der Empfänger anhand der Bytes und der erlaubten Struktur entscheiden.

OWASP empfiehlt im File Upload Cheat Sheet, Erweiterungen per Allowlist zuzulassen, dem Content-Type-Header nicht zu vertrauen, Dateinamen serverseitig zu erzeugen und Uploads außerhalb des Webroots zu speichern. Diese Hinweise sind weiterhin richtig. Workflows mit Agenten brauchen jedoch eine zusätzliche Regel: Prüfe den Typ anhand des benannten Zwecks, bevor der Dienst den entfernten Empfänger kontaktiert. Ein gültiges PDF ist nicht automatisch für jeden Upload-Zweck zulässig.

Nutze mehrere Prüfungen, die unterschiedliche Fragen beantworten:

• Die Erweiterung zeigt, welchen Dateityp der Absender behauptet.
• Signatur-Bytes zeigen, ob der Inhalt wie das behauptete Format beginnt.
• Ein Parser mit begrenzten Ressourcen zeigt, ob die Bytes ausreichend den Anforderungen des Formats entsprechen, um sie sicher zu verarbeiten.
• Eine Inhaltsprüfung zeigt, ob die Datei für diesen Zweck verbotene Inhalte enthält.

Akzeptiere für einen CSV-Export eine kleine Allowlist wie .csv und UTF-8-Text, analysiere eine begrenzte Stichprobe und lehne eingebettete Binärdaten oder ungewöhnlich breite Zeilen ab. Prüfe bei einem PDF die Signatur %PDF-, setze ein Größenlimit und verwende einen Parser mit Zeit- und Speicherlimits, wenn du Seiten untersuchen musst. Dekodiere bei Bildern zunächst die Abmessungen. Ein Bild mit geringer Dateigröße kann beim Dekodieren trotzdem viel zu viel Speicher belegen.

Vermeide einen pauschalen Typ «Archiv». ZIP, TAR und GZIP unterscheiden sich, und jedes Format erzeugt eigene Prüfanforderungen. Wenn ein Geschäftsprozess kein Archiv benötigt, lehne es ab. Ein Format zu akzeptieren, weil Benutzer es gelegentlich wünschen, ist der Weg zu generischen Anhang-Endpunkten.

Benenne akzeptierte Dateien auf der Serverseite um. Bewahre den ursprünglichen Dateinamen nach der Bereinigung als Anzeige-Metadatum auf. Verwende ihn aber nicht als Dateisystempfad, Object-Store-Schlüssel oder Content-Disposition-Wert, ohne ihn zu maskieren. Namen können Steuerzeichen, irreführende Unicode-Zeichen, Pfadtrenner und Zeichenfolgen enthalten, die nachgelagerte Logs verändern.

Zielprüfungen müssen Weiterleitungen überstehen

Eine Empfänger-Allowlist muss den exakten Ort benennen, der die Datei erhalten darf. https://example.com zu erlauben reicht nicht aus, wenn der HTTP-Client Weiterleitungen zu einem anderen Host folgt, eine interne Adresse auflöst oder einen anderen Port akzeptiert.

Speichere Ziele als serverseitige Datensätze mit festem Schema, Host, Port, Pfadpräfix, Anmeldungsidentität, Aufbewahrungserwartung und erlaubten Zwecken. Die Aktion erhält destination_id, niemals einen frei formulierbaren Endpunkt. Wenn ein Empfänger eine Fall-ID im Pfad benötigt, konstruiere sie aus einer eingeschränkten Kennung, statt eine vollständige URL vom Agenten zu übernehmen.

Bei jedem Versand sollte der HTTP-Client diese Prüfungen erzwingen:

1. Verlange HTTPS, sofern keine dokumentierte interne Ausnahme besteht.
2. Vergleiche Host und Port der Anfrage vor dem Verbindungsaufbau mit dem Zieldatensatz.
3. Deaktiviere Weiterleitungen standardmäßig. Wenn ein Empfänger Weiterleitungen benötigt, prüfe jedes Weiterleitungsziel gegen denselben Datensatz, bevor du ein weiteres Byte sendest.
4. Lehne IP-Literale, Loopback-Adressen, Link-Local-Adressen und private Bereiche ab, sofern dieses Ziel nicht ausdrücklich für einen kontrollierten internen Dienst eingerichtet wurde.
5. Lege erlaubtes Pfadpräfix und HTTP-Methode fest, statt einen ganzen Host freizugeben.

Der vierte Punkt wird häufig als SSRF-Schutz bezeichnet, und das ist er auch. Er verhindert außerdem eine versehentliche Offenlegung durch einen Agenten, der einer URL aus einer Aufgabenbeschreibung folgt. Ein Upload-Client mit Zugriff auf interne Netzwerke darf Aufgabentext niemals als Berechtigung verstehen, eine Adresse zu kontaktieren.

Leite den ursprünglichen Autorisierungskontext nicht weiter. Die Zugangsdaten für eine Fallmanagement-API sollten ausschließlich zu diesem Empfänger und dieser Aktion gehören. Ein Upload-Gateway, das beliebige Agenten-Header kopiert, schafft einen einfacheren Weg für Header-Injection und ermöglicht es einem Agenten, indirekt Zugangsdaten auszuwählen.

Protokolliere nach Weiterleitungen die endgültige URL, aber maskiere Abfragewerte in Betriebslogs. Query-Strings enthalten häufig signierte Upload-Tokens. Das Ziel zu protokollieren ist nützlich. Einen verwendbaren Autorisierungstoken zu reproduzieren wäre fahrlässig.

Logs brauchen einen bewusst gestalteten Exportweg

Logs sind die Anhangsklasse, die Teams am meisten unterschätzen. Sie enthalten Request-Header, Kundenkennungen, SQL-Fragmente, Stacktraces, interne Hostnamen und manchmal vollständige Request- oder Response-Bodies. Nur weil ein Log in einem Entwicklerverzeichnis liegt, ist es nicht sicher, es per E-Mail zu versenden oder hochzuladen.

Löse das nicht mit einer Anweisung, die dem Agenten sagt, er solle «Geheimnisse entfernen». Agenten können Formate übersehen, zu viel entfernen oder eine verdächtige Zeichenfolge als harmlosen Kontext einstufen. Erstelle einen Builder für Diagnosepakete, der bekannte Dateien liest, deterministische Filter anwendet und ein neues Artefakt in einem Staging-Verzeichnis erzeugt.

Eine praktische Filterrichtlinie kann ganze Felder entfernen, statt nach jedem möglichen Geheimnismuster zu suchen. Entferne standardmäßig Authorization, Cookie, Set-Cookie, API-Schlüsselfelder, Sitzungskennungen und Request-Bodies. Ersetze Kundenkennungen durch stabile lokale Tokens, wenn eine Zuordnung wichtig ist. Beschränke Zeitstempel auf das Incident-Fenster, statt mehrere Wochen Historie zu versenden.

Das ist beispielsweise eine sicherere Form eines Diagnoseeintrags als ein roher HTTP-Trace:

{
  "time": "2025-03-08T14:22:11Z",
  "request_id": "local-7f3c",
  "method": "POST",
  "route": "/v1/reports",
  "status": 502,
  "upstream": "reporting-service",
  "authorization": "[removed]",
  "body": "[omitted]"
}

Der Paket-Builder sollte ein Manifest mit Dateinamen, Byte-Anzahlen, Hashes und angewendeten Filtern erzeugen. So erhält ein Reviewer etwas Konkretes zur Prüfung, ohne jeden Anhang öffnen zu müssen. Der Empfänger kann außerdem einen gekürzten oder veränderten Upload erkennen.

Für Datenbankexporte gilt eine strengere Regel. Ein Agent sollte keinen Produktions-Export anhängen, nur weil in einem Ticket «Sende ein Beispiel» steht. Erzeuge stattdessen ein Artefakt nur mit dem Schema, eine zweckgebundene Abfrage mit genehmigten Spalten oder eine synthetische Reproduktion. Wenn ein Incident echte Kundendatensätze erfordert, muss das eine separate Aktion mit ausdrücklichem Ziel, Umfang und menschlicher Genehmigung sein.

Screenshots verdienen denselben Verdacht. Sie können Kundenkonten, Nachrichten, Browser-Tabs, Benachrichtigungen und lokale Pfade enthalten. Schneide den Inhalt zu oder erzeuge über ein kontrolliertes Tool eine fokussierte Aufnahme, statt dem Agenten ein umfangreiches Screenshot-Verzeichnis zu überlassen.

Archive und Office-Dokumente verbergen mehr als eine Datei

Ein Archiv erzeugt innerhalb des ersten Uploads eine zweite Menge von Dateien. Prüfe vor dem Versand die Liste seiner Elemente und setze Limits für Anzahl der Elemente, komprimierte Bytes, entpackte Bytes, Pfadtiefe und Verschachtelung. Lehne Einträge mit absoluten Pfaden, ..-Traversal, doppelten Namen oder Symlinks ab.

Eine ZIP-Datei mit 2 MB auf dem Datenträger kann sich auf eine Größe entpacken, die einen Worker oder Empfänger erschöpft. Das wird meist als Dekompressionsbombe bezeichnet. Das Problem beschränkt sich jedoch nicht auf böswillige Eingaben. Build-Systeme können versehentlich riesige Archive erzeugen, und ein Agent kann die erste Datei anhängen, die wie ein Export aussieht.

Für Office-Dokumente gilt Ähnliches. Moderne Dokumentformate enthalten oft ZIP-Container, eingebettete Medien, Metadaten, Kommentare, Änderungsverfolgungen und externe Beziehungen. Ein Dokument kann auf der Seite redigiert wirken und trotzdem früheren Text oder Autoreninformationen in seinem Paket behalten. Wenn der Workflow nur gerenderte Inhalte benötigt, erzeuge aus genehmigten Daten ein neues PDF, statt das bearbeitbare Original weiterzuleiten.

Versuche nicht, beliebige Dokumente im Anfragepfad rekursiv zu «bereinigen». Das Parsen und Umschreiben komplexer Formate bringt eigene Sicherheits- und Zuverlässigkeitsrisiken mit sich. Für einen begrenzten Workflow akzeptierst du eine begrenzte Menge erzeugter Artefakte. Bei einem außergewöhnlichen Dokument leitest du den Vorgang an einen menschlichen Prüfprozess weiter, der die tatsächliche Datei und ihr Ziel untersuchen kann.

Der Aktionsvertrag sollte unsichere Anfragen unmöglich machen

Ein Tool für Agenten sollte Auswahlmöglichkeiten anbieten, die zu deinen Kontrollen passen, nicht einen Builder für rohe HTTP-Anfragen. Wenn das Tool url, headers, file_path und method anbietet, hat die Richtlinie bereits den größten Teil ihrer Form verloren.

Verwende ein Anfrageschema, in dem nicht vertrauenswürdige Felder die Absicht beschreiben und vertrauenswürdige Datensätze die Autorität liefern. Dieses Beispiel hält Empfänger, Zugangsdaten und erlaubte Dateiklasse außerhalb der Kontrolle des Agenten:

{
  "action": "send_attachment",
  "purpose": "customer_export",
  "destination_id": "finance-import",
  "artifact_id": "exp_8c4e1a",
  "note": "March reconciliation correction"
}

Der Dienst löst artifact_id zu einem bereitgestellten Objekt auf, das er selbst erstellt oder über einen separaten Intake-Workflow akzeptiert hat. Er berechnet Digest und erkannten Typ selbst. destination_id wird zu einem festen Empfängerdatensatz aufgelöst. Die Zugangsdaten für den Empfänger werden erst beim Versand hinzugefügt. Der Agent sieht diese Zugangsdaten nie und kann nach einer Genehmigung keinen zweiten Empfänger einsetzen.

Das Ergebnis der Vorabprüfung sollte genug Details für eine informierte Entscheidung enthalten:

{
  "decision": "approval_required",
  "artifact": {
    "name": "reconciliation-2025-03.csv",
    "bytes": 482913,
    "detected_type": "text/csv",
    "sha256": "a4d1...c09e"
  },
  "destination": {
    "label": "Finance import",
    "host": "imports.example.internal",
    "path": "/v2/reconciliation"
  },
  "reason": "customer_export requires approval"
}

Zeige einem Reviewer nicht nur den Dateinamen und eine Schaltfläche zum Genehmigen. Zeige gemessene Größe, erkannten Typ, Zielhost, Zielbezeichnung und Zweck. Bei sensiblen Dateien sollte die Genehmigungsansicht ein Klassifizierungsergebnis oder Manifest in Stichprobenform zeigen, nicht den vollständigen Inhalt.

Artefakt-IDs sollten kurzlebig und auf einen Zweck beschränkt sein. Ein bereitgestelltes Diagnosepaket sollte nach dem Schließen des Supportfalls nicht als allgemeines Upload-Objekt wiederverwendbar bleiben. Binde es bei der Erstellung an Zweck und Empfänger und lasse es nach einem kurzen betrieblichen Zeitraum ablaufen.

Wiederholungen brauchen Idempotenz. Netzwerkfehler sind häufig, und Agenten wiederholen Anfragen aggressiv. Erzeuge das Idempotenz-Token auf Aktionsebene, binde es an Artefakt-Digest und Ziel und verwende es nur für denselben vorgesehenen Versand erneut. Eine Wiederholung mit geändertem Pfad oder Digest darf die frühere Autorisierung nicht übernehmen.

Menschliche Genehmigung funktioniert, wenn sie eine echte Grenze markiert

Eine Genehmigung ersetzt keine Validierung. Ein Mensch kann in einem Dialogfenster nicht zuverlässig eine Dekompressionsbombe, eine getarnte Datei oder einen Weiterleitungsfehler erkennen. Die Genehmigung gilt für eine Entscheidung, die eine Richtlinie nicht automatisch treffen kann: ob dieser konkrete Kundenexport für diesen Incident an diesen Empfänger gehen soll.

Nutze eine Genehmigung pro Aufruf für besonders sensible Sendungen, neue Empfänger, Produktions-Exporte und umfangreiche Diagnoseartefakte. Routineartefakte mit engem Umfang können unter einem genehmigten Zweck übertragen werden, wenn Ziel und Inhalte begrenzt sind. Wenn ein Mensch jeden Testbericht genehmigen muss, klickt er irgendwann ungelesen weiter.

Der Genehmigungsdatensatz sollte an Artefakt-Digest, erklärten Zweck und Zieldatensatz gebunden sein. Ändert sich einer dieser Werte, muss die Genehmigung verworfen werden. Ein Dateiname reicht nicht aus, da zwei Dateien denselben Namen, aber unterschiedliche Bytes haben können.

Sallyport kann den Agenten von den Zugangsdaten für einen HTTP-Upload fernhalten. Die Option zur Genehmigung pro Schlüssel passt zu Sendungen, bei denen jedes Mal eine Person entscheiden soll. Das macht einen Vertrag auf Anwendungsebene für Artefakte trotzdem nicht überflüssig, denn das Gateway kann nicht erkennen, ob eine Kunden-CSV in ein Supportticket gehört.

Führe zwei Audit-Ansichten. Eine zeigt, welcher Agentenlauf die Berechtigung zum Handeln erhalten hat. Die andere dokumentiert jeden Übertragungsversuch und sein Ergebnis. Ein Audit-Datensatz sollte Digest, gemessene Bytes, Typbewertung, Zweck, Empfängerdatensatz, Entscheidung, Antwortstatus und Zeitpunkt enthalten. Geheimnisse und vollständige Dateiinhalte gehören, sofern du sie überhaupt aufbewahrst, an einen anderen Ort.

Teste Ablehnungspfade, bevor ein Agent sie findet

Eine Richtlinie, die nur im Erfolgsfall funktioniert, ist unvollständig. Baue einen isolierten Empfänger, der die exakt empfangene Anfrage aufzeichnet, und verwende anschließend Testdateien, die jede Grenze auslösen.

Beginne mit einer einfachen Upload-Anfrage an deinen Testempfänger:

curl -i -X POST https://receiver.test/attachments \\
  -H 'Authorization: Bearer test-token' \\
  -F 'file=@fixtures/diagnostic.zip;type=application/zip' \\
  -F 'case_reference=CASE-1842'

Ein erfolgreicher Test sollte Methode, endgültigen Host, Pfad, Digest und Größe bestätigen. Aussagekräftig sind vor allem die Tests, die beweisen, dass der Empfänger nichts erhalten hat. Stelle sicher, dass ein zu großer Body vor der Weiterleitung abgelehnt wird, ein gefälschter text/plain-Header keine Binärdaten durchlässt und ein nicht gelistetes Ziel niemals eine Verbindung erhält.

Nimm diese Fälle in deine Testsuite auf:

• Eine gültige Erweiterung mit nicht übereinstimmenden Signatur-Bytes.
• Ein komprimiertes Archiv, dessen entpackte Größe die Regel überschreitet.
• Eine Weiterleitung von einem erlaubten zu einem nicht erlaubten Host.
• Eine Log-Datei mit einem Autorisierungs-Header und einer Kunden-E-Mail-Adresse.
• Eine Wiederholung mit demselben Idempotenz-Token, aber anderen Dateibytes.

Untersuche während dieser Tests die Serverlogs. Du prüfst zwei Dinge: dass die Übertragung nicht stattgefunden hat und dass deine eigenen Logs weder den abgelehnten Body noch Bearer-Token oder signierte URL aufbewahrt haben. Teams reparieren oft den Netzwerkpfad und lassen dasselbe sensible Material in Exception-Traces zurück.

Führe die Tests über dieselbe Agenten-Tool-Schnittstelle aus, die Produktionsagenten verwenden. Ein sicherer interner HTTP-Client hilft nicht, wenn der Wrapper für Agenten eine beliebige URL auswählen oder den Artefakt-Staging-Pfad umgehen kann.

Mache den sicheren Weg einfacher als den direkten Weg

Teams umgehen Upload-Kontrollen, wenn der genehmigte Weg langsam, unklar oder für alltägliche Supportarbeit ungeeignet ist. Baue eine kleine Gruppe von Artefakten, die Menschen tatsächlich brauchen: ein redigiertes Diagnosepaket, einen begrenzten Export, einen erzeugten Bericht und einen Incident-Screenshot mit klaren Grenzen. Jeder sollte für einen Agenten einfach per Namen anforderbar sein.

Halte den generischen Roh-Upload aus der Tool-Liste für Agenten heraus. Wenn ein Entwickler ihn für einen ungewöhnlichen Fall braucht, verlange einen interaktiven betrieblichen Prozess, in dem er Datei und Empfänger mit vollständigem Kontext auswählt. Diese Unbequemlichkeit ist angemessen, weil die Aktion keine zuverlässige automatische Klassifizierung ermöglicht.

Prüfe abgelehnte Sendungen genauso ernst wie erfolgreiche. Eine Häufung zu großer Pakete bedeutet, dass dein Diagnoseartefakt falsch gestaltet ist. Wiederholte Versuche, Logs an einen neuen Host zu senden, können bedeuten, dass die Zielliste eine begründete Erweiterung braucht. Es kann aber auch heißen, dass ein Agenten-Prompt versucht, deine Kontrollen zu umgehen. Der Unterschied wird nur im Datensatz sichtbar, wenn Zweck, Dateibewertung und Empfängerentscheidung gemeinsam erfasst werden.

Die erste Änderung, die ich vornehmen würde, ist einfach: Entferne frei formulierbare URLs und beliebige Dateipfade aus der Upload-Aktion für Agenten. Sobald die Aktion nur noch bereitgestellte Artefakte, benannte Zwecke und Ziel-IDs akzeptiert, haben Größenlimits und Inhaltsprüfungen einen verlässlichen Ansatzpunkt.