SOC 2 для ИИ-агентов может стать следующим больным местом корпоративной безопасности: агенты уже действуют через человеческие сессии, OAuth-разрешения, API-ключи и сервисные аккаунты, а аудит часто видит только знакомое имя сотрудника в логе. По данным BleepingComputer, Token Security предупреждает: если SOC 2 не начнет явно учитывать агентные идентичности, часть проверок будет проходить формально, но не отвечать на главный вопрос — кто именно получил доступ и что он сделал.
SOC 2 важен не как декоративный бейдж на сайте поставщика. Для многих B2B-компаний это билет в закупку: без отчета отдел безопасности клиента просто не пустит сервис к данным. Проблема в том, что классические проверки доступа строились вокруг людей. Есть сотрудник, есть заявка, есть владелец аккаунта, есть журнал действий. С ИИ-агентами эта цепочка начинает расползаться: агент может появиться как побочный эффект клика по кнопке «Разрешить», добавленного MCP-сервера в JSON-конфиге или ключа, вставленного в файл настроек.
Token Security разбирает это на примере обычной строки в access review: продакшен-база, 10:03, 50 запросов от имени старшего инженера. Формально все красиво: доступ выдан, роль соответствует, лог содержит конкретного пользователя. Но инженер в этот момент мог пить кофе, а запросы выполнял агент, которому раньше разрешили работать через его учетные данные. Для аудитора строка выглядит привычно. Для команды безопасности это уже другой риск: не человек с контекстом и ответственностью, а программа, которая действует по инструкциям, впитывает окружение и может выполнять цепочки операций быстрее, чем кто-либо успеет моргнуть.
В статье выделены четыре предположения, на которых держатся многие проверки SOC 2, особенно в зоне критериев CC6.1–CC6.3. Первое: аккаунт кто-то одобряет до создания. Второе: у каждого аккаунта есть известный владелец. Третье: имя в логе указывает на реального исполнителя. Четвертое: по разрешениям аккаунта можно понять, для какой работы он предназначен. Для людей это обычно работало достаточно хорошо. Для агентов — уже нет. Владелец может быть вычислен задним числом по репозиториям, ключам и артефактам, а не записан в системе как факт. Лог может показать сотрудника, хотя действовал агент. А набор прав показывает только максимальный радиус поражения, но не намерение конкретного запуска.
Самая неприятная часть — различимость. В материале приводится оценка исследования Cloud Security Alliance: более двух третей организаций не могут четко отделить действия ИИ-агентов от действий людей. Для русскоязычных IT-команд это не теоретическая страшилка из презентации поставщика. Если разработчики уже используют агентные IDE, локальные помощники, MCP-серверы, внутренние автоматизации и SaaS-интеграции, то вопрос «кто сделал изменение» постепенно превращается в «какой человек, какой агент и через какой токен оказались в одной цепочке».
Из-за этого проседают сразу несколько привычных контролей. Offboarding в SOC 2 обычно хорошо отстроен для сотрудников: HR отметил увольнение, IdP погасил учетку, SaaS-сервисы закрыли доступ, аудит получил доказательства. У агентов нет HR-системы и понятного органа, который скажет: этот агент больше не нужен. Если агент был привязан к человеку, его OAuth-гранты или API-ключи могут пережить увольнение владельца, если компания специально не проверяет такой сценарий. Контроль не сломан, он просто смотрит в сторону от новой проблемы.
Похожая история с поставщиками. SOC 2 предполагает понятный процесс: контракт, оценка вендора, отчет, ежегодный пересмотр. Но MCP-сервер или агентная интеграция могут прийти не через закупку, а через конфигурационный файл разработчика. При этом они получают данные, выполняют действия от имени компании и запускают код, который никто внутри может не читать. Token Security отдельно указывает, что примерно три из десяти названий в их реестре не удается сопоставить с существующей компанией. Это не статистика по каждой конкретной среде, но сигнал неприятный: у безымянного «поставщика» невозможно запросить SOC 2-отчет.
Еще один тонкий участок — разделение обязанностей в change management, связанный с CC8.1. В классической схеме автор изменения и утверждающий должны быть разными людьми. Но если один агент подготовил изменение, а второй агент его проверил, формальное разделение идентичностей еще не означает независимую проверку. Решение могло родиться в промпте, в инструменте, которого нет в описании системы, а единственным видимым следом станет pull request. На бумаге процедура соблюдена, в реальности контур контроля стал намного мутнее.
Для бизнеса вывод довольно практичный: SOC 2 для ИИ-агентов не обязан превращаться в новый бюрократический том, но ему нужны отдельные признаки агентной активности. Компаниям придется инвентаризировать агентов, связывать их с владельцами, хранить происхождение токенов, отличать человеческие и агентные действия в логах, учитывать агентов при увольнении сотрудников и проверять MCP-интеграции как потенциальных поставщиков. Иначе аудит продолжит честно подтверждать, что старые контроли работают, хотя значимая часть действий уже происходит рядом с ними, почти в слепой зоне.