Возможности, разрешения и шлюзы одобрения в командах разработчиков ИИ

Многие ИИ-инструменты предлагают упрощенный путь.

Вы подключаете инструмент или интеграцию. Интерфейс сообщает, что агент теперь может работать с файлами, задачами или командами.

Для серьезных команд этого недостаточно.

Техническая возможность — это не то же самое, что разрешение. Действие может быть технически осуществимым, но все равно требовать решения человека.

NexFlow разделяет эти три уровня:

• Возможность (Capability): Что субъект может сделать технически? • Разрешение (Permission): Разрешено ли конкретному субъекту использовать эту возможность? • Шлюз одобрения (Approval Gate): Требуется ли предварительное согласие человека для выполнения действия?

Путаница в этих терминах ведет к рискам безопасности.

Навык (skill) описывает роль, например, написание документации. Возможность (capability) описывает действие, например, create_pull_request. Разрешение (permission) — это политика, например, allow или deny. Шлюз одобрения (approval gate) — это человек или система, которая должна одобрить ограниченное действие.

У агента может быть навык проверки кода. Интеграция может предоставлять возможность создания pull request. Но разрешение должно определить, может ли именно этот агент использовать данный инструмент. Затем шлюз одобрения решает, должен ли человек проверить это действие.

Это различие защищает ваш проект. Оно предотвращает проблему «подключенного инструмента», когда агент получает больше полномочий, чем вы планировали.

NexFlow использует консервативную модель безопасности:

  • Проверка наличия у субъекта заявленной возможности.
  • Поиск правил разрешений.
  • Явный запрет (deny) является самым приоритетным правилом.
  • Статус approval_required блокирует действие до тех пор, пока человек его не одобрит.
  • Разрешение (allow) действует только в рамках определенной области (scope).
  • Если разрешения не существует, действие отклоняется.

Это не бюрократия. Это делает риски видимыми. Вы можете проверить свои политики еще до запуска первого агента.

Вы можете видеть:

  • Какие рискованные возможности существуют.
  • Кто может читать ваш репозиторий.
  • Кто может записывать файлы.
  • В каких случаях человек должен остановить действие.

Того, что агент может делать, недостаточно. Важно то, что ваш проект позволяет ему делать.

Source: https://dev.to/alexander_iwizard/capabilities-permissions-and-approval-gates-in-ai-developer-teams-2cc4

Optional learning community: https://t.me/GyaanSetuAi