Представьте себе кодинг-агента, выполняющего рутинную задачу.
В процессе он открывает файл, к которому у него не было причин обращаться, обнаруживает API-токен, предоставляющий ему больше прав, чем нужно, и решает использовать его для выполнения своей задачи.
Девять секунд спустя производственная база данных компании исчезает, включая резервные копии. Это звучит как фантастика, но это произошло на самом деле.
Подобные истории ужасов быстро распространяются в технологической среде. Публично все сохраняют оптимизм в отношении ИИ, но внутри компании начинает зарождаться здоровый скептицизм.
Большинство агентов не создаются намеренно для причинения вреда; они просто имеют больше возможностей, чем предполагалось, и не было механизма, сдерживающего такую недетерминированную активность. Производственная база данных стала непреднамеренным, масштабным сопутствующим ущербом в стремлении к эффективности ИИ.
Неудивительно, что это заставляет советы по комплаенсу и безопасности брать паузу каждый раз, когда новый агент попадает на их рассмотрение, а ценность, полученная от ИИ, на неопределенный срок остается в «чистилище» производственных проверок.
Согласно исследованию Salesforce и Atlantic Insights, 62% руководителей, использующих агентов в производстве, говорят, что хотят от этих агентов большего, чем могут безопасно позволить. А 77% сталкивались с тем, что внедрение приостанавливалось или перерабатывалось в прошлом году из-за того, что в последний момент возникал вопрос доверия.
Спрос есть; не хватает быстрого и уверенного способа одобрить их использование в производстве.
Каждое одобрение сводится к четырем вопросам
Тот, кто подписывает разрешение на использование агента, будь то архитектор безопасности, руководитель отдела комплаенса или финансовый директор, в конечном итоге задает одну из вариаций четырех вопросов.
К чему может получить доступ этот агент? От чьего имени он действует? Можем ли мы остановить его, если что-то пойдет не так? Сколько это будет стоить?
Когда команда может ответить на все четыре вопроса, подкрепив их доказательствами, одобрение проходит гораздо проще. Когда ответы основываются на заверениях, именно тогда внедрение производственных агентов буксует.
Эти ответы трудно получить, потому что агенты не живут в одном месте. Бизнес-подразделения создают их на разных платформах, часто используя постоянные учетные данные, подключенные к теневым активам. Большинство инструментов видят лишь часть этой картины; платформы агентов управляют своими собственными агентами, в то время как облачные провайдеры управляют трафиком на своих шлюзах.
Самые большие пробелы находятся между этими инструментами, и именно там обычно действуют агенты.
Скажите «да» везде, где действуют агенты
Устранение этих пробелов означает обеспечение доверия в точке действия агентов. Это охватывает как уровень агентов, где они создаются и работают, так и уровень подключения, где они получают доступ к вашим API, инструментам и моделям. Это также должно работать независимо от любого конкретного облака, поставщика идентификационных данных или шлюза, используя уже имеющиеся у вас идентификаторы и шлюзы, без необходимости замены чего-либо.
С такой основой задача разделяется.
Вам нужно понимать, к чему агент может получить доступ, от чьего имени он действует и можете ли вы его остановить — это вопросы доверия к агентам (Agent Trust).
- Управление доверием к агентам (Agent Trust Governance), которое находит агентов на каждой платформе, применяет единый набор правил ко всем шлюзам и оставляет аудиторский след, ускоряющий следующее одобрение. Безопасность, которая связывает каждое действие с реальным пользователем, ограничивает агентов одобренными инструментами и останавливает скомпрометированного агента, не останавливая работу остальных.
- Управление, которое находит агентов на каждой платформе, применяет единый набор правил ко всем шлюзам и оставляет аудиторский след, ускоряющий следующее одобрение.
- Безопасность, которая связывает каждое действие с реальным пользователем, ограничивает агентов одобренными инструментами и останавливает скомпрометированного агента, не останавливая работу остальных.
Вам также нужно понимать, во сколько это обойдется, и это вопрос Agent FinOps.
- Agent FinOps: бюджеты, которые ограничивают расходы на агента, команду или приложение, прежде чем они выйдут из-под контроля, и показывают стоимость каждого агента в рамках MCP и трафика между агентами. Оптимизация, которая сокращает бесполезные токены при каждом вызове модели и MCP, направляя запросы к моделям нужного размера и кэшируя повторяющиеся ответы без изменения кода агента.
- Бюджеты, которые ограничивают расходы на агента, команду или приложение, прежде чем они выйдут из-под контроля, и показывают стоимость каждого агента в рамках MCP и трафика между агентами.
- Оптимизация, которая сокращает бесполезные токены при каждом вызове модели и MCP, направляя запросы к моделям нужного размера и кэшируя повторяющиеся ответы без изменения кода агента.
И то, и другое должно соблюдаться там, где происходит большинство действий агентов: в вызовах MCP, которые делают агенты, и LLM, на которые они полагаются.
MCP и LLM — это то, где агенты встречаются с вашим бизнесом
Все больше и больше такой активности проходит через Model Context Protocol (MCP) — стандарт, который агенты используют для подключения к системам, которые вы уже используете, от SAP и Salesforce до пользовательских приложений, созданных вашими командами много лет назад. Две проблемы, как правило, проявляются на раннем этапе. Агенты легко получают доступ к SaaS-приложениям, но пользовательские API, на которых работает бизнес, часто остаются в стороне. Кроме того, команды уже подключают инструменты ИИ к серверам MCP, которые никто не проверял. Лучшее время для того, чтобы наладить работу с MCP, — это до того, как количество таких серверов достигнет сотен.
Правильный подход начинается с того, что уже работает. Существующие API превращаются в серверы MCP одним кликом вместо переписывания, сканеры находят серверы MCP, которые команды уже развернули, а идентификационные данные пользователя передаются при каждом вызове инструмента. Сокращение избыточных описаний инструментов и фильтрация многословных ответов на шлюзе означают, что агенты тратят меньше токенов и возвращают более качественные ответы.
Модели следуют той же логике. Команды хотят использовать лучшую модель для каждой задачи, и эта модель постоянно меняется. Один управляемый эндпоинт для более чем 140 моделей позволяет разработчикам свободно переключаться между ними, в то время как каждая новая модель наследует аутентификацию, лимиты скорости и аудиторский след, которые вы уже внедрили, поэтому службе безопасности не нужно начинать новую проверку каждый раз, когда выходит новая модель.
Время начинать — сейчас
Именно для этого создан Agent Fabric: управление, безопасность и Agent FinOps в одном решении, обеспечиваемом через Omni Gateway для агентов, серверов MCP, моделей и API, где бы они ни были созданы.
Вам не нужна масштабная программа, чтобы начать, но время действовать — прямо сейчас.
Сотрудники уже экспериментируют с агентами быстрее, чем любой процесс проверки может за ними угнаться, а регуляторы спрашивают, как вы остановите систему ИИ, если возникнет необходимость. Начните с агентов и инструментов MCP, которые у вас есть сегодня. Внедрите управление, безопасность и финансовые операции, и каждого последующего агента будет легче одобрить. Именно так советы по проверке начинают говорить «да» большему количеству агентов.
Если вы хотите еще больше облегчить жизнь совету по проверке, обязательно поделитесь с ними пакетом безопасности и комплаенса Agent Fabric. Это технический документ для ваших команд по безопасности и комплаенсу, который покажет им, как Agent Fabric может помочь удовлетворить их требования, начиная разговор с доказательств, а не с заверений.
Для получения более практических рекомендаций по внедрению агентов в производство подпишитесь на Technically Speaking, нашу ежемесячную рассылку в LinkedIn.
