Незаметно набирается зоопарк
ИИ-агенты прочно прописались в разработке: они правят код, ходят в CI/CD, смотрят задачи, общаются с базами и облаками. Технически это работает через MCP-серверы — и каждому такому серверу нужен токен. Репозитории, докер-реестр, CMS, база данных, монитор задач, секрет-менеджер. Через полгода после «попробую агента» у вас дюжина ключей, аккуратно разложенных по конфигам в открытом виде.
Хуже того: эти конфиги дублируются. Один и тот же токен лежит в настройках CLI-агента и в настройках редактора, в проектном .mcp.json и в глобальном конфиге. Поменяли ключ — не забудьте сходить в четыре места. Засветили один файл — считайте, засветили всё.
Чем грозит открытый ключ в файле, объяснять не надо: бэкапы и синхронизация конфигов, случайный коммит, демонстрация экрана, любой процесс на машине с правами на чтение. Секрет, лежащий в открытом тексте, рано или поздно уезжает.
Секреты — в системное хранилище, запуск — через обёртку
Лечится системными средствами. На macOS есть Keychain, в Linux — gnome-keyring с secret-tool, в Windows — Credential Manager. Принцип один: ключ лежит в защищённом хранилище ОС, а MCP-сервер запускается не напрямую, а через крошечную shell-обёртку, которая достаёт ключ в момент запуска.
# положить ключ в хранилище (значение спросит интерактивно)
security add-generic-password -a "$USER" -s mcp-my-service-token -w
# обёртка ~/mcp/bin/mcp-my-service.sh
#!/bin/bash
set -euo pipefail
TOKEN="$(security find-generic-password -a "$USER" -s mcp-my-service-token -w)" || {
echo "нет mcp-my-service-token в кейчейне" >&2; exit 1
}
export MY_SERVICE_TOKEN="$TOKEN"
export MY_SERVICE_URL="https://example.com"
exec node "$HOME/mcp/my-service/dist/index.js"В конфиге агента при этом остаётся только путь к обёртке — ни одного секрета:
"my-service": {
"type": "stdio",
"command": "/Users/you/mcp/bin/mcp-my-service.sh",
"args": []
}Что это даёт: конфиги можно свободно бэкапить, синхронизировать между машинами и показывать хоть на конференции; ротация ключа — одна команда с флагом -U и перезапуск редактора; утёкший файл конфига больше не утечкой является.
Две оговорки из практики. Первая: выбирайте MCP-серверы, которые умеют читать секрет из переменной окружения — если сервер принимает ключ только аргументом командной строки, он будет светиться в списке процессов. Вторая: агент с доступом к терминалу теоретически может запросить ключ из хранилища сам — кейчейн защищает от уноса файлов, но не отменяет следующую главу. И да, первый запуск из нового приложения попросит доступ к пункту хранилища — это нормально, один раз нажмите «Всегда разрешить».
AGENTS.md — это просьба, а не граница
Вторая типичная иллюзия — файлы инструкций AGENTS.md / CLAUDE.md и system prompt в роли «системы безопасности». Пишем агенту «не читай файл с ключами», «не трогай прод» — и считаем дело закрытым.
Такой файл — просто текст в том же контексте, что и всё остальное, что видит модель. Он конкурирует за внимание с содержимым репозитория, задач, issue и страниц, которые агент открыл своим браузерным инструментом. В этих данных может оказаться prompt injection — и тогда чужая инструкция «случайно» перевесит вашу. Плюс модели ошибаются и галлюцинируют вовсе без злого умысла. Инструкция «не делай X» — это просьба: её обычно выполняют, но гарантий никто не давал.
Вывод простой: всё действительно важное должно быть защищено так, чтобы агент не мог навредить, даже если захочет, — правами на уровне системы, а не словами в промпте.
Ограничения — на уровне системы
Что это значит на практике:
- Минимальные привилегии токенов. Агенту — отдельный токен с узкой ролью, а не ваш личный админский. CI-токен — только на нужные репозитории, доступ к базе — только на нужную схему, в секрет-менеджере — политика на нужную папку. Тогда даже «достал и слил» не даст ничего серьёзного.
- Read-only по умолчанию. У многих MCP-серверов есть флаги записи и allowlist путей. Держите запись выключенной, разрешайте адресно и осознанно: «write actions» включаются под конкретную задачу и выключаются после.
- Точечное включение серверов. Не держите все MCP включёнными «на всякий случай» во всех проектах. Не нужен агенту доступ к прод-мониторингу в задаче по вёрстке — выключите его в этом проекте.
- Режимы самого агента. Полностью автономные режимы и обход подтверждений — только в изолированных окружениях. На рабочей машине — подтверждение опасных команд и ревью дифов перед применением.
- Уровень ОС. Секреты в системном хранилище (см. выше), для особенно чувствительных прогонов — отдельная учётка или контейнер, где физически нет доступа к лишнему.
- Дешёвая ротация. Если смена ключа — это час правок в пяти конфигах, её будут откладывать. Когда ключ один, лежит в хранилище и меняется одной командой, ротация из события превращается в рутину.
Чеклист
- Ни одного секрета в конфигах агентов и в репозиториях — только в системном хранилище секретов
- MCP-серверы запускаются через обёртки, секрет достаётся в момент запуска
- Для агентов — отдельные минимально-привилегированные токены, не личные
- Запись и опасные действия выключены по умолчанию, включаются адресно
- AGENTS.md описывает правила — но всё важное продублировано правами на уровне системы
- Ротация ключей дешевле чашки кофе — иначе она не будет происходить
Коротко
ИИ-агенты — отличный усилитель, но работают они с теми правами, которые вы им выдали — часто молча и впрок. Держите секреты в системном хранилище и выдавайте их через обёртки, ограничивайте серверы и токены минимально необходимым, а AGENTS.md считайте культурой работы, а не границей безопасности. Граница — это права доступа, которые не обойти «если очень захочется».