Каждый новый AI-агент в компании начинается с одного и того же шага: куда-то записать токен. В конфиг агента на ноутбуке разработчика, в переменную окружения, в репозиторий с «временным» секретом. Через месяц таких токенов десятки, через полгода никто не помнит, какие из них ходят в прод-данные и кто их выдавал. Отзыв скомпрометированного секрета превращается в обход всей команды.
Проблема не в том, что секреты есть, а в том, где они живут. Пока секрет хранится у агента, агент становится самой ценной целью. Централизованное хранение решает это иначе: секрет живёт в одном месте и применяется без попадания в контекст агента.
Почему секреты расползаются
Типовая схема сегодня — каждый разработчик сам добавляет MCP-серверы и интеграции в свой клиент. Каждый конфиг содержит свои токены, каждый ноутбук — свою копию секрета. При таком раскладе:
- секрет дублируется по количеству рабочих мест;
- ротация означает ручной обход всей команды;
- аудит сводится к опросу «кто чем пользовался»;
- компрометация одного устройства дает доступ ко всем системам, к которым у агента были ключи.
Даже без злонамеренности широкий scope и секрет в локальном конфиге делают агента самой привлекательной точкой для атаки. Чем больше агентов, тем дороже обходится отсутствие единой точки.
Что такое централизованное хранилище и dynamic secrets
Централизованное хранилище — это не «еще одна база с секретами», а точка, которая выдает доступ по запросу и умеет его отзывать. В терминах HashiCorp Vault это выглядит так:
- секрет хранится в одном месте с политиками доступа;
- агент получает не долгоживущий токен, а короткоживущий lease или dynamic credential, который истекает сам;
- каждый доступ логируется: кто, когда, к какому секрету.
Ключевое отличие от «скопировали токен в конфиг» — время жизни. Статический токен живет месяцами и переживает смену владельца ноутбука. Dynamic secret живет минуты или часы и требует продления. Украденный short-lived токен быстро становится бесполезным, а отзыв в хранилище мгновенно закрывает доступ всем агентам сразу.
Как агент вызывает без знания секрета
Самый надежный способ не отдать секрет агенту — не отдавать его вовсе. Схема через шлюз:
агент -> управляемый шлюз -> корпоративная система
(хранит секрет) (Jira, БД, API)Агент вызывает «Jira: прочитай задачу», не зная токена. Шлюз проверяет права пользователя, подставляет downstream-секрет при реальном обращении и возвращает агенту только результат. Секрет не попадает ни в конфиг, ни в контекст окна, ни в логи агента.
Это же решает проблему token passthrough, которую MCP-спецификация прямо называет антипаттерном: шлюз не принимает токен от агента и не прокидывает его дальше как есть, а применяет свой, выданный для конкретного сервиса с правильным audience. Агент не может случайно или намеренно использовать чужой токен.
Ротация и отзыв в одном месте
Централизация делает ротацию операцией, а не проектом:
- поменяли секрет в хранилище — все агенты сразу получают новый при следующем вызове, без обхода ноутбуков;
- отозвали lease — доступ закрылся везде мгновенно;
- ушёл сотрудник — отключили его доступ в одном месте, а не ищете токены по устройствам.
Динамические секреты усиливают это: даже если отзыв задержался, короткое время жизни ограничивает окно эксплуатации. Для статических секретов, которые нельзя сделать динамическими, хранилище хотя бы дает единую точку ротации и видимость, кто их использует.
Аудит доступа к секретам
Каждый доступ к секрету должен оставлять след: какой агент, под чьими правами, к какой системе, когда. Без этого невозможно ответить на базовый вопрос расследования «кто за это отвечает».
Хороший аудит для секретов фиксирует не только «секрет выдан», но и «секрет применен»: какой инструмент агента повлек обращение к downstream-системе с этим секретом. Так журнал секретов связывается с журналом вызовов инструментов — и инцидент раскладывается на цепочку, а не на догадки.
Где Codenik: Vault-слой без локальных секретов
Codenik построен как такая точка: управляемый слой между AI-агентами и корпоративными системами. Он хранит секреты downstream-систем на своей стороне, выдает агенту только разрешенные инструменты без знания токенов, привязывает каждый вызов к правам конкретного пользователя и пишет аудит.
Команда добавляет новую интеграцию один раз — через процедуру с владельцем и scope — а не в каждый конфиг отдельно. Подробнее про модель без локальных секретов — в статье «MCP без локальных секретов».
Короткий вывод
Секреты для агентов должны жить отдельно от агентов. Централизованное хранилище с короткоживущими credentials, шлюзом, который применяет секрет без попадания в контекст, и аудитом каждого доступа превращает ротацию и отзыв из ручного обхода в операцию в одном месте.
Чем раньше секреты переедут из конфигов на ноутбуках в управляемую точку, тем дешевле будет каждый следующий агент — и тем меньше у него будет того, что можно украсть.