Anti-pattern Blind Tool Trust : confiance aveugle dans les tools

Idée en 30 secondes

Blind Tool Trust est un anti-pattern où l'agent accepte le tool output "tel quel", sans vérifier le format, le contenu et la sûreté.

Résultat : les erreurs d'outil passent dans la chaîne de décision. Le modèle "complète" des données manquantes, et le système peut déclencher une action externe incorrecte.

Règle simple : chaque tool output doit passer une validation avant l'étape suivante, sinon le run doit s'arrêter avec un stop_reason clair.

Exemple d'anti-pattern

L'équipe construit un agent de support qui lit le profil client et exécute immédiatement une action dessus.

Quand l'outil renvoie un output invalide ou partiel, l'agent continue quand même.

tool_result = run_tool("get_customer_profile", customer_id)
# account_status missing / credit_limit None, mais le run continue
decision = agent.decide_next_action(tool_result)
execute(decision)

Dans ce schéma, il manque l'étape de protection :

# pas de strict parse
# pas de schema validation
# pas de invariant checks

Pour ce cas, il faut un validation-gate avant d'utiliser le tool output :

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

Si la validation échoue, le run ne doit pas continuer vers une étape write.

Ici, la confiance aveugle dans le tool output ajoute :

• un risque de corruption silencieuse des données
• des actions incorrectes basées sur un output invalide
• des incidents complexes difficiles à expliquer

Pourquoi ça apparaît et ce qui se passe mal

Cet anti-pattern apparaît souvent quand l'équipe pense : "c'est notre outil, on peut lui faire confiance".

Causes typiques :

• l'input est validé, mais l'output ne l'est pas
• la schema validation est repoussée "à plus tard"
• HTTP 200 est interprété comme preuve de données correctes
• espoir que le modèle "se débrouille" avec un output sale

Résultats :

• corruption silencieuse - l'output invalide arrive dans les étapes suivantes
• mauvaises décisions - l'agent agit sur des données partielles ou contradictoires
• risque de side effects - une write action peut partir sur un payload cassé
• debug fragile - difficile de prouver où les données sont devenues invalides
• incidents répétés - sans stop reason explicite, reproduire le problème est difficile

Contrairement à Tool Calling for Everything, le problème principal ici n'est pas le nombre d'appels, mais l'absence de validation obligatoire du résultat d'appel.

Signaux de production typiques que vous faites confiance aux tools "à l'aveugle" :

• l'outil renvoie parfois un payload partiel ou inattendu, mais le run continue
• les logs contiennent presque jamais invalid_tool_output, alors que des incidents data arrivent
• le taux de malformed payload ou tool errors est visible, mais ils se terminent presque jamais en invalid_tool_output
• les erreurs downstream apparaissent plus tard dans la chaîne, pas au point d'entrée du tool output
• la même erreur revient périodiquement dans des scénarios similaires
• l'équipe n'a pas de règle claire pour arrêter un run en cas d'output invalide

Point important : le tool output est une donnée externe, pas une vérité. Sans checks parse/schema/invariant, l'agent prend des décisions critiques sans base fiable.

Bonne approche

Commencez par un pipeline de validation simple pour chaque outil critique. Si l'output ne passe pas les checks, ne laissez pas le run continuer "par inertie".

Cadre pratique :

• vérifiez content_type et les limites techniques de base (par exemple max_chars)
• faites un strict parse du format attendu
• validez le schema et les invariants métier
• en cas d'échec, retournez stop_reason="invalid_tool_output" ou basculez en 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)

Dans ce schéma, le système travaille soit sur des données valides, soit s'arrête de façon transparente et plus sûre.

Test rapide

Si la réponse à ces questions est "oui", vous avez un risque d'anti-pattern Blind Tool Trust :

• Le run continue-t-il même quand le tool output a un format suspect ?
• HTTP 200 est-il interprété comme "données valides" sans schema-check ?
• Des actions avec side effects peuvent-elles démarrer avant validation du tool output ?

Différence avec les autres anti-patterns

Write Access Default vs Blind Tool Trust

En bref : Write Access Default concerne des permissions excessives, alors que Blind Tool Trust concerne une confiance dangereuse dans les données utilisées pour agir.

Agents Without Guardrails vs Blind Tool Trust

En bref : les guardrails pilotent ce que l'agent a le droit de faire, le validation-gate pilote les données sur lesquelles il a le droit d'agir.

Auto-vérification : avez-vous cet anti-pattern ?

Vérification rapide de l'anti-pattern Blind Tool Trust.
Cochez les points pour votre système et regardez le statut ci-dessous.

Vérifiez votre système :

FAQ

Q : Si l'outil est interne, faut-il quand même valider ?
R : Oui. Les services internes ont aussi du schema drift, des partial failures et des réponses incohérentes. Le fait que la source soit interne ne supprime pas le besoin de validation.

Q : Que choisir : fail-closed ou safe-mode ?
R : Pour des scénarios write risqués, généralement fail-closed. Pour des scénarios read-only ou user-facing, un safe-mode avec état dégradé explicite convient souvent mieux.

Q : La schema validation seule est-elle suffisante ?
R : Non. Il faut aussi des invariants (plages, champs obligatoires, règles métier), sinon des données "formellement valides" peuvent rester dangereuses en pratique.

Et ensuite

Anti-patterns proches :

• Write Access Default - quand les actions write sont autorisées sans contraintes suffisantes.
• Agents Without Guardrails - quand le système manque de policies runtime et de limites.
• Tool Calling for Everything - quand les tools sont appelés sans besoin explicite.

Ce qu'il faut construire à la place :

• Allowed Actions - comment limiter les actions de l'agent avec des règles d'accès explicites.
• Tool Execution Layer - où centraliser la validation d'output et les policies d'exécution.
• Stop Conditions - comment terminer les runs de façon transparente sur données invalides.