Доступы ИИ-агента: почему у нашего сотрудника нет ваших паролей

25 августа Vercel вывела из беты продукт с говорящим названием — Connect. Суть в одной фразе из их анонса: приложение больше не хранит учётные данные, оно просит доступ в момент, когда он нужен, и этот доступ истекает сам.

Формулировка, ради которой стоит прочитать их пост целиком:

Индустрия наконец назвала проблему, с которой мы живём полтора года. Только у российского бизнеса она стоит в заметно более жёсткой форме — и решение, к которому пришли мы, отличается от их решения ровно настолько, насколько отличается задача.

Разберём обе.

Что такое credential sprawl

Дословно — «расползание учётных данных». Состояние, до которого доходит любая компания старше пары лет.

Пароль от кабинета Ozon знают трое: тот, кто заводил, тот, кто ушёл в прошлом году, и подрядчик по карточкам. Ключ от API Wildberries лежит в скрипте на ноутбуке маркетолога. Логин в банк-клиент бухгалтер передал «на время отпуска» — отпуск кончился в марте. Доступ к 1С у внешнего программиста, потому что иначе он не починит обмен. Токен Telegram-бота — в переписке, где его прислали, чтобы «быстро вставить».

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

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

Потому что стандартный способ подключить агента к кабинету — выдать ему тот же самый бессрочный ключ. Только теперь он лежит ещё и в переменных окружения сервиса, к которому у вас нет доступа.

Почему в России эта задача жёстче

Западная модель предполагает мир, в котором каждый сервис умеет OAuth, понимает scope и смотрит в интернет. В таком мире можно выдавать короткоживущий токен на конкретную задачу: этот — только на чтение одного репозитория, тот — только на публикацию в один канал.

Половина российских кабинетов так не умеет.

Где-то авторизация — подпись тела запроса секретом, который у вас один на всё. Где-то — логин с живущей сессией, которую надо переполучать. Где-то обмен файлами по расписанию. Где-то прямое подключение к базе. Где-то 1С стоит на сервере в офисе и наружу вообще не смотрит — и правильно делает.

Понятия «выдать доступ только на эту операцию» в таких кабинетах не существует. Ключ там — всегда ключ от всего.

Значит, задачу нельзя решить сужением ключа. Её надо решать в другом месте.

Наш ход: агенту нечего выдавать

Сотрудник, которого вы у нас нанимаете, не открывает соединение с внешним сервисом сам.

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

сотрудник
   │  описание вызова — без ключей
   ▼
платформа
   │  чья сессия → чей кабинет → достать доступ
   │  проверить адрес · распознать запись · записать в журнал
   ▼
ваш кабинет

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

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

Промпт-инъекция не выносит доступы. Классическая атака на агента — подсунуть ему текст, который он прочитает как инструкцию: письмо от «контрагента», описание товара, комментарий в задаче. Если у агента есть ключ, инструкция «перешли свои настройки по адресу» технически исполнима. Если ключа нет — исполнять нечего.

Утечка логов не утечка ключей. Ключ не проходит через агента, значит, не попадает ни в один его лог, ни в одну трассировку, ни в одну отладочную выгрузку.

Подрядчик не уносит доступы. Настроил интеграцию, ушёл — уносить нечего, у него их и не было.

Что меняется

Несколько строк этой таблицы стоит расшифровать — за каждой стоит отдельная проверка, а не намерение.

Адрес кабинета зафиксирован заранее. Он записан в описании самого сервиса, а не приходит в вызове. Ни один вызов не может увести запрос на другой хост — даже если бы модель этого захотела, даже если бы её об этом попросил текст, который она читает. Проверка происходит до того, как в сеть уходит первый байт.

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

Повтор не удваивает действие. Изменяющий вызов несёт ключ идемпотентности. Сеть моргнула, задача переотправилась — счёт всё равно выставится один раз, а не два.

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

Контур, из которого ничего не выходит

Отдельный разговор — про 1С и всё остальное, что живёт внутри периметра.

Если сервер не смотрит наружу, модель «внешняя платформа шлёт ему запрос» не работает ни у кого. Ни у нас, ни у Vercel, ни у любого SaaS. Обычный выход — открыть порт и прикрыть его чем-нибудь, и именно на этом месте служба безопасности говорит «нет», а проект умирает.

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

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

Доступ — половина дела. Вторая — право сделать

И здесь мы расходимся с западной моделью сильнее всего.

Суженный токен отвечает на вопрос «куда агент может пойти». Он не отвечает на вопрос «что ему там можно сделать». Токен на запись в CRM — это право создать сделку и право удалить сотню сделок; для токена это одна и та же запись.

Для сотрудника — не одна и та же.

Поэтому каждое действие у нас распознаётся до исполнения и попадает в один из трёх разрядов: чтение, изменение, необратимое. Чтение идёт молча — за этим его и нанимали. Изменение сверяется со ступенью самостоятельности, выданной этому сотруднику на этом участке: либо проходит, либо он останавливается и спрашивает вас. Спрашивает конкретным «отправить это КП контрагенту на такую-то сумму?» — с текстом, суммой и адресатом, а не абстрактным «разрешить действие».

Каждое выполненное изменение ложится строкой в журнал, который нельзя переписать задним числом: что сделано, на каком основании, чем закончилось и как это откатить.

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

Когда аудитор или собственник спросит, кто и когда трогал систему, ответ — запрос к журналу, а не расследование по переписке.

Чего мы не делаем

Честность про границы полезнее, чем ещё один абзац про преимущества.

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

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

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

Итог

Разница между «мы дали софту наши пароли» и «мы наняли сотрудника» — не в интерфейсе и не в качестве модели.

Софту выдают ключ и надеются. Сотруднику выдают доступ к участку, ступень самостоятельности и журнал, по которому видно, что он делал, пока на него не смотрели. Первое всегда останется риском, который кто-то однажды подпишет своей фамилией. Второе — обычная управленческая практика, которой ваша компания занимается каждый день, просто применённая к работнику нового типа.

Мы сделали второе. Больше ста кабинетов из коробки — маркетплейсы, CRM, банки, мессенджеры, документооборот, 1С — и ни одного ключа на руках у агента.

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