Анти-патерн Blind Tool Trust: сліпа довіра до tools

Ідея за 30 секунд

Blind Tool Trust — це анти-патерн, коли агент приймає tool output "як є", без перевірки формату, змісту і безпечності.

У результаті помилки інструмента проходять далі в ланцюг рішень: модель "додумує" відсутні дані, а система може зробити неправильну зовнішню дію.

Просте правило: будь-який tool output перед наступним кроком має пройти валідацію або завершити run зі зрозумілим stop_reason.

Приклад анти-патерну

Команда будує support-агента, який читає профіль клієнта і одразу на його основі виконує дію.

Коли інструмент повертає невалідний або частковий output, агент усе одно йде далі.

tool_result = run_tool("get_customer_profile", customer_id)
# account_status missing / credit_limit None, але run іде далі
decision = agent.decide_next_action(tool_result)
execute(decision)

У такій схемі немає захисного етапу:

# немає strict parse
# немає schema validation
# немає invariant checks

Для цього кейсу потрібен validation-gate перед використанням tool output:

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

Якщо перевірка не пройдена, run не має продовжуватись у write-крок.

У цьому випадку сліпа довіра до tool output додає:

• ризик тихої корупції даних
• помилкові дії на базі невалідного output
• складні інциденти, які важко пояснити

Чому виникає і що йде не так

Цей анти-патерн часто з’являється, коли команда вважає, що "інструмент же наш, отже йому можна довіряти".

Типові причини:

• перевіряють input, але не перевіряють output
• валідацію схеми відкладають "на потім"
• сприймають HTTP 200 як ознаку коректних даних
• сподіваються, що модель "сама розбереться" з брудним output

У результаті виникають проблеми:

• тиха корупція — невалідний output потрапляє у наступні кроки
• неправильні рішення — агент діє на часткових або суперечливих даних
• ризик side effects — write-дія може статись на базі зламаного payload
• крихкий дебаг — важко довести, де саме дані стали невалідними
• повторні інциденти — без явного stop_reason проблему відтворити складно

На відміну від Tool Calling for Everything, тут головна проблема не в кількості викликів, а в тому, що результат виклику не проходить обов’язкову перевірку.

Типові production-сигнали, що ви довіряєте tools "всліпу":

• інструмент інколи повертає частковий або неочікуваний payload, але run іде далі
• в логах майже немає invalid_tool_output, хоча інциденти з даними трапляються
• частка malformed payload або tool errors помітна, але вони майже ніколи не завершуються invalid_tool_output
• downstream-помилки проявляються пізніше в ланцюгу, а не в точці отримання tool output
• одна і та сама помилка періодично повертається у схожих сценаріях
• команда не має чіткого правила, коли зупиняти run через невалідний output

Важливо, що tool output — це зовнішні дані, а не істина. Без parse/schema/invariant перевірок агент приймає критичні рішення без надійної опори.

Правильний підхід

Починайте з простого validation-pipeline для кожного критичного інструмента. Якщо output не проходить перевірку, не продовжуйте run "за інерцією".

Практична рамка:

• перевіряйте content_type і базові технічні межі (наприклад, max_chars)
• робіть strict parse для очікуваного формату
• валідуйте schema й бізнес-інваріанти
• при фейлі віддавайте stop_reason="invalid_tool_output" або переходьте у 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)

У такій схемі система або працює на валідних даних, або зупиняється прозоро і безпечніше.

Швидкий тест

Якщо на ці питання відповідь "так", у вас є ризик анти-патерну Blind Tool Trust:

• Чи run продовжується навіть коли tool output має сумнівний формат?
• Чи HTTP 200 інтерпретується як "дані валідні" без schema-перевірки?
• Чи side-effect дії можуть запускатись до валідації tool output?

Чим відрізняється від інших анти-патернів

Write Access Default vs Blind Tool Trust

Якщо коротко: Write Access Default — про зайві права, а Blind Tool Trust — про небезпечну довіру до даних, на основі яких приймається дія.

Agents Without Guardrails vs Blind Tool Trust

Якщо коротко: guardrails керують тим, що агенту дозволено робити, а validation-gate — тим, на яких даних йому взагалі дозволено діяти.

Самоперевірка: чи немає у вас цього анти-патерну

Швидка перевірка на anti-pattern Blind Tool Trust.
Відмічайте пункти під вашу систему і дивіться статус нижче.

Перевірте свою систему:

FAQ

Q: Якщо інструмент внутрішній, його теж треба валідовувати?
A: Так. Внутрішні сервіси теж мають schema drift, partial failures і неконсистентні відповіді. Джерело не скасовує потребу валідації.

Q: Що обрати: fail-closed чи safe-mode?
A: Для ризикових write-сценаріїв зазвичай fail-closed. Для read-only або користувацьких сценаріїв часто підходить safe-mode з явним деградованим станом.

Q: Чи достатньо лише schema validation?
A: Ні. Потрібні ще інваріанти (діапазони, required поля, бізнес-правила), інакше "формально валідні" дані можуть залишатись практично небезпечними.

Що далі

Схожі anti-patterns:

• Write Access Default — коли write-дії дозволені без достатніх обмежень.
• Agents Without Guardrails — коли системі бракує runtime-політик і меж.
• Tool Calling for Everything — коли інструменти викликаються без явної потреби.

Що будувати замість цього:

• Allowed Actions — як обмежити дії агента через явні правила доступу.
• Tool Execution Layer — де централізувати валідацію output і політики виконання.
• Stop Conditions — як завершувати run прозоро при невалідних даних.