Agent Control: open-source control plane для AI-агентов

Иногда всё ломается не громко, а почти буднично. В одной крупной компании агент без участия человека снёс production-таблицу. Ночью. Guardrails это не поймали: проверка искала строку DROP TABLE в SQL-ответе, а агент пошёл в базу другим tool call. Дальше — PagerDuty в три утра, сонная SRE-команда, аварийная остановка, разбор полётов на выходных. Неприятная история. И, если честно, слишком знакомая.

Так сегодня у многих и устроено управление агентами: разрозненные проверки по коду, локальные правила на уровне отдельных команд, ручные костыли вместо системного контроля. Когда агент начинает вести себя странно, выбор обычно невелик — выключить, переписать, заново задеплоить. Не управление, а игра на авось.

Именно здесь появляется Agent Control — открытый control plane для AI-агентов, который выносит политики безопасности, runtime governance и контроль решений в отдельный, централизованный слой. Для компаний, которые строят AI-агентов и автоматизацию, это, по сути, переход от хаотичных guardrails к управляемой инфраструктуре.

Где на самом деле проблема

Беда не в том, что guardrails отсутствуют. Они есть. Но стоят не там, где нужно.

Шлюзы и API-прокси. Они умеют фильтровать вход и выход: отсечь токсичный запрос, скрыть PII в финальном ответе, зажать очевидно опасный контент. Полезно? Да. Достаточно? Нет. Такой слой не видит, какой инструмент выбрал агент, какие аргументы передал, что вернула база, почему он вообще принял именно это решение. А значит, полноценная безопасность AI-агентов на одном gateway не строится.

Guardrails внутри фреймворка. LangChain, CrewAI, OpenAI Agents SDK и другие платформы позволяют встраивать проверки глубже — уже ближе к логике агента. Но тут другая засада: политики оказываются намертво пришиты к коду. Нужно поменять правило? Значит, правим исходники, тестируем, выкатываем заново. Если агентов десятки, а команды разные, одно изменение политики превращается в длинную цепочку инженерных задач. Ну такое.

Нужен отдельный слой, который работает на уровне шагов и решений агента, но управляется централизованно. То есть не «каждый агент сам за себя», а единая плоскость контроля: политики, enforcement, обновления в реальном времени — без переписывания логики каждого сервиса. В терминах рынка это и есть agent control plane.

Что такое Agent Control

Galileo открыл Agent Control для сообщества как open-source-проект под лицензией Apache 2.0. По сути, это control plane для AI-агентов, который позволяет задавать, применять и обновлять политики поведения во время выполнения. Не после инцидента. В момент принятия решения.

Если смотреть практично, Agent Control закрывает три болезненные зоны: интеграцию, централизованное применение политик и совместимость с разными evaluators.

1. Один декоратор на границе принятия решения

Интеграция выглядит почти подозрительно просто:

@control()
async def query_database(sql: str) -> Results:
    return await db.execute(sql)

Вот и всё. Декоратор @control() превращает функцию в контролируемую точку принятия решения. Без отдельной API-обвязки, без ручной упаковки payload, без лишней возни. Поставили хук — получили control point.

И это важно: в отличие от gateway-подхода, здесь контроль можно разместить на каждом значимом шаге. Вызов базы, обращение к внешнему API, выбор инструмента, генерация промежуточного плана, работа с памятью — всё это можно покрыть отдельными политиками. Для команд, проектирующих архитектуру AI-агентов, такой уровень детализации — не роскошь, а необходимость.

2. Политики живут отдельно от кода

Когда декорированная функция запускается, Agent Control обращается к серверу политик — либо к локальному кэшу, если он настроен. Дальше система оценивает входные или выходные данные по активной политике и возвращает решение: allow, deny, warn, log или steer. Если правило говорит deny, SDK выбрасывает исключение до выполнения опасного действия.

Ключевая мысль тут простая, но мощная: разработчик определяет, где нужен контроль, а команда безопасности или compliance решает, что именно должно проверяться и как реагировать. Это уже не локальный guardrail в одном сервисе, а централизованное управление политиками для всего парка агентов.

На практике это означает, что можно обновить, например, правила обнаружения PII, ограничения на доступ к данным или требования к действиям агента — и изменения вступят в силу без нового деплоя. Следующий запрос уже пойдёт по новой политике. Для enterprise-среды и задач вроде AI compliance и соответствия требованиям это огромный шаг вперёд.

3. Разные evaluators, один control plane

Архитектура evaluators в Agent Control модульная. То есть компания не запирается на одном вендоре и не обязана строить весь стек вокруг одной платформы. В одной политике можно сочетать модели для токсичности, отдельные проверки на темы и ограничения, compliance-валидаторы, регулярные выражения для PII и собственную бизнес-логику.

Это особенно важно там, где агенты работают в сложной среде: с внутренними системами, документами, базами знаний, внешними API, пользовательскими данными. Один инструмент редко закрывает всё. А здесь можно собрать best-of-breed-стек и управлять им из единой панели. Не идеально волшебно, конечно, но уже очень по-взрослому.

Почему open source здесь действительно важен

Рынок централизованного контроля агентов быстро движется в сторону закрытых платформ. Многие решения привязаны к конкретному облаку, стеку или экосистеме. Для бизнеса это означает знакомый риск: vendor lock-in, ограниченная прозрачность и зависимость от чужой дорожной карты.

Agent Control идёт в другую сторону. Открытая лицензия Apache 2.0 даёт прозрачность, возможность аудита, расширяемость и право строить собственные интеграции без оглядки на одного поставщика. Для компаний, которые разворачивают агентные системы внутри периметра, это не идеологический бонус, а вполне прикладная вещь.

Особенно если речь идёт о сложных сценариях — например, когда нужны мультиагентные системы, распределённые политики, согласованные правила доступа и единый слой наблюдаемости. Тут закрытые коробки часто начинают скрипеть.

Что это даёт enterprise-командам

Agent Control полезен не только как инструмент безопасности. Он меняет сам подход к эксплуатации AI-агентов в production.

• Меньше ручной инженерии. Политики обновляются централизованно, а не через правки в десятках сервисов.

• Глубже контроль. Проверки работают не только на входе и выходе, но и внутри цепочки действий агента.

• Быстрее масштабирование. Один и тот же подход можно применять к разным агентам, командам и сценариям.

• Лучше управляемость. Безопасность, observability и governance перестают быть набором разрозненных решений.

Если у компании уже есть агентная память, retrieval-цепочки и RAG-пайплайны, такой контроль становится ещё важнее: агент может не просто отвечать, а извлекать, комбинировать и использовать чувствительные данные. В таких случаях связка политик, runtime enforcement и агентной памяти и RAG — это уже базовая гигиена, а не опция.

Galileo и экосистема вокруг Agent Control

Galileo позиционирует Agent Control как логичное продолжение своего стека для evaluation и observability. Идея понятная: сначала компании учатся измерять качество и надёжность агентов, затем — управлять их поведением централизованно. Сначала видимость, потом контроль. Хотя, если честно, в реальных проектах эти две вещи почти всегда приходится строить параллельно.

В запуске проекта участвуют заметные игроки рынка, включая Cisco AI Defense, CrewAI, Strands Agents SDK, Glean, Rubrik и ServiceNow. Общий мотив у всех один: enterprise-командам нужен не просто набор guardrails, а инфраструктурный слой, который позволяет безопасно выводить AI-агентов в production и масштабировать их без постоянного страха что-нибудь уронить.

Почему это важно для рынка AI-агентов

Сейчас индустрия уходит от демонстрационных агентов к рабочим системам, которые реально получают доступ к данным, запускают процессы, принимают решения и взаимодействуют с внутренними сервисами. А значит, вопрос уже не в том, «умеет ли агент сделать задачу». Вопрос другой: как сделать так, чтобы он не сделал лишнего.

Вот тут и нужен control plane. Не как модная надстройка, а как базовый слой эксплуатации. Примерно как IAM, observability или policy engine в обычной корпоративной инфраструктуре. Без этого агентный стек остаётся хрупким — красивым на демо, нервным в проде.

Итог

Agent Control — это open-source control plane для AI-агентов, который выносит политики безопасности и governance из кода в централизованный runtime-слой. Он даёт простой способ размечать точки контроля через @control(), применять политики без редеплоя и комбинировать разные evaluators в одной системе.

Для команд, которые строят production-grade агентные решения, это важный сдвиг: от разрозненных guardrails к управляемой инфраструктуре. Не серебряная пуля — таких, увы, не бывает, — но очень сильный фундамент для безопасного масштабирования AI-агентов в enterprise.