Для AI-агентов credentials особенно чувствительны, потому что агент вызывает tools: CRM, Google Drive, Slack, Telegram, 1С, платежи, почту или внутренние API. Если ключ попал в prompt, trace, лог или ответ пользователю, злоумышленник может получить доступ к данным или выполнить действия от имени компании.
Правильный подход: хранить credentials не в промпте и не в коде статьи, а в защищенном хранилище секретов, переменных окружения, настройках n8n/Make/Flowise или secret manager. Агент должен видеть только название tool и разрешенные параметры, но не сам токен.
У credentials должны быть минимальные права. Если агенту нужно читать статусы заказов, ему не нужен полный доступ к удалению сделок. Для production полезны отдельные ключи по средам, scopes, expiration, ротация, audit log, IP restrictions и быстрое отключение при инциденте.
Главная ошибка - использовать один общий ключ администратора для всех агентов и интеграций. Это удобно на демо, но опасно в реальной системе: невозможно понять, кто что сделал, сложно ограничить ущерб и трудно безопасно отозвать доступ.
Примеры
- OpenAI API key хранится в переменной окружения `OPENAI_API_KEY`, а приложение читает его на сервере, не отправляя в браузер.
- Telegram bot token нужен для управления ботом. Его нельзя вставлять в публичный код, screenshots, prompts или сообщения пользователю.
- Google OAuth refresh token позволяет агенту получать новый access token и работать с Drive без повторного входа пользователя.
- n8n хранит credentials отдельно от workflow, а AI Agent node получает только подключенный tool, не видя секрет напрямую.
- Slack bot token с scope `chat:write` может отправлять сообщения, но не должен иметь лишний доступ к файлам и приватным каналам.
- Service account для Google API лучше ограничить конкретным проектом, папкой или набором ресурсов, а не давать доступ ко всему домену.
Где используется
- подключение AI-агента к внешним API
- безопасное хранение ключей OpenAI, Telegram, Slack, Google и CRM
- настройка credentials в n8n, Make, Zapier и Flowise
- разделение read-only и write-доступов для tools
- OAuth-подключение пользователя к Google Drive, Gmail или календарю
- ротация ключей после инцидента или смены сотрудника
- ограничение scopes и прав доступа для агента
- audit log действий, выполненных через API
- защита от утечки токенов в prompts, logs и traces
- быстрое отключение опасной интеграции без остановки всего агента
Связанные термины
Частые вопросы
API credentials - это то же самое, что API key?
API key - один из видов credentials. В эту же группу входят access token, refresh token, client secret, service account, webhook secret и другие данные, которые дают доступ к API.
Можно ли вставлять API key в prompt агента?
Нет. Модель не должна видеть секреты. Ключ хранится на сервере, в secret manager или в credentials-хранилище платформы, а агент вызывает tool через безопасный backend-слой.
Что делать, если API key попал в лог или trace?
Сразу отозвать или перевыпустить ключ, проверить audit log, удалить секрет из логов там, где это возможно, найти источник утечки и добавить маскирование secrets в logs, traces и error messages.
Какие права давать credentials для AI-агента?
Минимально необходимые. Если агент только читает данные, используйте read-only scope. Для записи данных добавляйте allowlist действий, validation, human approval и отдельный ключ с ограниченными правами.
Где хранить API credentials в no-code инструментах?
Встроенные credentials-хранилища n8n, Make, Zapier или Flowise обычно безопаснее, чем вставка ключей в prompt, node text или публичные переменные. Для production также стоит смотреть на шифрование, доступы и аудит.
Как часто менять API credentials?
Зависит от риска. Хорошая практика - ротация при смене сотрудников, подозрении на утечку, изменении прав, переносе проекта и по регулярному графику для критичных интеграций.
