От полезного ИИ к контролируемым действиям: зачем корпоративным агентам нужна реально действующая граница

Практическая проверка ИИ, который читает данные, вызывает сервисы и действует от имени компании: проверять разрешение в точке действия, а не только в инструкции.
Original editorial illustration

Introduction: Кто решает, что разрешено ИИ-агенту?

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

1. Инструкция не заменяет контроль доступа

Указание «не отправляй конфиденциальную информацию» полезно. Оно не убирает учётные данные с широкими правами и не отключает ненужную функцию экспорта. Рекомендации по предотвращению чрезмерных полномочий советуют ограничивать доступные функции, сокращать права в целевых системах и проверять разрешения в системах, исполняющих запросы. Задача чтения документов не должна получать право удаления только потому, что тот же коннектор его поддерживает. Начните с минимального полезного набора действий, затем проверяйте каждый запрос на соответствие заданным границам.

[4] [5]

2. Идентификация и разрешение отвечают на разные вопросы

Подтверждённая идентичность показывает, кто отправляет запрос. Сама по себе она не даёт права выполнить его. Архитектура нулевого доверия рассматривает аутентификацию и авторизацию как разные функции. Для корпоративного агента решение должно связывать инициатора запроса, идентичность программы, конкретный ресурс и предлагаемое действие. Общая учётная запись администратора затрудняет такое разделение. Лучше ограниченный доступ с сохранением контекста соответствующего пользователя, чем одинаковые широкие полномочия для каждого процесса.

[4] [6]

3. Размещайте проверку там, где происходит действие

Сервис политик может разрешить запрос к инструменту, запретить его или потребовать одобрения до достижения цели. Но расположение проверки важно. Шлюз защищает проходящий через него трафик; нельзя считать, что он контролирует и обходной маршрут. Изоляция хоста и сетевые средства контроля охватывают разные пути. Прежде чем заявлять о полноте защиты, составьте карту локальных файлов, дочерних процессов, сетевых сервисов и делегированных вызовов. Проверяйте запрещённое действие по каждому доступному пути, а не только в стандартной демонстрации.

[1] [5]

4. Журнал аудита является свидетельством, но не автоматическим доказательством

В недавних работах о движках политик описаны записи решений с необязательными подписями и цепочками хешей для обнаружения последующих изменений. Эти функции могут усилить расследование. Они не доказывают, что политика была правильной, что были охвачены все пути или что разрешённое действие было хорошим бизнес-решением. Записывайте идентичность, ресурс, запрошенное действие, решение и ссылку на одобрение. Не допускайте излишних чувствительных данных в журналах и проверяйте, сможет ли проверяющий восстановить реальный инцидент.

[1] [2]

5. Проведите небольшой, намеренно сложный пилот

Выберите один процесс с понятным ответственным и измеримым результатом. Предоставьте ему только необходимые записи и действия. Испытайте просроченное одобрение, постороннюю запись клиента, инструкцию внутри документа и просьбу использовать другую цель. Определите, что нужно отклонять и что должно ждать человека. Проверьте поведение при недоступности сервиса политик. Успешный пилот должен столь же ясно демонстрировать контролируемый отказ, как и успешное выполнение.

[1] [2] [5]

Conclusion: Сначала оцените полномочия, затем автономность

Открытые разработки на ранней стадии полезны как инженерный ориентир, но не гарантируют готовность к промышленной эксплуатации. Прежде чем расширять доступ, руководители должны запросить свидетельства реально действующих границ, проверок обходных путей и пригодных для расследования журналов. Цель не в том, чтобы замедлить каждое действие. Нужно сделать разрешённую работу надёжной, а запрещённую трудновыполнимой. Более качественное рассуждение помогает агенту выбрать действие. Реально ограниченные полномочия определяют, должна ли компания разрешить его.

References

  1. Policy enforcement research, 9 November 2026
  2. Policy engine implementation and release status
  3. Cloud-native project maturity record
  4. Zero Trust Architecture, SP 800-207
  5. Excessive agency: causes and prevention
  6. Workload identity and verifiable identity documents

Powered By K7