Когда в корпоративный контур заходят не два-три бота, а 200 автономных помощников, старая схема удалённого доступа начинает сбоить. История про ИИ-агенты и VPN важна не только для служб ИБ: она напрямую касается разработчиков, платформенных команд и руководителей, которые уже выдают агентам доступ к коду, внутренним API и данным.
Об этом пишет The New Stack: главная проблема в том, что классический VPN изначально проектировали под людей, а не под плотный парк машинных исполнителей. Для сотрудников такой подход и без того неидеален, потому что часто открывает доступ шире, чем нужно. Для ИИ-агентов этот перекос становится ещё заметнее: вместо точечного допуска компания получает раздачу избыточных прав множеству автоматизированных сущностей, которые работают быстро, массово и без привычного человеческого контекста.
Сама коллизия довольно простая. VPN исторически решал сетевую задачу: подключить пользователя к внутреннему периметру и считать, что дальше он разберётся по корпоративным правилам. Но агентный софт ведёт себя не как человек с ноутбуком. Один агент может читать документацию, другой запускать проверки, третий ходить в систему тикетов, четвёртый обращаться к внутренним сервисам разработки. Если все они получают доступ по старой модели, компания не просто подключает их к сети, а фактически впускает в сегменты, которые им не нужны для конкретной операции. На бумаге это выглядит как удобство. На практике это лишняя поверхность атаки, сложный аудит и тяжёлая ручная настройка.
Проблема становится острее из-за масштаба. Десяток сотрудников можно терпимо обслуживать через традиционные схемы, даже если они не слишком изящны. Сотни агентов ломают экономику процесса. Их надо создавать, отзывать, ротировать, ограничивать по ролям и наблюдать за тем, куда именно они ходят. Если человеку можно задать вопрос в чате или позвонить, чтобы уточнить, зачем ему тот или иной доступ, то агент ничего не объяснит. Он просто выполнит цепочку действий, которую ему разрешили. Именно поэтому сюжет про ИИ-агенты и VPN быстро выходит за рамки сетевой темы и превращается в вопрос управления идентичностями, политиками и минимально необходимыми правами.
На этом фоне старая ставка на периметр выглядит всё менее убедительно. В корпоративной инфраструктуре и без агентов давно накапливался дрейф в сторону более точных моделей доступа: не «подключился к сети, значит, почти дома», а «получил ровно тот ресурс, который нужен, на то время, которое нужно, и под ту задачу, которая разрешена». Появление агентных систем только ускоряет этот сдвиг. Потому что машинам проще и логичнее выдавать доступ не к подсети или VPN-туннелю, а к конкретному приложению, API, репозиторию, базе знаний или внутреннему сервису. Там, где раньше терпели широкие сетевые ворота ради удобства людей, для агентов такой компромисс уже слишком дорог.
Для русскоязычных команд это особенно практичный сигнал. Во многих компаниях агенты сначала появляются не как большая стратегическая платформа, а как набор локальных экспериментов: помощник для разработки, сервис для анализа инцидентов, автоматизация саппорта, внутренний copilоt для документации. Каждый такой инструмент просит доступ «всего лишь» к паре систем. Через несколько месяцев оказывается, что этих инструментов десятки, а доступы выдавались в спешке, без единой модели. В этот момент безопасники видят не инновацию, а хаотичный зоопарк сервисных учёток, токенов и туннелей. Разработчики, в свою очередь, сталкиваются с другой крайностью: если ИБ начинает резать всё подряд, агенты теряют полезность, потому что не могут дотянуться до нужного контекста.
Отсюда и вывод, который читается между строк материала: спорить надо не о том, нужны ли агентам доступы, а о том, как их выдавать без раздачи лишнего. Рабочий подход здесь ближе к унифицированному доступу, чем к классическому VPN. То есть к модели, где каждая машинная сущность получает собственную идентичность, чёткие политики, короткоживущие разрешения и журналирование действий на уровне приложения, а не только сетевого подключения. Для эксплуатации это означает меньше слепых зон. Для бизнеса — более внятный контроль над тем, что именно могут делать автоматизированные сотрудники. Для разработки — шанс не закапывать агентные сценарии в бесконечные ручные согласования.
Важный нюанс в том, что речь не о полном отказе от VPN как технологии. Во многих инфраструктурах он ещё долго останется частью картины: для людей, подрядчиков, отдельных сегментов и совместимости со старым стеком. Но когда компания реально идёт в сторону агентной автоматизации, VPN перестаёт быть главным ответом на вопрос доступа. Он может остаться транспортом, но уже плохо работает как базовая модель доверия. И чем больше агент умеет действовать сам, тем опаснее предполагать, что ему можно дать почти человеческий доступ «на всякий случай».
Для CIO, CISO и платформенных лидов здесь просматривается неприятный, но полезный вывод. Массовое внедрение ИИ-агентов — это не только вопрос производительности и качества автоматизации. Это ещё и проверка зрелости всей архитектуры доступа. Если агенту для полезной работы нужно полкорпоративной сети, проблема, скорее всего, не в агенте. Проблема в том, что старая инфраструктурная логика плохо переживает переход от десятков людей к сотням машинных исполнителей. И похоже, именно вокруг этой точки в ближайшее время и будет идти главный спор: кто в компании умеет управлять доступом точнее — старый VPN или новая модель, где каждый агент получает ровно столько, сколько ему действительно нужно.