Когда ИИ‑агенту дают доступ к инструментам, он может не только помочь, но и «наломать дров» — из‑за неверного вызова, лишних прав или отсутствия контроля. Microsoft выпустила открытый стандарт ACS, чтобы политики безопасности и логирование действий агента перестали быть кустарными и разрозненными.
ИИ‑агенты быстро перестают быть «умным чатиком» и превращаются в исполнителей: они читают данные, вызывают инструменты, запускают цепочки действий и работают в разных средах. Чем шире доступ, тем важнее вопрос контроля — не на уровне общих инструкций, а на уровне правил, которые можно проверить и потом объяснить аудитору.
Microsoft представила открытый стандарт Agent Control Specification (ACS) — попытку описать единый способ управлять тем, что именно агенту разрешено и запрещено делать, когда нужно привлекать человека и какие следы действий обязаны оставаться в логах.
В чём проблема: агенты действуют, а контроль часто «на скотче»
На практике команды обычно защищаются комбинацией подходов: прописывают строгий system prompt, добавляют проверки в приложении, используют классификаторы для фильтрации входа/выхода. Это работает, но есть типичный побочный эффект — контроль распределён по коду и разным инструментам, его сложно переиспользовать между проектами и почти всегда тяжело нормально проверять.
ACS предлагает вынести правила в отдельный слой управления — так, чтобы политики были единообразными, переносимыми и проверяемыми.
Что такое ACS: политики, которые «перехватывают» поведение агента
Суть ACS — возможность описать политики, которые определяют:
- что агент может делать (например, какие инструменты вызывать и с какими параметрами);
- что делать нельзя (например, не отправлять данные определённого типа наружу);
- где нужен человек (утверждение действия перед выполнением);
- что логировать как доказательство корректного поведения (для расследований, соответствия требованиям и внутреннего контроля).
Политики проверяются в нескольких «точках перехвата» по ходу работы агента: до получения входных данных, перед вызовом инструмента, после получения результата инструмента и перед отправкой финального ответа пользователю. В зависимости от политики система может разрешить действие, заблокировать его, замаскировать чувствительную информацию или попросить подтверждение у человека.
Почему это важно разработчикам и безопасности
Главная ценность подхода — не в очередной «надстройке», а в попытке стандартизировать то, что многие уже вынуждены делать вручную. Если политики оформлены единообразно и живут отдельными файлами, их проще:
- использовать повторно в разных проектах и командах;
- обсуждать и утверждать совместно (разработка, безопасность, комплаенс);
- аудировать после инцидентов — по логам и правилам становится яснее, почему агент действовал именно так.
Практический сценарий: агент помогает сотрудникам работать с внутренними системами (CRM, тикеты, база знаний) и умеет выполнять действия через инструменты. В ACS можно закрепить, что агент:
- не создаёт новые учётные записи и не меняет права доступа;
- может формировать черновик ответа клиенту, но отправка требует подтверждения;
- при обнаружении чувствительных данных (например, персональных) обязан скрывать их в ответе и фиксировать событие в журнале.
Как это будет подключаться: SDK и плагины под популярные фреймворки
По данным Microsoft, ACS поставляется как SDK и заявлен с интеграциями (плагинами) для распространённых инструментов и фреймворков, включая LangChain, OpenAI Agents SDK, Anthropic Agents SDK, AutoGen, CrewAI, Semantic Kernel, Microsoft.Extensions.AI и MCP‑инструменты.
Если обещанная совместимость окажется удобной на практике, у команд появится шанс меньше тратить времени на «самодельные» предохранители и больше — на сценарии, где агент действительно помогает: ускоряет рутину, снижает число ошибок и упрощает контроль.
Источник: TechCrunch
