Подпись кода для AI-агентов: подтверждайте сеансы на основе доказательств

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

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

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

Подпись идентифицирует код, но не намерение

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

В документации Apple по подписи кода, Technical Note TN2206, подписи описываются как способ проверить код и задать designated requirement, с помощью которого macOS может впоследствии узнавать тот же код. Designated requirement важен потому, что он точнее имени файла. Исполняемый файл с названием agent можно скопировать куда угодно и переименовать. Подписанная идентичность сохраняет связь с исходным кодом лучше, если цепочка подписей и требование по-прежнему проходят проверку.

Такая связь отвечает на практический вопрос: «Это клиент, который мы согласились разрешить?» Но она не отвечает на другие не менее практичные вопросы:

• Получил ли агент инструкции, которым ни в коем случае нельзя попасть в рабочую среду?
• Запустил ли пользователь этот процесс намеренно, из ожидаемого каталога проекта?
• Есть ли у процесса расширение, плагин или конфигурация, меняющие его поведение?
• Относится ли запрошенный вызов API к этой задаче?
• Не обладает ли учётная запись, стоящая за вызовом, большими полномочиями, чем нужно для задачи?

Люди часто воспринимают имя издателя как окончательный вердикт. Это не так. Подписывающая сторона показывает, кто контролировал учётные данные подписи, использованные для этого артефакта. Крупный издатель может подписывать множество программ. Небольшая внутренняя команда может выпустить вполне подходящую сборку. Решение об авторизации должно сравнивать наблюдаемую идентичность со списком разрешённых вариантов, который команда может объяснить, а не с расплывчатым ощущением, что имя издателя кажется знакомым.

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

Воспринимайте карточку подтверждения как запись об источнике запроса

Карточка подтверждения должна дать оператору достаточно информации, чтобы до авторизации связать запрос с реальным процессом. Подписывающую сторону стоит показывать вверху, потому что её труднее подделать, чем название процесса, но рядом должны быть путь к процессу и сведения о сеансе.

Для процесса, запрашивающего доступ на общем компьютере, я хочу видеть в одном месте такие факты:

• Идентичность исполняемого файла или приложения и полный локальный путь.
• Подписывающую сторону или designated requirement, по которому распознаётся процесс.
• Идентификатор процесса и родительский процесс, чтобы было понятно, кто его запустил.
• Учётную запись macOS, которой он принадлежит.
• Канал действия и назначение, например хост API или SSH-хост.

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

На общем Mac учётная запись пользователя не является формальностью. Если два инженера используют один логин, подтверждение почти ничего не говорит о том, кто запустил агента. Компьютер всё ещё может показать, какой процесс сделал вызов, но команда потеряла чёткую границу между людьми ещё до начала процесса авторизации. Отдельные учётные записи macOS дешевле, чем спор о содержимом истории терминала после инцидента.

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

Проверьте исполняемый файл до того, как сделаете его одобренной идентичностью

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

В macOS программа codesign может показать сведения о подписи. Подробный вывод направляется в стандартный поток ошибок, поэтому для сохранения результата проверки перенаправьте его:

codesign -dv --verbose=4 /Applications/ApprovedAgent.app 2\u003e\u00261

Обычно вывод содержит такие поля:

Executable=/Applications/ApprovedAgent.app/Contents/MacOS/ApprovedAgent
Identifier=com.example.approved-agent
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=...
Authority=Developer ID Application: Example Developer (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
TeamIdentifier=ABCDE12345
Sealed Resources version=2 rules=13 files=...

Храните вместе Identifier, конечное значение Authority и TeamIdentifier. Один Team ID плохо подходит для правила авторизации, потому что одна организация может подписывать разные приложения. Один идентификатор тоже слабее: неподписанная программа может использовать тот же идентификатор пакета. Полезным утверждение делает вся цепочка.

Затем проверьте подписанное содержимое:

codesign --verify --deep --strict --verbose=2 /Applications/ApprovedAgent.app

При успешной проверке результат часто не выводится. Ошибка укажет на изменённый вложенный компонент или другую проблему с подписью. Параметр --deep просит codesign рекурсивно пройти по вложенному коду. Для проверки это удобно, но не считайте такой результат доказательством того, что каждый вложенный компонент соответствует вашей политике безопасности. Apple отмечает, что глубокая проверка выполняется рекурсивно и может скрыть необходимость отдельно изучить схему подписи компонентов пакета.

Для приложения, полученного не через управляемый канал распространения программ, запросите также оценку Gatekeeper:

spctl --assess --type execute --verbose=4 /Applications/ApprovedAgent.app

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

Запишите проверенный путь. Если позже человек одобрит /Users/alex/bin/agent, потому что его метка похожа на метку проверенного приложения из /Applications, проверка не была повторена. Путь является частью доказательств.

Подпись интерпретатора не подтверждает скрипт, который он запускает

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

Представьте разработчика, который запускает агента такой командой:

/usr/bin/python3 /Users/dev/work/demo/tools/agent_runner.py

Системный Python может иметь известную подпись. Это говорит об исполняемом файле интерпретатора. Но ничего не говорит о agent_runner.py, файлах, которые он импортирует из репозитория, файле .env, который он читает, или инструкциях, переданных через стандартный ввод. Если интерфейс подтверждения показывает только python3, злоумышленнику достаточно изменить скрипт или состояние проекта, а не интерпретатор.

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

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

Базовый контекст работающего процесса можно посмотреть стандартными средствами:

ps -p 4821 -o pid=,ppid=,user=,command=
ps -p 4812 -o pid=,ppid=,user=,command=

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

Для клиента на основе скрипта включите дайджест скрипта в запись подтверждения. Простая локальная проверка поможет заметить изменения:

shasum -a 256 /Users/dev/work/demo/tools/agent_runner.py

Дайджест не делает скрипт надёжным. Он даёт команде конкретный ответ на вопрос, изменился ли одобренный скрипт между запусками. Храните ожидаемый дайджест только для проверенного выпуска или контролируемого состояния проекта. Не превращайте копирование хешей из сообщений чата в формальный ритуал.

На общих компьютерах сначала нужны границы учётных записей

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

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

Рабочая схема также разделяет чувствительные назначения. Создайте отдельные записи и метки учётных данных для разработки, тестовой и рабочей среды, чтобы оператор сразу видел намерение. Подтверждение для inventory-staging не должно незаметно выбрать рабочие учётные данные только потому, что обе записи указывают на один клиент API. Если имя учётных данных скрывает среду, человек не сможет принять взвешенное решение в нужный момент.

Физический доступ тоже важен. Человек у разблокированного общего Mac может запустить процесс под активной учётной записью и дождаться, пока владелец нажмёт кнопку в запросе. Блокируйте экран, отходя от компьютера, требуйте новый вход после выхода из сна и не оставляйте привилегированный терминал работающим в общем помещении. Это обычные меры, поэтому команды часто пропускают их, пока не начинают устранять вполне предотвратимый беспорядок.

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

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

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

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

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

Разделяйте авторизацию и аутентификацию. Touch ID или пароль могут доказать, что присутствующий пользователь macOS подтвердил действие. Они не идентифицируют процесс. Подпись кода может помочь идентифицировать процесс. Ни один из этих механизмов не решает, подходят ли назначение и действие. Хорошая карточка подтверждения показывает все три типа данных и не выдаёт их за взаимозаменяемые.

Для обычной работы с репозиторием решение о сеансе может охватывать повторяющиеся операции чтения через API разработки. Для действия, которое меняет конфигурацию развёртывания, обновляет учётные данные, удаляет записи или открывает SSH-соединение с рабочим хостом, запрашивайте новое решение именно для этого вызова. Трение должно появляться там, где меняются последствия, а не случайно по истечении таймера.

Подписывающая сторона не предотвращает все ожидаемые сбои

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

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

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

Третий путь связан с манипуляциями локальными процессами. Подписанное приложение может загрузить плагин, унаследовать переменную окружения или запуститься с родительским процессом, который передаст неожиданные аргументы. Защита macOS снижает вероятность некоторых видов вмешательства, но система подтверждений всё равно должна показывать настоящий контекст процесса. Если данные противоречат друг другу, отклоните запрос и проверьте компьютер. Не придумывайте безобидное объяснение только потому, что строка с издателем кажется знакомой.

Четвёртый путь связан с избыточными полномочиями. Правильно идентифицированный клиент может использовать учётные данные, позволяющие сделать гораздо больше, чем требуется для задачи. Ограничивайте учётные данные нужными API, хостом, репозиторием и средой. Подпись кода может показать, какой клиент использовал учётные данные, но не уменьшит их полномочия задним числом.

Поэтому совет «подписано значит безопасно» вреден. Он звучит просто и сокращает число запросов. Но он поощряет подтверждения без указания назначения, описания действия и границы сеанса. Сигнал подписи помогает человеку отличить знакомый код от неизвестного. Он не должен отменять остальные элементы решения.

Для необратимых и важных учётных данных нужно подтверждение каждого вызова

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

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

Сохраняйте удобство для действий с небольшими последствиями. Разработчик, которому приходится подтверждать каждое чтение тестового API, быстро привыкает нажимать кнопку, не читая. Это лишает контроль смысла и облегчает пропуск действительно важного запроса. Авторизация сеанса хорошо работает, когда агент выполняет повторяющуюся ограниченную работу в среде разработки, а идентичность процесса ожидаема.

Последовательность решений должна быть настолько простой, чтобы человек мог объяснить её после тяжёлой недели. Сначала заблокированное хранилище учётных данных отклоняет каждое действие. Затем новый процесс агента запрашивает авторизацию сеанса. Наконец, для отдельных учётных данных требуется подтверждение каждого использования. Не прячьте эти решения в особом языке политик, который может истолковать только один человек. Именно скрытые исключения разрушают правила работы с общими компьютерами.

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

Аудитируйте подтверждение и вызов как отдельные события

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

Полезная последовательность расследования выглядит так:

1. Найдите запись сеанса для процесса, запросившего доступ.
2. Проверьте учётную запись пользователя, путь к исполняемому файлу, подписывающую сторону, родительский процесс и время подтверждения.
3. Найдите вызовы, выполненные в рамках сеанса, и сравните назначения с поставленной задачей.
4. Если сеанс ещё активен, отзовите его. Затем отключите или замените затронутые учётные данные, если вызовы указывают на злоупотребление.
5. Сохраните записи до изменения файлов проекта или переустановки клиента.

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

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

Sallyport ведёт журналы сеансов и активности в одном зашифрованном аудит-журнале с хеш-сцеплением, а sp audit verify проверяет цепочку офлайн без учётных данных хранилища. Поэтому регулярную проверку удобно выполнять после инцидента или перед передачей записей другому проверяющему.

Делайте решения о подтверждении воспроизводимыми, а не личными

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

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

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

Проведите на общем Mac отдельную тренировку отказа. Запустите одобренный клиент из ожидаемой учётной записи и проверьте отображаемую сторону подписи и поведение сеанса. Затем запустите неподписанный скрипт через подписанный интерпретатор, откройте клиент из другой учётной записи и запросите учётные данные, для которых требуется подтверждение каждого вызова. В каждом случае оператор должен сразу понимать правильную реакцию. Если запросы выглядят слишком похожими, улучшите показываемую информацию до того, как люди столкнутся с настоящей ошибкой.

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