Следите за новостями по этой теме!
Подписаться на «Гик Гайд (3 апельсина) / Цифра сегодня»
Цифровое доверие десятилетиями строилось на простой предпосылке: за каждым входом в систему или решением стоит человек. Пароли и многофакторная аутентификация подтверждали, что тот, кто запрашивает доступ, действительно обладает нужными учетными данными. Но искусственный интеллект меняет сам вопрос. Теперь недостаточно выяснить, может ли объект войти и кто он такой. Нужно понимать, кто разрешил ему действовать, что именно ему позволено делать и как долго это разрешение сохраняется.
Здесь важно разделить три проверки. Аутентификация отвечает на вопрос, есть ли доступ. Идентификация устанавливает, кто перед нами. Авторизация определяет, кто разрешил действие, какие операции допустимы, при каких ограничениях и в течение какого времени. Большинство существующей инфраструктуры хорошо справляется с первыми двумя задачами. ИИ-агенты заставляют всерьез заняться третьей.
ИИ-агенты уже выполняют платежи, оформляют операции и решают административные задачи, которые раньше требовали участия сотрудника. При этом многие системы безопасности не умеют надежно отличать человека от программного агента, а легитимного агента — от самовольно действующего. Они проверяют наличие правильных учетных данных, но не выясняют, имел ли их обладатель право совершать конкретную операцию.
Великобритания последние годы развивает инфраструктуру цифровой идентичности. Закон Data (Use and Access) Act закрепил правовой статус сервисов цифровой верификации личности — Digital Verification Services, или DVS. В отдельных сценариях вводится обязательная проверка личности директоров и лиц, имеющих существенный контроль над компаниями. Это полезный шаг, но он отвечает главным образом на вопрос «кто этот человек», а не на вопрос «кто сейчас действует и на каком основании».
В обычном бизнесе проверка личности всегда дополняется проверкой полномочий. Например, сотрудник может быть официально установлен как конкретный человек, но организация все равно должна знать, вправе ли он именно сейчас одобрять платеж. В финансовом секторе и здравоохранении такие проверки давно накладываются на идентификацию: одна личность сама по себе не говорит, что разрешено ее владельцу.
С ИИ-агентами это различие становится необходимым повсюду. Установить, какой агент отправил запрос, недостаточно: это не доказывает, кто поручил ему действие и укладывается ли оно в изначально выданное разрешение. Если бизнес просто копирует агенту доступ человека, один взломанный или неправильно настроенный процесс сможет причинить намного больший ущерб, чем агент с узкими полномочиями.
Поэтому разрешения нужно выдавать по принципу минимальной необходимости. Агенту следует предоставлять конкретный, ограниченный мандат на определенную задачу, а не постоянный доступ ко всему, что доступно сотруднику. Компания должна заранее проверить полномочия, зафиксировать, кто их выдал, установить ограничения, срок действия и возможность отзыва.
Для каждого действия агента бизнес должен уметь ответить на пять вопросов: кто или что действует; кто это разрешил; что именно разрешено; какие ограничения установлены; действительно ли полномочие сейчас. Такой подход близок к моделям делегирования «от имени другого» — on-behalf-of, или OBO, — уже применяемым в стандартах цифровой идентичности. Поэтому необязательно изобретать систему с нуля.
Без этих ответов неправильно настроенный агент может незаметно одобрить платеж, к которому его вообще не должны были допускать. Ожидание, пока регулятор первым напишет идеальный стандарт, лишь продлевает период уязвимости.
Правительству Великобритании также разумнее расширять уже созданную инфраструктуру, а не начинать строительство с чистого листа. DVS Trust Framework уже признает делегированные полномочия, когда человек действует от имени другого человека или организации. Теперь нужно определить, как тот же принцип будет работать, если делегатом выступает программа.
Практический результат должен быть понятен машине: агент предъявляет проверяемый мандат, в котором указано, кто его выдал, что разрешено делать, при каких условиях, на какой срок и действует ли разрешение сейчас. Одним из возможных мест хранения такого мандата могут стать цифровые кошельки — рядом с подтвержденными данными человека или организации, чтобы полномочие можно было проверить и отозвать.
Это не единственный вариант, но он показывает, какая инфраструктура нужна. У Великобритании остается ограниченное время, чтобы успеть выстроить правила до того, как внедрение ИИ-агентов обгонит системы, призванные их контролировать.
В перспективе цифровое доверие будет зависеть не от того, смогло ли нечто пройти экран входа. Главным станет доказательство того, кто или что реально действует, от чьего имени и как долго имеет на это право.
У бизнеса появился новый персонаж — программа, которая действует от чьего-то имени, но сама не краснеет, когда нажимает кнопку. Старые пропуска и пароли по-прежнему открывают двери, а вопрос, кто выдал агенту право войти дальше, внезапно стал неудобным. Технологии ускорили исполнение поручений; ответственность пока движется пешком.
У этой тревоги есть вполне разумная сторона: полномочия должны быть ограничены, понятны и отзывны. Но вокруг всякой новой угрозы быстро вырастает рынок тех, кто продаёт словарь, архитектуру и консультацию для её приручения. Когда материал настойчиво напоминает, что существующие системы не готовы, полезно спросить, кто именно готов предложить следующий слой контроля и выставить за него счёт.
Требование объяснить, кто разрешил действие и на какой срок, звучит как здравый минимум. Оно же создаёт прекрасный набор полей для новой формы, стандарта или цифрового кошелька. Сначала агенту дают доступ, потом рынок обнаруживает, что для безопасного доступа нужен отдельный рынок.
Особенно удобно, что виновником потенциального ущерба назначают плохо настроенную программу: она не участвует в совещаниях, не читает договоров и не возражает против роли крайней. Человек же, который выдал ей слишком широкие полномочия, получает шанс остаться за кадром — вместе с компанией, торопившейся автоматизировать процесс. Разговор о мандате важен, но он не должен превращаться в способ снять ответственность с тех, кто этот мандат написал.
Совет не ждать идеального регуляторного стандарта звучит энергично, почти как призыв немедленно открыть внутренний проект с бюджетом. В этом есть логика: защита, собранная после инцидента, обычно похожа на замок, установленный вокруг уже вынесенной мебели. Но поспешная система доверия тоже не магия — особенно если её проверяют те же люди, которым удобнее всего расширить доступ ради скорости.
Цифровое доверие хотят сделать машинно проверяемым, а значит, добавить ещё один слой удостоверений между намерением и действием. Это может помочь, если компания вправду ограничивает полномочия, фиксирует ответственных и отзывает разрешения. Если же агенту просто выпишут аккуратную доверенность на всё подряд, получится бюрократия с идеальной записью о том, кто именно разрешил катастрофу.
Редакция приветствует сам вопрос о границах полномочий — он полезнее очередного заклинания про «искусственный интеллект». Но главный тест здесь не в том, умеет ли система предъявить мандат, а в том, готов ли кто-то сказать агенту «нет» ради безопасности, даже если это замедлит квартальный план. Именно на этом месте обычно заканчиваются красивые схемы и начинается корпоративная жизнь.