Claude Code считывает файлы, запускает команды оболочки, вызывает инструменты MCP и действует с использованием учетных данных, доступных на компьютере разработчика. Новые конечные точки API Compliance от Anthropic предоставляют специалистам по безопасности наиболее полную на сегодняшний день картину этой деятельности. Они также выявляют более глобальную проблему: одни только журналы активности не позволяют определить, является ли доступ агента законным.
Благодаря таким инструментам, как Claude Code, ИИ перешел из вкладки браузера на конечные устройства. Они работают на компьютерах разработчиков, локально выполняют команды bash и подключаются к сторонним сервисам через серверы MCP, навыки и плагины. Все это делается для того, чтобы пользователь мог передать часть работы машине и сосредоточиться на проектировании, размышлениях и творчестве.
Локальные агенты — это не нишевая категория. На их долю приходится 68,6 % агентов ИИ, обнаруживаемых Token Security в средах клиентов, и они часто наследуют учетные данные, сетевое положение и разрешения сотрудника.
Переход к конечным устройствам имеет серьезные последствия для безопасности. В случае с Claude Code отсутствует централизованная консоль для мониторинга агентов на конечных устройствах в контексте локальных конфигураций, идентификации и доступа, а также времени выполнения. До августа 2026 года встроенные средства управления Anthropic обеспечивали ограниченную видимость того, чем на самом деле занимались эти агенты, что вынуждало команды использовать сторонние расширения даже для обеспечения минимального уровня управления.
Благодаря новым конечным точкам транскрипции локальных сеансов в API соответствия Anthropic вы можете более эффективно управлять своими локальными агентами, при этом понимая, какие ограничения все еще существуют.
Харнесс — это сложный оркестратор. Он принимает ввод пользователя и отправляет его в LLM вместе с полным контекстом сеанса. Сам LLM не поддерживает состояние; он получает от харнеса всё необходимое для оперативного реагирования. Компонентом, который фактически выполняет команды, проходит аутентификацию у третьих сторон и подключается к серверам MCP, является харнес, а не LLM.
Сравните конечный агент с человеческим телом. LLM — это мозг: он обрабатывает данные и принимает решения. Всё остальное — это «харнес», от рук и ног до органов чувств. Это странная гибридная система, и наша модель безопасности должна адаптироваться к ней. Мозг работает в облаке Anthropic, но руки работают на ваших конечных устройствах, и именно там должны находиться ваши возможности мониторинга и контроля.
Сейчас модно говорить, что SaaS мертв, и это немного грустно (SaaD), потому что классический SaaS решал за нас много задач. Мы ожидаем, что сервис позволит нам управлять и контролировать наше предприятие с центральной панели управления, контролировать организационные политики и четко видеть, что могут делать агенты внутри нашего предприятия.
С локальными системами дело обстоит иначе. Claude Code бросает вызов классической модели разделения ответственности и возлагает большую нагрузку на администраторов. В опросе Cloud Security Alliance, проведенном по заказу Token среди 418 специалистов в области ИТ и безопасности, 68 % респондентов оценили свою осведомленность об ИИ-агентах как высокую. В том же опросе 82 % респондентов сообщили, что за последний год обнаружили агент, о существовании которого не знали ни специалисты по безопасности, ни ИТ-специалисты, ни руководство.
Загадайте мне загадку: я живу на вашем хосте в качестве агента, но я был здесь задолго до появления какого-либо LLM. Я знаю о вашем Claude Code больше, чем сама компания Anthropic, потому что конечные точки — это моя сфера.
Поскольку большая часть выполнения «кода Клода» происходит локально, телеметрия конечных точек может выявить процессы, файлы и конфигурации, которые недоступны для облачных сервисов. Однако EDR предоставляет лишь доказательства, а не модель управления. Он не может связать активность агента с его владельцем, намерениями, учетными данными и разрешениями.
Собственные инструменты Anthropic помогают, но их недостаточно, чтобы предотвратить разрушительные действия LLM, даже если эти действия могут быть законными. Существует три ключевых уровня сбора данных для эффективного управления локальными ИИ-агентами. Вам необходимо понять, что предоставляет вам Anthropic, что может собирать только агент на конечных устройствах и что вам нужно делать с этими данными.
Уровень 1: Управляемые настройки — базовая политика
Механизм обеспечения соблюдения правил в Anthropic — это управляемые настройки. Каждый конечный узел, на котором установлен Claude Code, имеет запись управляемых настроек: файл JSON на Mac и Linux и записи реестра в Windows. Правила этой записи имеют приоритет над глобальными настройками, настройками проекта и пользователя, что позволяет применять базовые требования ко всем сеансам работы с Claude Code в организации. В рамках корпоративного тарифного плана Claude Code политики применяются через графический интерфейс; если такой планы отсутствует, ваша система MDM может записывать запись управляемых настроек на все конечные устройства.
Доступные правила охватывают широкий спектр возможностей:
списки разрешенных и запрещенных элементов для определенных серверов MCP
Регулярные выражения для команд bash
Запрет на использование навыков для выполнения команд и многое другое
Списки разрешенных и запрещенных серверов MCP
Запрет на выполнение команд с помощью навыков и многое другое
Они помогают, но лишают ваших разработчиков значительной свободы действий, а статические политики разрешений и запретов не рассчитаны на темпы развития современного ИИ. Хуже того, они не учитывают контекст или намерения. По сути, они представляют собой огромный валун посреди реки, который затрудняет течение, но не останавливает его.
До недавнего времени API Compliance от Anthropic в основном охватывал действия claude.ai, то есть активность через веб-интерфейс и Claude Desktop, при этом поддержка Claude Code была весьма ограниченной. 11 августа 2026 года компания Anthropic представила новые конечные точки для локальных сеансов:
Они позволяют отслеживать агентов, работающих на конечных точках, на основе их взаимодействия с моделями Anthropic. Всё, что передаётся модели, регистрируется в виде трёх типов блоков: text, tool_use и tool_result. В совокупности они охватывают запросы пользователей, команды bash, операции чтения и записи, и даже команды MCP.
Модель не хранит состояние на стороне сервера. Файлы навыков и плагинов в формате .md существуют только на конечной точке, поэтому система тестирования пересылает полный контекст модели на каждом шаге. Всё, что поступает в модель, попадает в API Compliance, что чрезвычайно полезно для управления и мониторинга.
При правильном анализе стенограммы сеансов позволяют регистрировать использование инструментов и составлять перечень ваших агентов: навыки каждого из них, используемые им серверы MCP и его плагины.
API Compliance также охватывает административные действия, в основном на уровне организации, и в меньшей степени — для отдельных пользователей, изменяющих настройки. Я ожидаю, что со временем этот охват расширится.
Почему вам всё же может понадобиться OpenTelemetry
OpenTelemetry (или OTel) — это стандарт с открытым исходным кодом для трассировок, метрик и журналов событий, и он встроен в каждый распространенный инструментарий, требуя лишь настройки.
Некоторые действия на конечной точке никогда не доходят до LLM, поэтому API соответствия их не видит. Наиболее наглядным примером являются хуки: они запускаются локально, между принятием решения моделью и фактическим запуском инструмента, и могут заблокировать выполнение инструмента или отправку запроса.
OTel также фиксирует решения о разрешениях для инструментов и информацию о том, кто их принял — будь то политика, хук или пользователь, давший разрешение. Кроме того, изменения разрешений, переведенные в режим bypassPermissions / auto, будут регистрироваться в OTel, но не в API Compliance.
OTel был создан для регистрации атомарных действий. Транскрипты сеансов представляют собой длинные, очень подробные JSON-файлы без возможности регулировать уровень детализации, и их необходимо обрабатывать, чтобы получить тот же результат регистрации событий. Если вы не хотите собирать и хранить чрезвычайно объемные транскрипты, OTel может оказаться более простым инструментом (пока не появится что-то лучшее).
И есть строгое ограничение: если вы запускаете Claude Code на модели, не принадлежащей Anthropic, вы вообще не получите покрытия со стороны Compliance API, поскольку он регистрирует только взаимодействия с моделями Anthropic. Сеансы, запущенные на Bedrock, Foundry или Google Cloud, не будут охвачены.
Важное замечание: локальные стенограммы сеансов могут содержать конфиденциальные данные, включая персональные данные (PII), секретную информацию и данные клиентов. Их хранилище само по себе становится источником конфиденциальных данных. Относитесь к нему соответственно.
Уровень 3: То, что может сообщить только конечная точка
Compliance API и OTel фиксируют то, что ДЕЛАЮТ агенты. Ни один из них не может видеть, что находится на диске: конфигурационные файлы, установленные навыки и плагины, а также их файлы .md (если они не использовались в сеансе) или процессы, запущенные вне сеанса. Именно здесь агент конечной точки оправдывает своё существование. Собирайте файлы конфигурации, извлекайте файлы .md навыков и плагинов и сопоставляйте журналы EDR, чтобы выявлять опасные команды bash, поступающие от агентов. Token Security обнаруживает в среднем более 10 файлов конфигурации на каждый локальный агент, разбросанных по конечной точке.
Ещё один элемент, хранящийся на диске, который вы также можете извлечь через API Compliance: стенограммы сеансов. По умолчанию Claude Code хранит всю историю сеансов локально в течение 30 дней, чтобы пользователи могли быстро возобновить предыдущую работу. Злоумышленник, получивший доступ к конечной точке, также может прочитать эти файлы, поэтому следует соблюдать ту же осторожность.
Не забывайте о стенограммах при составлении плана охвата. Начните с ответственного использования: не допускайте, чтобы пользователи записывали секретные данные в открытом виде в сессиях, маркируйте проекты и сессии, содержащие данные клиентов или конфиденциальную информацию, и удаляйте их по расписанию. Затем добавьте средства обнаружения и реагирования: выявляйте запросы пользователей, содержащие секретные данные в открытом виде, и принимайте меры в отношении сессий, которые могут поставить под угрозу данные клиентов.
Немного о разборе стенограмм
Чтобы получить журнал атомарных действий из сеансов Claude Code, необходимо обработать стенограммы Compliance API. Как указано выше, каждое сообщение представляет собой либо текст, либо tool_use, либо tool_result, заключенный в поля, такие как user, assistant (ответы LLM) и другие. Для обнаружения фактических плагинов, навыков и серверов MCP требуются несколько дополнительных приемов.
Простой случай: каждая команда отображается как tool_use с «name»: «Bash», а полная командная строка находится в значении input.
Они отображаются в виде «tool_use», имя которого имеет формат mcp__<server>__<command>. Серверы, принадлежащие самой платформе, используют понятные названия, поэтому тип часто можно определить с первого взгляда: Jira, Slack, Notion. Серверы, подключённые пользователями, отображаются в виде UUID, и определить сервис можно по суффиксу команды (slack_send_message) или по таблице сопоставления UUID и имён, которую вы ведёте.
Каждый из них представляет собой постоянные учетные данные для данного конечного пункта, и примерно треть из них поступает из-за пределов экосистемы поставщика: 35,1 % серверов MCP, обнаруженных Token Security, созданы сообществом или имеют неизвестное происхождение.
Названия навыков не указываются в поле так же, как команды MCP, но их можно определить косвенно. Когда запускается навык, LLM не может использовать его без контекста, поэтому тестовая среда отправляет файл SKILL.md через API, либо вставляя содержимое навыка напрямую, либо выполняя запрос Read по его пути. Этот запрос «Read» раскрывает как название навыка, так и его расположение: входной параметр `tool_use` содержит путь, а текстовый параметр `tool_result` — содержимое навыка.
С плагинами сложнее, поскольку плагин — это не отдельный файл. Он объединяет различные типы расширений, включая навыки и скрипты. Имена плагинов можно определить по соглашениям об именовании путей, когда один из скриптов или файлов .md плагина считывается в контекст.
Всё это работает без вмешательства в запросы пользователя, исключительно на основе блоков `tool_use` и командной строки.
Управляемые настройки + локальные стенограммы сеансов + сбор данных с конечных точек = Хорошо, но недостаточно
Архитектура Claude Code создает вызовы, на которые не может ответить ни один отдельный уровень. Вместе эти три уровня справляются лучше, но всё равно не дотягивают:
Даже всех трёх недостаточно, поскольку ни один из них не отражает контекст вашего предприятия и не углубляется достаточно в привязку доступа к намерениям. Администратор, просматривающий транскрипты, не может отличить вредоносный плагин, загруженный из Интернета, от легитимного, написанного инженером. Чтобы устранить этот пробел, требуется контекст из других источников в организации, например, сопоставление навыков и плагинов, запущенных на конечных устройствах, с теми, которые фактически управляются вашими внутренними репозиториями, что повышает степень легитимности. Как только у вас появится этот контекст по всей организации, обнаружение даже одного вредоносного навыка даст вам «тепловую карту» мест его запуска, и меры по устранению угрозы будут приняты быстро.
Телеметрия может показать, что произошло. Управление требует сопоставления этих сигналов с владельцем агента, его целью, идентификационными данными, учетными данными, разрешениями и путями доступа. Этот контекст позволяет определить, оправдан ли доступ, ограничить его до минимально необходимых прав и отозвать его, когда цель агента будет достигнута. Идентификация — это плоскость управления, которая преобразует данные о конечных точках и сеансах в обеспечение безопасности ИИ-агентов, поддающееся принудительному исполнению.
Узнайте, как Token обеспечивает безопасность ИИ-агентов на конечных устройствах, в облаке, SaaS и средах разработчиков, посмотрев краткую демонстрацию в любое время.
Примечание: эта статья была написана и предоставлена экспертом в области безопасности, исследователем Дэном Абрамовым.