Более пятой части локальных AI-агентов в компаниях уже имеют прямой доступ к production-источникам данных. Для команд, которые всерьез обсуждают безопасность AI-агентов, это неприятный, но полезный сигнал: старые процессы ИБ, рассчитанные на людей, серверы и сервисные аккаунты, больше не успевают за софтом, который сам берет токены, ходит по API и исчезает до следующего инвентаризационного скана.
Именно об этом пишет BleepingComputer, пересказывая позицию Token Security: агентные системы ломают базовое допущение, на котором корпоративная безопасность держалась последние два десятилетия. Раньше среда менялась с человеческой скоростью. У ИБ-команд было время купить инструмент, собрать инвентарь, описать политики и жить на преднастроенных дашбордах от вендора. С AI-агентами такая схема начинает скрипеть уже на уровне модели управления доступом.
Проблема в том, что AI-агенты не похожи на обычные приложения. Они могут работать автономно, вызывать внешние инструменты, наследовать доступ сотрудника, переключаться между системами и менять поведение в зависимости от контекста. Часть таких агентов санкционирована и живет внутри SaaS-платформ, часть запускается локально и вообще проходит мимо формальных процедур. В результате в логах и аудитах появляется сущность, которая действует как человек, но человеком не является. Для безопасности AI-агентов это худший сценарий: у вас не просто растет число учеток, у вас размывается понимание, кто именно и на каком основании сейчас ходит в прод, CRM, CI/CD или хранилище секретов.
Отсюда и главный тезис Token Security: универсальные security-workflow, которые вендор однажды собрал и отдал всем клиентам, больше не закрывают реальную картину. Да, дашборд может показать привычные вещи вроде избыточных прав, неактивных администраторов, старых учетных данных или доступа к production-системам. Но вопросы, которые важны именно для эпохи агентов, почти всегда локальные и завязаны на внутреннюю архитектуру компании. Например: какие агенты, созданные за последние две недели, могут попасть в прод через унаследованные человеческие креды; какие локальные coding-агенты сохранили рабочие токены после завершения проекта; по какому маршруту агент может стать частью цепочки атаки между двумя системами. Это уже не про «включить правильную вкладку в консоли». Это про знание своего ландшафта доступа в реальном времени.
На этом фоне меняется и старый спор build vs buy. Раньше вопрос звучал просто: покупать готовый инструмент или делать свой. Теперь, если верить аргументации Token Security, формулировка уже неверная. Собрать собственное приложение действительно стало проще: в материале приводится отчет Retool Build vs. Buy за 2026 год, где 35% команд сообщили, что уже заменили хотя бы один SaaS-продукт самописным решением, а 78% собираются строить больше внутренних инструментов в этом году. Для разработки это почти банальность: то, что раньше занимало недели, теперь можно накидать за часы. Но в ИБ главная боль не интерфейс и не кодогенерация, а подложка данных. Если у команды нет живых и нормализованных данных об идентичностях, правах, владельцах, активности и связях между системами, то любой самописный workflow быстро превращается в красивую автоматизацию поверх неполного экспорта из CSV.
Именно поэтому Token Security предлагает сместить фокус: покупать не весь «комбайн», а фундамент. В этот фундамент компания включает непрерывное обнаружение агентов, интеграции с облаками и SaaS, нормализацию схем, корреляцию идентичностей, карту доступов, governance-контроли, аудитируемость и безопасные границы исполнения. А вот операционный слой, наоборот, должна собирать сама ИБ-команда: отчеты, проверки, ревью, автоматизации и remediation-сценарии под свой стек, процессы и аппетит к риску. Для разработчиков и платформенных команд мысль знакомая: инфраструктуру можно взять как сервис, а бизнес-логику оставлять у себя. В безопасности AI-агентов этот подход выглядит особенно рационально, потому что разница между компаниями теперь определяется не списком купленных коробок, а тем, насколько точно они описали жизненный цикл агента: кто владелец, какой доступ допустим, какие исключения разрешены и что делать, если агент заброшен, скомпрометирован или внезапно стал умнее, чем предполагалось в тикете.
Ключевой опорой в этой модели авторы называют идентичность. Не guardrails, не фильтрацию промптов и не поведенческие ограничения, а именно identity-слой. Логика простая: любой полезный агент рано или поздно должен аутентифицироваться, получить токен, вызвать инструмент и дотянуться до данных. Даже если у него нет собственной учетки, он часто занимает чужую, обычно человеческую. А значит, настоящий радиус поражения определяется не тем, что агент говорит, а тем, куда он реально может зайти. Для российского рынка, где компании массово комбинируют облака, on-prem, Git-сервисы, корпоративные мессенджеры, самописные внутренние панели и все более активные AI-помощники, вывод неприятный, но практичный: без карты идентичностей и доступа в реальном времени безопасность AI-агентов будет держаться на ручных договоренностях, устаревших инвентарях и скриптах, которые ломаются быстрее, чем закрывается квартальный аудит.
Главный вопрос теперь не в том, появятся ли у компаний новые security-инструменты для агентных систем, а в том, кто будет владеть правилом игры: вендор с очередным фиксированным workflow или сама команда, которая понимает свой стек и умеет быстро менять операционный слой. Похоже, эпоха «поставили коробку и успокоились» для AI-агентов заканчивается раньше, чем многие успели согласовать бюджет.