Какие доступы давать ИИ-агенту, если безопасностью никто не занимается

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

Вы подключили агента к CRM. Заработало. Теперь он просится в почту, и вы замечаете, что правила, по которому это решать, у вас нет.

Идёте искать – и каждый найденный материал написан не для вас.

В чём риск, если сказать без жаргона?

Агент оказывается с теми правами, которые шли в комплекте, а не с теми, которые нужны для задачи. Дальше достаточно одной неверно понятой просьбы.

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

Двух примеров оттуда хватает, чтобы понять всю механику.

В первом разработчику нужно, чтобы агент читал документы из хранилища. Готовое расширение, которое он для этого выбрал, заодно умеет их менять и удалять. Право на удаление никто не выдавал сознательно. Оно приехало вместе с чтением.

Во втором примере расширение попробовали на этапе разработки, отказались от него в пользу лучшего и забыли отключить. У агента оно осталось.

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

Поэтому риск считается по числу подключений, и качество модели на него почти не влияет. Хорошая модель, подключённая ко всему, опаснее плохой модели, подключённой к одной системе.

Почему готовые советы вам не подходят?

Потому что написаны для тех, у кого есть кому их выполнять. Это не делает их неверными. Это делает их неисполнимыми в вашем масштабе.

Откройте выдачу по этому вопросу: авторы – поставщики средств управления доступом и сетевой безопасности, а пишут они для корпоративных команд. Словарь выдаёт адресата сразу: микросегментация, атрибутный контроль доступа поверх ролевого, эфемерные учётные данные, выдаваемые на время задачи, непрерывный мониторинг поведения, агенты как самостоятельные субъекты доступа с проверяемыми полномочиями.

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

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

Всё остальное в тех статьях – леса вокруг этих двух мыслей, нужные тем, кто проводит их через тысячи учётных записей. Вам надо провести их через шесть систем.

Три вопроса к каждому подключению

Спросите, что оно читает, что меняет и что делает необратимо. Третий вопрос важнее первых двух вместе взятых.

Разложите каждое подключение по этим трём столбцам до того, как одобрить, и решение станет очевидным само.

Чтение – дешёвая часть. Агент, который умеет читать календарь и больше ничего, способен потратить ваше время и не способен потратить ваши деньги. Основная полезная работа живёт именно здесь, и знать это стоит до того, как выдавать более широкие права.

Изменение – там, где начинается осторожность, и оно делится по обратимости. Агент, который правит поле в CRM, делает то, что вы откатите за минуту. Агент, который отправляет сообщение клиенту, делает то, что вы не откатите.

Необратимое стоит выписать отдельно, и список этот короткий: деньги, уходящие из компании; всё, что отправлено человеку за её пределами; удаление; изменение того, у кого какой доступ.

Меру защиты стоит взять у OWASP дословно, и покупать для неё ничего не надо: отказаться от расширений без границ. Расширение, которое выполняет любую команду оболочки или скачивает файл по произвольному адресу, умеет ровно всё. Узкая функция, которая пишет один тип файла в одно место, умеет только это. Когда поставщик предлагает вам универсальный инструмент и специальный, берите специальный, даже если его дольше подключать.

Правый столбец – то, что требует участия человека. А строка, где в середине нет ничего безопасного, показывает, что агент должен там только читать.

Что остаётся за человеком?

Всё из последнего столбца. Причём подтверждение – это шаг в процессе, а не настройка модели.

Разница здесь важнее, чем кажется. Если вы велите модели спрашивать перед необратимым действием, безопасность становится свойством инструкции, а инструкция – это совет. Если подтверждение встроено в само подключение, безопасность становится свойством системы, а у системы не бывает плохого дня.

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

Одна оговорка. Статья описывает практику, а не соответствие требованиям. Если вы работаете с регулируемыми данными, вопросы выше – отправная точка, а ваши обязанности обсуждаются отдельно и с тем, кто имеет право это обсуждать.

Как проверить то, что уже подключено?

Составить список подключений и выяснить, что каждое реально умеет. С тем, что вы думали, когда его одобряли, это совпадает редко.

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

1. Выпишите все интеграции, до которых агент дотягивается. Не те, которыми вы пользуетесь, а те, которые он может вызвать. Это разные списки, и разница между ними обычно и есть находка.
2. Откройте каждую и прочитайте выданный объём прав. Ищите тот самый случай из примера OWASP: полный доступ там, где хватило бы чтения, выданный потому, что полный был вариантом по умолчанию в диалоге.
3. Отключите то, чем не пользуетесь. Брошенное, но подключённое расширение – второй пример из того же документа.
4. Убедитесь, что действия куда-то записываются. Если действие произошло, а восстановить потом никто ничего не может, разбор превращается в спор. Малые компании пропускают эту часть в первую очередь, а нужна она раньше остальных: без неё ответ на вопрос «что случилось» – догадка.

Вот и весь метод. Он невзрачный, не требует платформы и отвечает тем двум мыслям из корпоративной литературы, которые стоило забрать.