Black Hat USA 2026: безопасность AI Agent на Mac

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

Быстрое решение: до 1 августа 2026 года проведите приёмку удалённого Mac по шести зонам — отдельная идентичность, минимальные права, отсутствие секретов на диске, ограниченная сеть, полный аудит и быстрое уничтожение среды. Если хотя бы одна зона не проверяется доказательствами, Agent не допускайте к приватному коду и подписи.

Кому нужен этот материал:
Командам, которые разрешают кодирующим Agent доступ к закрытым репозиториям.
DevOps, запускающим на удалённом Mac подпись, сборки и автоматизацию.
Руководителям безопасности и соответствия, которым нужен формальный порог выхода AI Agent в эксплуатацию.

Последнее обновление — 29 июля 2026 года. Даты и программа сверены с официальными страницами Black Hat USA 2026; во время мероприятия перечень публичных исследований нужно перепроверить по Briefings, Arsenal и официальным материалам. (blackhat.com)

Сначала определите, что именно считается провалом

Black Hat USA 2026 пройдёт с 1 по 6 августа 2026 года в Лас-Вегасе. В официальной программе заявлены AI Summit, AI Zone и доклады по атакам на AI Agent. Это подтверждает актуальность направления, но не даёт права заранее объявлять конкретные ещё не представленные исследования доказанными фактами. (blackhat.com)

Для приёмки вам нужна не общая оценка «Mac защищён», а проверяемая цепочка:

1. какой субъект запустил задачу;
2. какие инструменты и каталоги получил Agent;
3. какие секреты были доступны процессу;
4. какие сетевые соединения разрешены;
5. какие действия записаны;
6. что осталось после завершения.

Разделите результат на три уровня:

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

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

Проверьте личность Agent отдельно от пользователя

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

Проверьте следующие доказательства:

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

Критерий прохождения: по журналу можно отличить ручную команду инженера от вызова инструмента Agent и связать обе операции с одной задачей.

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

Если Agent работает через MCP-сервер, не считайте сам протокол границей безопасности. Официальные рекомендации требуют проверять входящие запросы, применять защищённые идентификаторы сессий и запускать сервер с минимальным доступом к файловой системе, сети и другим ресурсам. (modelcontextprotocol.io)

Изолируйте секреты до запуска сборки

Кодирующий Agent не обязан «красть» сертификат. Достаточно, чтобы секрет оказался в зоне, которую он умеет читать:

• переменная среды;
• файл конфигурации;
• история Shell;
• вывод команды;
• каталог проекта;
• кэш зависимости;
• дамп ошибки;
• журнал CI/CD;
• общий профиль пользователя.

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

Apple рекомендует хранить пользовательские секреты в Keychain, а при изменении или отзыве удалять соответствующий элемент, а не оставлять его в локальном хранилище. Это полезный базовый механизм, но он не заменяет ограничение доступа самого процесса: если Agent получил право читать нужный элемент, защищённое хранилище не остановит разрешённую операцию. (developer.apple.com)

Критерий прохождения:

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

Блокирующее условие: сертификат подписи или API-ключ доступен постоянно, не имеет отзыва или читается любым процессом в пользовательской сессии.

Для подписи macOS-приложений отдельно проверьте, где находится профиль для notarytool, кто может его использовать и не попадает ли пароль в скрипт. Документация Apple описывает хранение профиля в Keychain как способ не помещать пароль в открытый текст автоматизированного сценария. (developer.apple.com)

Ограничьте команды, каталоги и повышение прав

Фраза «Agent может работать только в проекте» ничего не значит, пока это не выражено техническим правилом. Вам нужно перечислить:

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

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

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

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

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

Для чувствительных шагов используйте двухфазный процесс:

1. Agent готовит команду и объясняет ожидаемый результат.
2. Человек подтверждает конкретную операцию.
3. Система выполняет её от имени ограниченной сервисной личности.
4. В журнал попадают инициатор, команда, цель, результат и время.

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

Зафиксируйте разрешённые сетевые выходы

Сетевой контроль должен отвечать не только на вопрос «есть ли Интернет», но и на вопрос «какие данные могут покинуть среду».

Сформируйте белый список:

• одобренные модели и API;
• система контроля версий;
• внутренний реестр пакетов;
• сервис подписи и нотарификации;
• системы наблюдаемости;
• адреса обновления зависимостей.

Запретите произвольные исходящие соединения. Если это невозможно из-за особенностей инструмента, примените прокси с журналированием домена, метода, размера запроса и результата. Содержимое секретов при этом должно маскироваться.

Проведите тестовые задания с искусственными маркерами:

• уникальная строка в исходнике;
• тестовый токен;
• фиктивный сертификат;
• маркер в логе;
• файл с намеренно чувствительным именем.

Затем проверьте, не появились ли эти значения в неразрешённых запросах, ошибках, кэше и истории инструментов.

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

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

Для MCP-интеграций дополнительно проверьте транспорт, авторизацию и привязку сессии к пользователю. Официальные рекомендации отдельно предупреждают, что локальный сервер MCP может работать с теми же привилегиями, что и клиент, поэтому ему нужны песочница и ограничение доступа к сети и файлам. (modelcontextprotocol.io)

Восстановите одну задачу по журналам

Слишком подробный журнал может раскрыть данные, а слишком короткий не позволит расследовать инцидент. Вам нужен баланс: записывать действие, но не секрет.

Минимальное событие должно содержать:

• идентификатор задачи;
• идентичность пользователя и Agent;
• инструмент или команду;
• целевой файл, каталог или сервис;
• время начала и завершения;
• результат;
• причину отказа;
• идентификатор одобрения человека;
• хэш либо ссылку на артефакт.

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

Проверка: возьмите одну тестовую задачу — чтение файла, изменение кода, запуск сборки, отказ в сетевом запросе — и восстановите всю цепочку без доступа к памяти оператора.

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

Подход согласуется с рекомендациями по безопасности агентных приложений: доступ к журналам должен быть ограничен, а действия Agent — иметь операционный след, пригодный для расследования. (genai.owasp.org)

Завершите задачу очисткой, а не выходом из сеанса

Закрытие окна удалённого рабочего стола не означает уничтожение среды. После завершения проверьте:

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

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

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

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

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

Выполните итоговую приёмку по чек-листу

Используйте этот список как минимальный протокол перед выдачей доступа к приватному коду:

• [ ] Для Agent создана отдельная сервисная идентичность.
• [ ] Ручные и автоматические действия различаются в журналах.
• [ ] Общий администраторский аккаунт не используется.
• [ ] Личные постоянные токены удалены из сценариев.
• [ ] Каждый секрет имеет владельца, срок жизни и процедуру отзыва.
• [ ] Сертификат подписи не лежит в рабочем каталоге.
• [ ] Секреты не попадают в переменные среды, историю Shell и логи.
• [ ] Разрешённые команды и каталоги перечислены явно.
• [ ] Высокорисковые записи требуют подтверждения человека.
• [ ] Исходящие сетевые назначения ограничены белым списком.
• [ ] Неодобренные внешние запросы блокируются или регистрируются.
• [ ] В журнале видны субъект, инструмент, цель и результат.
• [ ] Тестовая задача восстанавливается от запуска до очистки.
• [ ] После завершения удаляются кэш, сессии, токены и временные файлы.
• [ ] Процедура уничтожения среды проверена отдельно от процедуры входа.

Оценка должна быть формальной:

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

Почему привычная схема хуже временного Mac

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

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

До 1 августа передайте этот чек-лист в совместную приёмку безопасности и DevOps. Если обнаружится блокирующий пункт, сначала устраните изоляцию прав и секретов, а затем повторите тестовую задачу с полным журналом и подтверждённым уничтожением среды.