Ошибка инструмента отдала модели секрет из stack trace

Агент обращается к платёжному API через инструмент get_invoice. Внешний запрос падает, адаптер возвращает модели полный текст исключения вместе с URL, заголовками и трассировкой. В одном из заголовков находится bearer token. Теперь секрет оказался в контексте модели, трассе вызова и, возможно, в ответе пользователю. Ошибка инструмента стала каналом передачи данных, на который никто не накладывал правила для обычных документов.

Разделите два сообщения об ошибке

Адаптеру нужны две формы результата. Для модели — короткий структурированный ответ вроде {"code":"UPSTREAM_TIMEOUT","retryable":true,"request_id":"r-42"}. Для внутренней диагностики — stack trace в защищённом журнале с тем же request_id. Прежде чем писать даже внутренний лог, удаляйте или маскируйте токены, cookie, персональные данные и тела запросов. То, что журнал доступен только инженерам, не делает сырой секрет безопасным.

Не формируйте безопасный ответ простым усечением исключения до первых 200 символов. Самое начало часто содержит URL с query-параметрами или текст Authorization. Белый список полей надёжнее: стабильный код ошибки, возможность повтора, человекочитаемое описание без деталей внешнего сервиса и непрозрачный ID для поиска в логах. Не отдавайте модели имя внутреннего хоста или путь к файлу, если это не нужно для следующего решения.

Как агент должен действовать дальше

На UPSTREAM_TIMEOUT агент может один раз повторить чтение, если операция идемпотентна и задан лимит повторов. Для записи платежа такого вывода недостаточно: неизвестно, успел ли внешний сервис принять действие до таймаута. Инструмент должен вернуть отдельное состояние «исход неизвестен» и дать безопасный способ проверить операцию по idempotency key или внешнему ID. Текст исключения не должен подсказывать модели обходные пути вроде прямого запроса к базе.

Проверьте адаптер на искусственном исключении, в которое вставлены тестовые строки Bearer test-secret-123 и customer@example.test. В результате инструмента, LLM-трассе и пользовательском ответе этих строк быть не должно. Во внутреннем логе после redaction они тоже не должны оставаться в исходном виде, но связь с request_id и тип ошибки должна сохраняться. Затем проверьте неожиданный тип исключения: fallback обязан выдавать нейтральный код, а не сериализовать объект целиком.

Проверяйте несколько мест, где ошибка могла сохраниться до redaction: callback SDK модели, запись tool-call в observability-платформе, очередь повторов и уведомление оператору. Если вы очищаете только финальный текст ответа, секрет уже мог попасть в telemetry. Сначала фильтруйте исключение у границы инструмента, затем отдельно настраивайте политику хранения трасс. Для отладки достаточно идентификатора запроса, класса ошибки и времени; полный URL или headers должны появляться только в строго ограниченном диагностическом канале, если вообще нужны.

В платном курсе LLM Security PRO: Prompt Injection, утечки, tool-abuse вы работаете с предотвращением утечек секретов, ограничением полномочий tools и security-гейтами. Тест на исключение с canary-секретом удобно включить в CI: он ловит утечку до того, как настоящий токен попадёт в промпт. Откройте программу курса, чтобы настроить этот контур вместе с остальными проверками агента.