Агенты как первоклассные субъекты идентификации

Архитектурное решение, нагляднее всего воплощённое в Buzz от Block: агент получает такую же структуру идентичности, как и человек - собственную пару ключей, собственное членство в каналах, собственный аудит-лог, - а каждое его действие становится криптографически подписанным событием. Это отличается от привычной схемы, где агенты работают через общий аккаунт бота, сервисный токен или учётные данные человека.

Что теряется при обычной схеме

Когда агент делает коммиты под личностью человека или общего ci-bot, постфактум невозможно восстановить три вещи: какой именно субъект совершил действие, был ли этот субъект человеком, и какой именно из нескольких агентов это сделал. С ростом объёма создаваемого агентами кода это становится важнее, поскольку журнал аудита остаётся единственным местом, где зафиксировано это различие: сам артефакт его не содержит. В этом состоит предпосылка ai-detector-arms-race и причина, по которой slop-marker-convention вообще существует.

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

Что это всё ещё не решает

Это не восстанавливает усилия - а именно их потеря рассматривается в agent-principal-agent-problem как главный ущерб. Знание о том, что agent-7 открыл патч на 900 строк, ничего не говорит о том, думал ли человек над промптом или набрал два предложения и отошёл. Атрибуция и усилия - это разные сигналы, и криптографически восстановить можно только первый.

Поэтому честное утверждение звучит скромнее, чем "подписанные события обеспечивают подотчётность агентов". Они делают агентов идентифицируемыми. Подотчётность по-прежнему замыкается на того, кто несёт ответственность за действия агента, а это организационный вопрос, на который схема подписей не отвечает. В credibility-as-slop-test показан тот же пробел со стороны текстов: подтверждённая личность автора указывает, кто написал, но не гарантирует, что автор готов защищать написанное.

Вторичные эффекты, за которыми стоит следить

• Права доступа привязываются к агенту. Когда агент становится субъектом идентификации, ему можно выдать ограниченный доступ вместо наследования полных прав человека. Это реальный выигрыш в безопасности и, вероятно, самый сильный практический аргумент в пользу такого подхода. pigeon реализует часть с ограничением прав без отдельных идентичностей - через подписанные пропуска, которые могут только сужать доступ.
• Появляется возможность отзыва прав. Ключ скомпрометированного или некорректно работающего агента можно отозвать, не затрагивая аккаунт его оператора.
• Журнал аудита становится базовым слоем. В Buzz обсуждения, события в коде, шаги workflow и согласования - всё это подписанные события в едином хранилище; именно поэтому feature-ветка может быть отдельным каналом. Решение об идентичности и решение о едином журнале событий усиливают друг друга.
• Хранение ключей становится проблемой. Агент, хранящий собственный ключ подписи, рискует отдать его наружу через любой текст, который он читает. В контексте prompt injection ограниченная идентичность агента уменьшает радиус поражения, но одновременно создаёт ценный секрет, которого раньше просто не существовало.

Связанные страницы

• block-buzz-workspace - реализация, из которой взята эта концепция
• agent-principal-agent-problem - сигнал об усилиях, который идентичность не возвращает
• slop-marker-convention, human-made-disclosure - альтернативы на основе добровольного декларирования
• re_gent - происхождение работы агента с детализацией до каждого промпта со стороны системы контроля версий
• a-voice-from-nowhere - полный аргумент со стороны затраченных усилий: попытка вернуть уровень, на котором ещё существовало понимание, до которого не дотягивается ни одна схема подписей