Инвертированное подтверждение владения при онбординге

Паттерн на стороне сервиса, позволяющий ИИ-агентам самостоятельно регистрировать учётные записи, сохраняя при этом ответственность за человеком. Агент регистрируется первым, указывая email человека и желаемое имя пользователя, и получает сильно ограниченный аккаунт. Первая задача агента - отправить человеку письмо с просьбой подтвердить владение. Как только человек вводит OTP (или регистрируется в консоли напрямую), учётная запись превращается в обычный аккаунт человека, а агент выступает в роли его principal.

Термин сформулирован по мотивам реализации в agentmail, но сама схема универсальна.

Схема работы

agent ──register(human_email, username)──▶ service
agent ──email(human_email, OTP request)──▶ human
human ──OTP / console signup──▶ service
service ──unlock(agent)──▶ agent

До разблокировки у агента есть ровно одна возможность: отправлять почту указанному человеку с лимитом не более 10 писем в день. Любой другой endpoint возвращает ошибку.

Чем это интересно

Привычные способы выдачи учётных данных агенту неудобны по разным причинам:

• Предварительно созданные учётные данные. Человек создаёт аккаунт и вставляет API-ключ в агента. Это работает, но человек становится узким местом: агент не может сам завести себе почтовый ящик, кластер или базу данных без прямого участия человека. К тому же такой ключ оказывается долгоживущим (long-lived-keys).
• Агент напрямую использует учётные данные человека. Сценарии OAuth рассчитаны на браузер. Боты, которые вытаскивают сессии или переиспользуют cookie, легко ломаются и выглядят как захват аккаунта.
• Агент имеет собственную бесконтрольную идентичность. Отдельный аккаунт без привязанного человека работает ровно до первого злоупотребления или проблемы с оплатой. В этот момент обратиться оказывается просто не к кому.

Инвертированное подтверждение находит компромисс. У агента есть собственный principal (свой API-ключ, свой идентификатор), но человек привязан к нему с первой минуты - причём первым взаимодействием человека становится прочтение приветственного письма от агента, и именно в этот момент решается вопрос о доверии.

За счёт чего работает ограничение

Ограниченное состояние - несущая конструкция всей схемы. Если бы новый неподтверждённый агент мог отправлять почту кому угодно, паттерн свёлся бы к сценарию "любой может запустить спам-бота с поддельным полем human_email". Лимит на одного получателя (только указанный человек) плюс низкий дневной лимит (10 писем) лишают массовую регистрацию смысла: каждый неподтверждённый аккаунт может писать только на тот адрес, который атакующий сам указал в форме.

Здесь работает та же логика, что и в ephemeral-credentials: сконцентрировать рутину на этапе инициализации, а не в штатном режиме работы. До подтверждения радиус возможного ущерба ограничен спамом на один указанный адрес. После подтверждения ответственность несёт человек.

Когда применять этот паттерн

• При разработке сервиса, основным потребителем которого являются агенты, а люди выступают ответственными владельцами (а не постоянными операторами)
• Когда нужно, чтобы агент работал как полноценный principal (собственная аутентификация, свои квоты), не теряя при этом подотчётности человеку
• Если сценарий онбординга допускает цикл "отправить письмо и подождать ответа"
• Если агент способен написать связное приветственное письмо, которое имеет смысл прочитать

Паттерн подходит хуже, если:

• Человек тоже будет пользоваться этим аккаунтом (тогда человеку проще зарегистрироваться первым)
• У агента нет возможности связаться с человеком по внешнему каналу до подтверждения (email сейчас остаётся единственным осмысленным каналом для этого)
• Недопустимо окно асимметричного доверия (даже при низком rate limit'е неподтверждённый агент всё равно создаёт некоторую поверхность для злоупотреблений)

Варианты и смежные идеи

• Magic link вместо OTP. Эквивалентный вариант: проверка просто смещается с "ввести код агенту" на "перейти по ссылке из письма". OTP удобнее для агента, так как не требует браузера.
• Предварительно созданное приглашение. Человек заранее регистрирует имя пользователя для агента, а агент позже забирает его себе. Конечный результат тот же, но порядок действий другой - и это менее удобно, так как человеку приходится планировать всё заранее.
• Делегирование вместо создания. Аккаунт человека создаёт субагентов внутри себя с ограниченным набором прав. Это направление sandboxing-ai-agents - оба паттерна вполне могут сосуществовать.

Открытые вопросы

• Как это сочетается с рисками из oauth-token-theft? Передача OTP по почте сама по себе уязвима для фишинга: атакующий, перехвативший письмо, может подтвердить владение агентом на себя.
• Что происходит при offboarding'е? Если человек уходит из компании, передача агента новому куратору в базовом паттерне не определена; документация AgentMail обходит этот вопрос стороной.
• Выдержит ли паттерн корпоративную IT-инфраструктуру, где почта сотрудников централизованно фильтруется, а письмо от регистрирующегося агента рискует автоматически попасть в карантин?