Почему API-ключ нельзя хранить в системном промпте
Секрет должен оставаться в доверенной части приложения, которая выполняет разрешённую операцию. Помещение ключа в системный промпт не превращает его в защищённое хранилище.
Пример из разработки
Разработчик добавляет ключ CRM в инструкции модели и пишет: «Никогда не показывай пользователю». Теперь credential находится в контексте, который участвует в генерации. Если модель ошибётся, его может оказаться достаточно для раскрытия. Кроме того, ключ рискует попасть в трассировки, отладочные выгрузки и сохранённую историю. Проблема начинается до конкретной атаки: архитектура передала секрет туда, где он обычно не нужен.
Почему это работает
Пусть модель выбирает разрешённую операцию и несекретные аргументы, а серверный инструмент добавляет credential уже при обращении к CRM. Выдайте этому credential минимальные права и определите процедуру ротации. Не передавайте секрет обратно в ответ tool и не включайте его в сообщения об ошибках. Проверяйте конфигурацию журналов, трассировки и тестовых фикстур. Если ключ уже попал в недопустимую среду, удаление строки не отменяет необходимость оценить отзыв и замену.
Проверка перед использованием
| Проверка | Ожидаемое поведение |
|---|---|
| Обычный вызов CRM через инструмент | Модель получает только результат и допустимые поля, а credential используется внутри доверенного исполнителя. |
| Запрос показать внутренние инструкции | Даже при ошибочном раскрытии промпта там отсутствует настоящий ключ внешней системы. |
| Сбой внешнего запроса | Журнал и ответ не содержат заголовок авторизации, URL с секретом или исходный объект настроек. |
Проверьте также примеры в документации и тестовых данных приложения: разработчики иногда убирают ключ из промпта, но оставляют его в сообщении ошибки или скопированной инструкции подключения.
Иногда приложению нужно обрабатывать секрет как пользовательские данные. Это отдельный специальный сценарий с явными правилами, а не оправдание хранить постоянные рабочие credentials в контексте любого помощника.
Безопасная архитектура LLM начинается с того, какие данные модель вообще может увидеть, а не только с фильтра её ответа. В платном курсе LLM Security PRO: Prompt Injection, утечки, tool-abuse можно продолжить изучение соответствующего инженерного направления. Перед покупкой сравните программу и открытые материалы со своей задачей.
Документация для проверки технических деталей: OWASP: управление секретами.
Следующий шаг: Безопасность LLM-приложений: практические проверки. По смежным вопросам: Checkpoint AI в pickle: почему нельзя загружать чужой файл состояния, Почему read-only SQL для LLM ещё может раскрывать данные.
