Перейти к содержанию

Skill over CLI и безопасность токенов

Проблема: скил поверх CLI

Когда у нужного сервиса нет MCP, в команде появляется соблазн обернуть его в CLI-утилиту и описать её использование прямо в скиле. Технически это работает: скилы у Claude исполняются в окружении с доступом к файловой системе и bash, поэтому агент может запускать скрипты и команды как обычный пользователь (Anthropic). Но, по нашему опыту, это скользкий подход, и упирается он в один вопрос: куда безопасно положить токен авторизации к сервису.

Правильного ответа здесь, по сути, нет. Токен можно положить в переменную окружения, но тогда агент может до него достучаться, утащить его или случайно затянуть в контекст. Это не паранойя: внешние источники подтверждают, что переменные окружения слабо защищены и утекают через логи и инспекцию процесса, а извлечение секретов через prompt-injection — реальный вектор атаки на агентов (OWASP MCP Top 10). Общая рекомендация по скилам — вообще не хранить учётные данные внутри скила и не передавать их агенту в открытом виде, а использовать стандартные механизмы вроде OAuth (Red Hat).

Почему MCP снимает проблему секретов

Наш вывод: если идти через MCP, проблемы с токеном как таковой не возникает. MCP-сервер — это, по сути, серверное приложение, которое хранит все секреты у себя и не отдаёт их модели; агент лишь вызывает тулы, не видя «сырого» токена. Это подтверждает и официальная документация: для локального (STDIO) MCP-сервера учётные данные берутся из переменных окружения или встроенных библиотек на стороне самого сервера, а не агента; для удалённого — через OAuth 2.1, где сервер валидирует bearer-токен, но не раскрывает секрет клиенту (Model Context Protocol). То есть аутентификацию вы проходите на уровне MCP-обвязки один раз, а скил поверх MCP просто пользуется тулами без дополнительной возни с секретами.

Если же сервис приватный и авторизуется под вами (например, через OAuth), ничего не мешает написать собственную MCP-обёртку — это «не rocket science».

Важная оговорка

MCP не делает безопасность автоматической. Внешние источники отдельно подчёркивают, что неправильное обращение с токенами и утечка секретов — это риск №1 именно для MCP: секреты стоит держать в защищённых хранилищах (Vault, Secrets Manager), выдавать короткоживущие токены и не писать их в логи (OWASP MCP Top 10). Но это уточняет, а не отменяет ключевой тезис: архитектурно MCP уводит секрет из контекста модели, тогда как skill-over-CLI оставляет его на виду у агента.

Источники