Материал

Как безопасно разрешить AI-агентам запускать команды в терминале

Обновлено: 14 мая 2026 Время чтения: 19 мин

Руководство для CTO, Tech Lead и AppSec-инженеров, которые уже работают с Claude Code, Cursor и другими агентами в продакшн-среде

Терминальный доступ — это не удобство, это привилегия

Несколько лет назад AI-ассистент в IDE предлагал строки кода. Разработчик нажимал Tab и сам решал, что с этим делать. Сегодня Claude Code, Cursor Agent, GitHub Copilot Workspace и аналогичные инструменты запускают команды в терминале, переписывают файлы, устанавливают зависимости, выполняют тесты и пушат изменения — часто без паузы на подтверждение.

По данным исследователей из арXiv (январь 2026), современные AI-кодинг-ассистенты прошли три поколения [1]:

Генерация кода (2020–2022): только inline-подсказки, атаки ограничены отравлением обучающих данных.
Чат-ассистенты (2022–2024): conversational interface, новые векторы — direct prompt injection.
Агентные системы (2024 — н. в.): доступ к файловой системе, терминалу, браузеру, API. Вся ширина поверхности атаки.

Именно третье поколение создало проблему, которую не решает стандартный AppSec-стек. Агент не является кодом с фиксированными путями исполнения. Он интерпретирует цели и может достичь их непредсказуемыми маршрутами — затронув десятки систем способами, которые разработчики не предусмотрели [2].

OWASP в декабре 2025 года выпустил первый отраслевой стандарт — Top 10 for Agentic Applications 2026 [3]. Anthropic публично рекомендует запускать Claude Code в изолированных средах именно потому, что «предоставление Claude такого широкого доступа к вашей кодовой базе может создать риски, особенно в случае prompt injection» [4].

Этот материал — практическое руководство по тому, как разрешить AI-агентам работать в терминале, не превращая рабочую машину или CI/CD-пайплайн в открытую дверь.

Часть 1. Что реально происходит, когда агент получает доступ к терминалу

Модель угроз: агент — это доверенный, но не безопасный исполнитель

Принципиальная проблема LLM-систем — структурная: модель не способна надёжно разграничить инструкции и данные [2]. В традиционном приложении код и пользовательский ввод — это разные слои с разными привилегиями. В языковой модели системный промпт разработчика, запрос пользователя и содержимое README из клонированного репозитория — это один и тот же артефакт: натуральный текст в окне контекста.

Это фундаментальная причина, по которой OWASP называет prompt injection уязвимостью #1 (LLM01:2025) для LLM-приложений [3], а в аналогичном списке для агентных систем выделяет отдельную категорию ASI05 — Unexpected Code Execution: «агент генерирует или выполняет код/команды небезопасным способом, создавая возможности для удалённого исполнения кода, побегов из sandbox и эксфильтрации данных» [5].

Три реальных сценария, где что-то пошло не так

Сценарий 1: malicious README. Исследователи (arXiv, сентябрь 2025) задокументировали атаки, при которых вредоносные инструкции внедрялись в файлы конфигурации (.cursorrules, CLAUDE.md, .copilotinstructions). При открытии проекта AI-редактор автоматически загружал эти файлы и выполнял инструкции из них. Зафиксированы попытки запустить команду curl для изменения ~/.bashrc — фактически постоянная закладка в shell-конфигурацию [6].

Сценарий 2: rm -rf от Cursor. Пользователи форума Cursor сообщали, что агент пытался выполнить rm -rf / в ходе обычной работы с кодом. К моменту, когда это было замечено, критические данные были удалены [6].

Сценарий 3: CVE-2025-54135 в Cursor. В Cursor была обнаружена уязвимость, позволявшая через indirect prompt injection в конфигурационных файлах MCP-сервера добиться remote code execution без подтверждения пользователем [7]. Аналогичную уязвимость Trail of Bits нашли в Claude Code: CVE-2025-54795 — command injection в CLI-агенте [8].

В тестовой среде (AIShellJack framework, сентябрь 2025) успешность атак через prompt injection в режиме auto-execution составила от 66,9 до 84,1% [9]. Это не теоретические показатели — это воспроизводимые результаты на реальных инструментах.

Почему стандартные инструменты безопасности это не замечают

EDR и традиционный мониторинг не настроены на такой паттерн: легитимный процесс (агент) вызывает легитимные команды терминала с правами пользователя-разработчика. Никакого повышения привилегий, никакой аномалии в сигнатурах — просто curl, rm, git push от имени того, кому это обычно и позволено.

Часть 2. Архитектура доступа: от максимального к минимально необходимому

Принцип: обращайтесь с AI-агентом как с внешним подрядчиком

OWASP и ведущие исследователи сформулировали это одинаково: к AI-агенту нужно применять те же контроли, что и к внешнему подрядчику — минимальные привилегии, обязательный code review, полный аудит-лог, строгие ограничения доступа к данным [1]. Агент не является кем-то, кому следует доверять только потому, что он «ваш» и запущен на вашей машине.

Уровни изоляции (от слабого к сильному)

Уровень 0: никакой изоляции, YOLO mode. --dangerously-skip-permissions или аналог в Cursor без контейнера. Агент работает с правами пользователя-разработчика, имеет доступ к ~/.ssh, ~/.aws, .env, всему репозиторию, всей файловой системе. Допустимо только для экспериментов на одноразовой VM или внутри изолированного DevContainer — не на рабочей машине.

Уровень 1: allowlist/denylist на уровне инструмента. Claude Code поддерживает явное управление разрешениями через allowedTools и disallowedTools. Ключевые правила [10]:

Deny-правила всегда имеют приоритет над allow-правилами, независимо от порядка.
allowedTools только предварительно одобряет перечисленные инструменты; для неперечисленных управление переходит к permissionMode.
Паттерн Bash(git ) разрешает только git-команды; Bash(rm ) — заблокировать явно.
Для «заблокированного агента»: использовать allowedTools совместно с permissionMode: "dontAsk" — всё, что не в allowlist, будет отклонено, а не спрошено.

Пример минимального .claude/settings.json для backend-проекта:

{
  "permissions": {
    "allowedTools": [
      "Read",
      "Write(src/**)",
      "Bash(git *)",
      "Bash(npm test)",
      "Bash(npm run lint)"
    ],
    "deny": [
      "Read(.env*)",
      "Read(~/.ssh/**)",
      "Write(production.config.*)",
      "Bash(rm *)",
      "Bash(sudo *)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

Важное ограничение: allowlist не спасает от shell-буилтинов. CVE-2026-22708 (NomShub) показала, что встроенные команды shell — export, cd, eval — обходят allowlist, поскольку парсер отслеживает только внешние исполняемые файлы [11]. Это означает, что только allowlist без контейнерной изоляции не является достаточной мерой.

Уровень 2: встроенный sandbox Claude Code. Anthropic запустил собственный sandbox runtime (октябрь 2025) на основе OS-level primitives — Linux bubblewrap и macOS Seatbelt [4]. Он обеспечивает:

Файловую изоляцию: доступ только к текущему рабочему каталогу.
Сетевую изоляцию: только через проксирующий unix-domain socket, выход только на явно одобренные хосты.

По данным Anthropic, встроенный sandbox сокращает количество permission-промптов на 84% при сохранении уровня безопасности [4]. Оба вида изоляции необходимы одновременно: без сетевой изоляции скомпрометированный агент может утечь ~/.ssh-ключи; без файловой изоляции — выйти из сети и получить полный доступ к системе.

Важное предупреждение: разрешение unix-сокетов через allowUnixSockets может открыть доступ к /var/run/docker.sock, что фактически даёт агенту доступ к host-системе [4]. Сокеты для whitelist должны быть проверены явно.

Уровень 3: DevContainer / Docker Sandbox. Наиболее рекомендуемый подход для продакшн-команд. Trail of Bits, Anthropic и Docker публично рекомендуют этот сценарий [12, 13, 14]:

Агент работает внутри контейнера и не имеет доступа к ~/.ssh (ssh-agent socket пробрасывается отдельно — ключевой материал остаётся на хосте), ~/.aws, ~/.claude вне контейнера.
Монтируются только нужные директории проекта — не весь $HOME.
Исходящий трафик ограничивается через iptables до конкретного allowlist: api.anthropic.com, github.com, registry.npmjs.org, pypi.org.
Если что-то пошло не так — только контейнер, не хост [12].

Docker опубликовал Docker Sandboxes — microVM-based изоляцию специально для coding agents (январь 2026). В феврале 2026 вышел Docker AI Governance: централизованный контроль над тем, что агент может исполнять, к каким сетям подключаться и какие MCP-инструменты вызывать [14].

Cursor использует аналогичную архитектуру: background agents работают в Docker-контейнерах на AWS VM, что даёт inherent-изоляцию от локальной среды разработчика [15]. Однако на локальной машине — только если разработчик настроил devcontainer самостоятельно.

Часть 3. MCP-серверы — новая поверхность supply chain атаки

Что такое tool poisoning и почему это хуже prompt injection

С появлением Model Context Protocol (MCP) — стандарта для подключения агентов к внешним инструментам и источникам данных — возник новый класс атак. Tool poisoning отличается от прямого prompt injection структурой вектора [16]:

Prompt injection — это проблема валидации входных данных: пользователь подал что-то, приложение не обработало.
Tool poisoning — это supply chain проблема: серверные метаданные, на которые агент опирается для discovery инструментов, написаны кем-то, кому агент никогда явно не доверял.

Когда агент подключается к MCP-серверу, он делает вызов tools/list и получает массив дескрипторов инструментов — name, description, JSON-schema параметров. Описания написаны на естественном языке. Модель читает их и решает, как использовать инструменты. Атакующий, контролирующий MCP-сервер, может написать в описание инструмента директивы, которые модель исполнит как инструкции — без какой-либо санитизации и с полными ambient-правами агента [16].

Задокументированные инциденты

В мае 2025 через официальную GitHub MCP-интеграцию атакующие создавали вредоносные GitHub-issues в публичных репозиториях. Поскольку разработчики часто настраивают GitHub MCP с Personal Access Token, дающим доступ ко всем репозиториям, poisoned issue инструктировал агента эксфильтровать данные из приватных репозиториев в публичный [17].

Отдельный инцидент: пакет, маскирующийся под легитимный Postmark MCP-сервер, направлял каждое исходящее письмо BCC атакующим — внутренние меморандумы, сброс паролей, счета [17].

В феврале 2026 OWASP зафиксировал систематическое заражение реестра ClawHub (маркетплейс для OpenClaw-агентов): 5 из 7 самых скачиваемых skills на пике заражения были подтверждённым malware [3].

Trend Micro обнаружил 492 MCP-сервера, открытых в интернет без аутентификации [18].

Минимальный контроль MCP-инфраструктуры

Ведите явный approved inventory MCP-серверов и принудительно применяйте его в runtime, не только при деплое.
Пинуйте версии серверов; мониторьте изменения между деплоями.
Проводите аудит дескрипторов инструментов на скрытые промпты, избыточные схемы и ссылки на внешние эндпоинты.
Обращайтесь с любым динамически загружаемым источником инструментов так же, как с third-party зависимостью в production-кодовой базе — потому что это оно и есть [19].
MCP-разрешения управляются через отдельный раздел mcpServers в settings.json, а не через механизм allowedTools [20].
Все данные, возвращаемые MCP-серверами, рассматривайте как untrusted input — санитизируйте до передачи модели.

Часть 4. Практический чек-лист: что настроить до того, как агент запустит первую команду

Для разработчика

Запускать агента только из директории проекта, а не из $HOME.
Настроить .claude/settings.json с явным allowlist команд под конкретный проект — не использовать глобальный unlimited Bash.
Никогда не монтировать ~/.ssh, ~/.aws, .env* внутрь контейнера с агентом.
Для работы с незнакомым или потенциально ненадёжным репозиторием — использовать devcontainer или Docker sandbox, даже для ревью.
Включить network isolation в Claude Code sandbox; добавить в excludedCommands команды, несовместимые с sandbox (например, docker).
Проверять, что allowUnsandboxedCommands выставлен в false в production-сценариях.
Периодически читать аудит-лог: что агент реально запускал за последнюю сессию.

Для Tech Lead / команды

Добавить .claude/settings.json в репозиторий как часть project configuration — вся команда использует одинаковые настройки с первого дня [20].
Определить политику: какие команды требуют human approval, какие — нет.
Запретить bypassPermissions (YOLO mode) без контейнерной изоляции на уровне policy.
Ввести approval workflow для изменений в allowedTools.
Требовать явный ревью PR, созданных агентом, перед merge — функционально работает ≠ безопасно.
Регулярно обновлять Cursor и Claude Code: в 2025 году только для Cursor было выпущено 7 CVE [11].

Для AppSec / DevSecOps

Включить audit logging всех команд, выполненных агентом: создать observability layer поверх агентных сессий.
Добавить behavioral monitoring: alert на девиации от ожидаемых паттернов использования инструментов.
Подготовить kill switch: возможность мгновенно прекратить работу агента при аномальном поведении.
Провести threat modeling для агентного стека: какие MCP-серверы подключены, с какими правами, к каким данным есть доступ.
Добавить агентный код (CLAUDE.md, .cursorrules, settings.json) в scope code review.
Периодически проводить red-team testing: имитация goal override через prompt injection в конфигурационных файлах.

Часть 5. Решения для команд: от встроенных механизмов к дополнительному контролю

Что уже есть в Claude Code

Claude Code работает по permission-based модели: по умолчанию read-only, большинство операций требуют явного подтверждения [4]. Структура контроля включает [10]:

Managed settings: организационные политики, которые пользователь не может переопределить — через server-managed settings, MDM/OS-level policies или файловые managed settings.
Project settings (.claude/settings.json): настройки уровня репозитория.
User settings (~/.claude/settings.json): пользовательский уровень.
Session flags: --allowedTools, --disallowedTools для одноразовых сессий.

Иерархия: deny на любом уровне нельзя отменить на другом. Deny в managed settings не переопределяется через --allowedTools. Deny в project settings имеет приоритет над user settings [10].

Что уже есть в Cursor

Cursor в начале 2026 года выкатил agent sandboxing на macOS, Linux и Windows: sandbox agents запускаются внутри контролируемых границ и поднимают permission request только при необходимости выйти за них — чаще всего для интернет-доступа. По данным Cursor, это сократило количество developer interruptions на 40% по сравнению с несandboxed-режимом [21].

Для enterprise NVIDIA Red Team рекомендует три дополнительных контроля поверх встроенного sandbox: fresh manual approval для каждого действия, нарушающего default-deny isolation; secret injection для минимально необходимых credentials под конкретную задачу; lifecycle management для предотвращения накопления secrets и artecfacts [21].

Ключевое замечание по Cursor: отключение auto-run (YOLO mode) — самая важная единственная мера безопасности [11]. CVE-2026-22708 (NomShub) показала детерминированный побег из sandbox через shell builtins — export, cd, eval — поскольку парсер allowlist отслеживает только внешние бинари.

Дополнительный контроль через HighVibe

Изоляция sandbox и allowlist команд решают вопрос execution control: что агент может запускать. Но есть другой вопрос — что агент фактически написал, прежде чем это попало в PR и ушло в релиз.

AI-агент с доступом к терминалу часто работает в batch-режиме: редактирует несколько файлов, меняет конфиги, обновляет зависимости, пушит ветку. PR может содержать десятки изменений. Дифы дочитывают не до конца. Новая или транзитивная зависимость приезжает незаметно — как в истории с Supabase Cursor Agent в 2025, где агент с привилегированным service-role доступом обработал пользовательский input как команды и утёк integration tokens [22].

HighVibe — дополнительный слой контроля до merge и релиза. Он анализирует конкретное изменение: код, конфиги, служебные файлы, новые и обновлённые зависимости, контекст релиза. Даёт короткий понятный ответ для команды — можно ли безопасно принять именно это изменение сейчас, а не ещё один длинный security-отчёт, который не помогает быстро понять, что действительно критично. highvibe.dev

Часть 6. Типичные ошибки и как их избежать

Ошибка 1: монтирование $HOME целиком. Разработчик монтирует всю домашнюю директорию в devcontainer для удобства. Агент получает доступ к ~/.ssh, ~/.aws, ~/.gnupg, всем .env-файлам. Даже если агент не скомпрометирован, MCP-сервер в той же сессии может получить доступ к этим данным. Правило: монтировать только директорию проекта.

Ошибка 2: доверие к bypassPermissions в CI/CD. --dangerously-skip-permissions разрабатывался для trusted local development или controlled CI/CD-пайплайнов с дополнительными safeguards — max_turns, timeout_minutes [23]. Без контейнерной изоляции в CI/CD это полностью открытый терминал с правами ci-пользователя. Агентный код в CI должен работать в изолированном контейнере или через управляемый Docker Sandbox.

Ошибка 3: использование bypassPermissions совместно с allowedTools. allowedTools не ограничивает bypassPermissions. Если permissionMode: "bypassPermissions" — все инструменты одобрены, включая Bash, Write, Edit, независимо от allowedTools [10]. Это ловушка, которая выглядит как безопасная конфигурация, но не является ею.

Ошибка 4: игнорирование MCP-разрешений в allowlist. MCP-разрешения управляются через отдельный раздел mcpServers, не через allowedTools/Bash-механизм. Разработчики, которые аккуратно настроили Bash-allowlist, могут забыть про MCP — оставив серверы с неограниченными правами [20].

Ошибка 5: shadow AI-инфраструктура. Разработчики устанавливают Claude Code или Cursor локально, подключают к production-системам, работают без audit trails или access controls. Это зеркало shadow IT десятилетней давности — но с существенно более высоким риском [24].

Ошибка 6: отсутствие kill switch. Нет возможности мгновенно остановить агента при аномальном поведении. Агент, получивший poisoned prompt через MCP-сервер, может выполнить цепочку из 10+ действий быстрее, чем человек успеет среагировать [9].

Часть 7. Будущее: что меняется прямо сейчас

NIST (январь 2026) запустил официальный Request for Information по безопасности AI-агентных систем: регулятор ищет best practices и рекомендует считать agent hijacking, backdoor attacks и другие эксплойты системными рисками для публичной безопасности [25].

OWASP в рамках проекта Agentic Skills Top 10 фиксирует: AI agent skill ecosystem находится под активной атакой начиная с Q1 2026. Экосистема плагинов и скиллов для AI-агентов повторяет ранний npm — без централизованной системы безопасности, без mandatory supply chain controls, без стандартов провенанса [3].

Среди практических трендов, которые стоит отслеживать:

Стандартизация workload identity для AI-агентов: переход от static API keys к certificate-based, short-lived credentials (SPIFFE/SVID, Google Autonomous Workload Identity). Okta зафиксировала снижение кражи credentials на 92% при использовании 300-секундных токенов вместо 24-часовых [26].
Intent gates и Policy Enforcement Points: middleware, который верифицирует намерение агента до исполнения действия — аналог firewall, но на уровне семантики инструментов.
Behavioral analytics для агентов: anomaly detection, настроенный на паттерны использования инструментов, а не только сетевые сигнатуры.
Mandatory human oversight для destructive actions: индустрия движется к hardcoded human-in-the-loop для действий с необратимыми последствиями — удаление данных, изменение production-конфигов, push в защищённые ветки.

Заключение: что делать прямо сейчас

Терминальный доступ для AI-агентов — это не вопрос «давать или нет». Команды, которые уже используют Claude Code, Cursor Agent и аналоги, работают быстрее. Вопрос в том, выстроен ли контроль.

Минимальный baseline, который стоит внедрить немедленно:

Добавить .claude/settings.json с explicit deny-листом опасных команд в каждый репозиторий.
Включить встроенный sandbox Claude Code (filesystem + network isolation).
Для работы с незнакомым или недоверенным кодом — запускать агента только в DevContainer или Docker Sandbox.
Запретить bypassPermissions без контейнерной изоляции на уровне команды.
Ввести code review для PR, созданных агентом, как обязательный шаг перед merge.
Аудит MCP-серверов: approved inventory, pin версий, проверка дескрипторов инструментов.

AI ускорил разработку. Контроль изменений не успел вырасти с той же скоростью. «Работает» по-прежнему не значит «безопасно для merge и релиза» — особенно когда инструмент, который пишет и запускает код, может быть перенаправлен через содержимое файла в вашем же репозитории.

Источники

[1] arXiv — "Prompt Injection Attacks on Agentic Coding Assistants: A Systematic Analysis" — https://arxiv.org/html/2601.17548v1

[2] Glean — "Best practices for AI agent security in 2025" — https://www.glean.com/perspectives/best-practices-for-ai-agent-security-in-2025

[3] OWASP GenAI Security Project — "OWASP Top 10 for Agentic Applications 2026" — https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[4] Anthropic Engineering — "Making Claude Code more secure and autonomous" — https://www.anthropic.com/engineering/claude-code-sandboxing

[5] F5 — "OWASP Top 10 for Agentic Applications: ASI05 Unexpected Code Execution" — https://www.f5.com/glossary/owasp-top-10-for-agentic-ai-applications

[6] arXiv — "Your AI, My Shell: Demystifying Prompt Injection Attacks on Agentic AI Coding Editors" — https://arxiv.org/html/2509.22040v1

[7] arXiv — "Are AI-assisted Development Tools Immune to Prompt Injection?" — https://arxiv.org/html/2603.21642v1

[8] Trail of Bits Blog — "Prompt injection to RCE in AI agents" — https://blog.trailofbits.com/2025/10/22/prompt-injection-to-rce-in-ai-agents/

[9] LastPass Blog — "Prompt Injection Attacks in 2025: When Your Favorite AI Chatbot Listens to the Wrong Instructions" — https://blog.lastpass.com/posts/prompt-injection

[10] Claude Code Docs — "Configure permissions" — https://code.claude.com/docs/en/permissions

[11] HowToHarden — "Cursor Hardening Guide" — https://howtoharden.com/guides/cursor/

[12] GitHub / Trail of Bits — "claude-code-devcontainer: Sandboxed devcontainer for running Claude Code" — https://github.com/trailofbits/claude-code-devcontainer

[13] CodeWithAndrea — "How to Safely Run AI Agents Like Cursor and Claude Code Inside a DevContainer" — https://codewithandrea.com/articles/run-ai-agents-inside-devcontainer/

[14] Docker — "Run Claude Code with Docker: Local Models, MCP, Sandboxes" — https://www.docker.com/blog/run-claude-code-with-docker/

[15] Agent Safehouse — "Cursor Agent: Sandbox Analysis Report" — https://agent-safehouse.dev/docs/agent-investigations/cursor-agent

[16] TrueFoundry — "MCP Tool Poisoning (CVE-2025-54136): A Structural Vulnerability in Agent Context" — https://www.truefoundry.com/blog/blog-mcp-tool-poisoning-gateway-defense

[17] Medium / InstaTunnel — "Securing MCP Servers: The 2026 Guide to AI Tool Tunneling" — https://medium.com/@instatunnel/securing-mcp-servers-the-2026-guide-to-ai-tool-tunneling-aafa113b08db

[18] CyberDesserts Blog — "AI Agent Security Risks 2026: MCP, OpenClaw & Supply Chain" — https://blog.cyberdesserts.com/ai-agent-security-risks/

[19] arnav.au — "Securing Agentic AI: The Architect's Practical Framework for 2026" — https://arnav.au/2026/05/13/securing-agentic-ai-the-architects-practical-framework-for-2026/

[20] ClaudeLab — "Claude Code Tool Permissions: A Practical Guide to Custom Allow/Deny Policies" — https://claudelab.net/en/articles/claude-code/claude-code-tool-permissions-custom-policy-guide

[21] adwaitx.com — "Cursor AI Agent Sandboxing Explained: How It Works in 2026" — https://www.adwaitx.com/cursor-ai-agent-sandboxing-explained/

[22] Practical DevSecOps — "MCP Security Vulnerabilities: How to Prevent Prompt Injection and Tool Poisoning" — https://www.practical-devsecops.com/mcp-security-vulnerabilities/

[23] Steve Kinney — "Claude Code Permissions" — https://stevekinney.com/courses/ai-development/claude-code-permissions

[24] MintMCP — "How to Sandbox Claude Code: Docker, VMs & Container Security Guide" — https://www.mintmcp.com/blog/sandbox-claude-code

[25] NIST / Federal Register — "Request for Information Regarding Security Considerations for Artificial Intelligence Agents" — https://www.federalregister.gov/documents/2026/01/08/2026-00206/request-for-information-regarding-security-considerations-for-artificial-intelligence-agents

[26] Prefactor — "5 Best Practices for AI Agent Access Control" — https://prefactor.tech/blog/5-best-practices-for-ai-agent-access-control