Anti-Pattern Blind Tool Trust: blindes Vertrauen in tools

Idee in 30 Sekunden

Blind Tool Trust ist ein Anti-Pattern, bei dem der Agent Tool-Output "wie er ist" übernimmt, ohne Format, Inhalt und Sicherheit zu prüfen.

Dadurch wandern Tool-Fehler in die Entscheidungskette: das Modell "ergänzt" fehlende Daten, und das System kann eine falsche externe Aktion ausführen.

Einfache Regel: Jeder Tool-Output muss vor dem nächsten Schritt validiert werden, sonst muss der Run mit klarem stop_reason enden.

Beispiel für das Anti-Pattern

Das Team baut einen Support-Agenten, der ein Kundenprofil liest und sofort darauf basierend eine Aktion ausführt.

Wenn das Tool ungültigen oder partiellen Output liefert, läuft der Agent trotzdem weiter.

tool_result = run_tool("get_customer_profile", customer_id)
# account_status missing / credit_limit None, aber der Run geht weiter
decision = agent.decide_next_action(tool_result)
execute(decision)

In diesem Setup fehlt eine Schutzstufe:

# kein strict parse
# keine schema validation
# keine invariant checks

Für diesen Fall braucht ihr ein validation-gate vor der Nutzung des Tool-Outputs:

parsed = validate_tool_output(tool_result)
if not parsed.ok:
    return stop("invalid_tool_output")

Wenn die Prüfung fehlschlägt, darf der Run nicht in einen write-Schritt weitergehen.

In diesem Fall fügt blindes Vertrauen in Tool-Output hinzu:

• Risiko stiller Datenkorruption
• falsche Aktionen auf Basis ungültigen Outputs
• komplexe Incidents, die schwer zu erklären sind

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn das Team denkt: "das Tool ist doch von uns, also kann man ihm vertrauen".

Typische Ursachen:

• input wird geprüft, output aber nicht
• schema validation wird auf "später" verschoben
• HTTP 200 wird als Zeichen korrekter Daten verstanden
• Hoffnung, dass das Modell mit schmutzigem Output "selbst klarkommt"

Daraus folgen Probleme:

• stille Korruption - ungültiger Output landet in späteren Schritten
• falsche Entscheidungen - der Agent handelt auf partiellen oder widersprüchlichen Daten
• side effects Risiko - write-Aktionen können auf kaputtem Payload passieren
• fragiles Debugging - schwer nachzuweisen, wo Daten ungültig wurden
• wiederholte Incidents - ohne klaren stop reason ist Reproduktion schwer

Im Unterschied zu Tool Calling for Everything liegt das Hauptproblem hier nicht in der Anzahl der Aufrufe, sondern darin, dass Call-Resultate keine verpflichtende Validierung durchlaufen.

Typische Production-Signale, dass ihr tools "blind" vertraut:

• ein Tool liefert gelegentlich partiellen oder unerwarteten Payload, aber der Run geht weiter
• in Logs gibt es fast nie invalid_tool_output, obwohl Daten-Incidents auftreten
• malformed payload oder tool errors sind sichtbar, enden aber fast nie mit invalid_tool_output
• Downstream-Fehler treten später in der Kette auf, nicht am Punkt des Tool-Outputs
• derselbe Fehlertyp kehrt in ähnlichen Szenarien immer wieder
• das Team hat keine klare Regel, wann ein Run wegen ungültigem Output stoppen muss

Wichtig: Tool-Output sind externe Daten, nicht Wahrheit. Ohne parse/schema/invariant Checks trifft der Agent kritische Entscheidungen ohne verlässliche Grundlage.

Richtiger Ansatz

Startet mit einer einfachen Validation-Pipeline für jedes kritische Tool. Wenn der Output die Prüfung nicht besteht, darf der Run nicht "aus Gewohnheit" weiterlaufen.

Praktischer Rahmen:

• prüft content_type und grundlegende technische Grenzen (z. B. max_chars)
• führt strict parse für das erwartete Format aus
• validiert schema und Business-Invarianten
• bei Fehlern liefert stop_reason="invalid_tool_output" oder wechselt in safe-mode

def use_customer_profile(customer_id: str):
    raw = run_tool("get_customer_profile", customer_id)

    parsed = parse_json_strict(raw, max_chars=200_000)  # rejects malformed JSON
    profile = validate_schema("customer_profile", parsed)
    if not check_invariants(profile):  # required fields, ranges, business rules
        return stop("invalid_tool_output")  # or switch to safe-mode for read-only paths

    action = agent.decide_next_action(profile)
    return execute(action)

In diesem Setup arbeitet das System entweder mit validen Daten oder stoppt transparent und sicherer.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet sind, habt ihr ein Risiko für das Anti-Pattern Blind Tool Trust:

• Läuft der Run weiter, obwohl Tool-Output ein verdächtiges Format hat?
• Wird HTTP 200 als "Daten sind valide" interpretiert, ohne schema-Prüfung?
• Können side-effect Aktionen vor der Tool-Output-Validierung starten?

Worin es sich von anderen Anti-Patterns unterscheidet

Write Access Default vs Blind Tool Trust

Kurz gesagt: Write Access Default betrifft zu viele Rechte, Blind Tool Trust betrifft gefährliches Vertrauen in Daten, auf denen Aktionen basieren.

Agents Without Guardrails vs Blind Tool Trust

Kurz gesagt: Guardrails steuern, was der Agent tun darf, validation-gates steuern, auf welchen Daten er überhaupt handeln darf.

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für das Anti-Pattern Blind Tool Trust.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Wenn ein Tool intern ist, muss es trotzdem validiert werden?
A: Ja. Interne Services haben ebenfalls schema drift, partial failures und inkonsistente Responses. Eigentum an der Quelle ersetzt keine Validierung.

Q: Was wählen: fail-closed oder safe-mode?
A: Für riskante write-Szenarien meist fail-closed. Für read-only oder user-facing Szenarien oft safe-mode mit explizitem degradierten Zustand.

Q: Reicht schema validation allein?
A: Nein. Es braucht zusätzlich Invarianten (Ranges, Pflichtfelder, Business-Regeln), sonst können "formal valide" Daten praktisch weiterhin unsicher sein.

Was als Nächstes

Ähnliche Anti-Patterns:

• Write Access Default - wenn write-Aktionen ohne ausreichende Begrenzungen erlaubt sind.
• Agents Without Guardrails - wenn dem System Runtime-Policies und Grenzen fehlen.
• Tool Calling for Everything - wenn tools ohne expliziten Bedarf aufgerufen werden.

Was ihr stattdessen bauen solltet:

• Allowed Actions - wie Agent-Aktionen über explizite Zugriffsregeln begrenzt werden.
• Tool Execution Layer - wo Output-Validierung und Ausführungspolicies zentralisiert werden.
• Stop Conditions - wie Runs bei ungültigen Daten transparent beendet werden.