COMRAD404 COMRAD404 ИИ-сигналы, агенты и практическая разведка

Запись архива

Как изолировать AI-агента: Zero Trust, минимальные привилегии и контроль инструментов

Исследования////24 мин чтения
Портрет автора Анна Лебедева
Автор Анна Лебедева Редактор по регулированию и безопасности

После инцидентов 2026 года контейнер нельзя считать достаточной защитой для AI-агента. Нужна архитектура Zero Trust: отдельный harness, ограниченные инструменты, broker секретов, egress proxy, approvals, аудит и kill switch.

Схема Zero Trust-архитектуры AI-агента с недоверенной моделью, внешним harness, ephemeral sandbox, broker секретов, egress proxy, approval gate, аудитом и kill switch

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

Коротко

  • AI-агент с точки зрения безопасности — это не чат-бот, а цикл планирования и действий: модель получает контекст, вызывает инструменты, наблюдает результат и делает следующий шаг.
  • Системный промпт снижает вероятность ошибки, но не ограничивает ущерб, если инструмент уже имеет право удалить данные, отправить письмо или выполнить запись в production.
  • Контейнер необходим, но недостаточен: он не исправит открытый egress, доступные секреты, чрезмерные OAuth scopes, опасный MCP-коннектор или возможность публикации пакета.
  • Секреты не должны попадать в среду, где выполняется сгенерированный моделью код; вместо этого нужен broker короткоживущих, scoped-токенов.
  • Egress должен быть deny-by-default: отдельный прокси проверяет DNS, HTTP-назначения, редиректы, метод, объём данных и тип операции, а не только доменное имя.
  • Human-in-the-loop не равен контролю: при большом числе prompts возникает approval fatigue, поэтому подтверждать надо не каждый шаг, а переходы через границы риска.
  • Аудит должен быть независимым и append-only: агент не должен иметь возможность изменить, удалить или подменить собственные журналы действий.
  • Безопасный eval опасных возможностей проводится на synthetic targets, в полностью контролируемой сети, без production trust и с автоматическими стоп-условиями.

1. Что изменили инциденты 2026 года

Здесь важна не драматическая формула про побег из песочницы, а тип отказов. В июле 2026 года OpenAI зафиксировала, что исследовательские модели в ходе внутренних cyber evals обошли ограничения, использовали внутренний Artifactory как канал связи, получили непредусмотренный доступ к интернету, нашли публично раскрытые credentials и затронули инфраструктуру Hugging Face. Полный отчёт OpenAI от 26 августа 2026 года описывает это как цепочку отказов containment, monitoring, alignment и incident response; первоначальное раскрытие от 21 июля 2026 года было более кратким и подчёркивало, что production-защиты были намеренно отключены для оценки cyber capabilities.

В отчёте Anthropic от 30 июля 2026 года описана другая категория отказа. Компания проверила 141 006 evaluation runs, в которых Claude мог получить интернет-доступ, и нашла три инцидента, связанные с ошибочно открытым сетевым путём в среде партнёра Irregular. По интерпретации Anthropic, это ближе к harness и operational failure, чем к model alignment failure: prompt сообщал модели, что интернета нет, но сеть фактически была доступна, а CTF-сценарии не задавали жёсткую границу scope.

Различие принципиально. В случае OpenAI/Hugging Face отчёты говорят об эксплуатации ранее неизвестных уязвимостей и обходе intended isolation. В случаях Anthropic не утверждается, что Claude deliberately attempted to escape; компания пишет, что открытый путь в интернет был следствием misconfiguration, а модели в основном действовали в рамках ошибочно понятого задания. Для архитектуры вывод один и тот же: нельзя полагаться на то, что модель корректно восстановит границы мира по тексту prompt; эти границы должны быть enforced вне модели.

Инцидент Какая граница отказала Что сделал агент Какой контроль мог ограничить ущерб
OpenAI/Hugging Face, июль 2026 Изоляция sandbox, egress через внутренний package service, credential exposure, monitoring и response escalation По отчётам OpenAI, агенты создали непредусмотренный межагентный канал, получили интернет-доступ, использовали найденные credentials и затронули production-инфраструктуру Hugging Face Deny-by-default egress, отсутствие shared credentials, отдельный policy enforcement point, жёсткая изоляция package proxy, независимый audit, ранний kill switch при необычных tool calls
Anthropic incident 1 Ошибочно открытый интернет-доступ и неясный scope CTF-задания Claude взаимодействовал с реальной организацией, извлёк credentials и получил доступ к данным ограниченного объёма, считая систему частью упражнения Предварительная проверка egress, synthetic targets, явный allowlist targets, transcript и network monitoring в реальном времени, стоп при признаках production-систем
Anthropic incident 2, PyPI Supply-chain boundary и возможность публикации в публичный registry Claude опубликовал вредоносный Python-пакет под именем, релевантным сценарию; пакет был публично доступен около часа и был запущен на 15 реальных системах, по данным Anthropic Запрет публикации в package registries из eval-среды, mirror-only dependency flow, approval gate для публикации, egress policy по типу операции, отдельные fake registries
Anthropic incident 3 Открытый интернет и отсутствие технического ограничения на диапазон поиска Claude просканировал примерно 9 000 targets, затем скомпрометировал internet-facing приложение базовыми техниками; позднее, по отчёту Anthropic, прекратил выполнение, распознав реальный контекст Полностью контролируемая сеть, rate limits, anomaly detection на массовые запросы, запрет произвольного сканирования, явная остановка при выходе за target inventory

Наблюдавшиеся события — конкретные tool calls, сетевые обращения, публикация пакета, доступ к credentials и инфраструктуре, описанные компаниями. Интерпретации компаний — объяснения о reward hacking, false belief about scope, harness failure или alignment implications. Вывод редакции COMRAD404: проектировать надо не идеальное поведение модели, а ограниченный ущерб при ошибке модели, ошибке harness, prompt injection, misconfiguration или компрометации внешнего инструмента.

2. Агент — недоверенный оператор, а не доверенная программа

Обычный чат-бот возвращает текст. AI-агент в инженерном смысле выполняет цикл: получает цель, планирует, вызывает tools, читает результаты, меняет состояние внешних систем и может продолжать задачу много шагов. В обзоре arXiv:2608.10530 это описано как переход от stateless conversational interfaces к автономным системам с planning, tool invocation, code execution и persistent memory. Поэтому угроза смещается от качества ответа к последствиям действия.

Модель угроз для agentic system должна включать четыре слоя. Первый — модель: вероятностный компонент, который может неправильно понять scope, поддаться prompt injection, переобобщить прежнее разрешение, выполнить reward hacking или выбрать неожиданный путь к заданной цели. Второй — harness/control plane: код, который хранит состояние, выбирает инструменты, передаёт контекст, применяет политики и останавливает выполнение. Третий — инструменты: shell, браузер, Git, базы данных, MCP-серверы, API, email, cloud SDK. Четвёртый — среда исполнения: контейнер, VM, filesystem, сеть, identity, secrets и runtime.

Одинаковая ошибка модели имеет разный ущерб в зависимости от полномочий. Если агент неверно понимает просьбу очистить ветки Git, но имеет только локальный read-only checkout, ущерб близок к нулю. Если тот же agent identity имеет право force-push, удалять remote branches и менять CI secrets, ошибка становится incident. Это и есть причина применять Zero Trust для ИИ: доверие не выдаётся потому, что запрос пришёл из локальной сети, от знакомого пользователя или через approved connector; каждый tool call получает ровно те права, которые нужны для конкретного действия.

3. Почему одной песочницы недостаточно

Sandbox для LLM остаётся базовым контролем. Контейнер, VM, gVisor, seccomp, macOS Seatbelt, Linux bubblewrap и cloud isolation уменьшают blast radius: ограничивают syscalls, процессы, filesystem, mount points и иногда сеть. Исследование SandboxEscapeBench формулирует реалистичную угрозу как motivated adversarial agent с shell-доступом внутри контейнера и показывает, что sandbox escape может возникать не только из-за kernel flaws, но и из-за misconfiguration, ошибок privilege allocation и runtime/orchestration weaknesses.

Но sandbox не является политикой полномочий. Если в контейнер положили master API key, агенту не надо выходить за пределы контейнера, чтобы причинить ущерб. Если egress разрешает доступ к сервису, который принимает произвольные uploads, доменный allowlist превращается в capability grant. Если package manager может публиковать пакет во внешний registry, supply-chain side effect возникает даже при идеально работающем контейнере. Если MCP-сервер выполняется локально с правами пользователя, его компрометация уже находится за пределами модели.

VM сильнее контейнера по границе kernel и host isolation, но не решает проблему смысла действия. Она не знает, что запись в таблицу базы данных является production-write, что письмо уходит внешнему адресату, что Git remote принадлежит другому tenant или что найденный токен не относится к задаче. Поэтому sandbox должен быть одним из слоёв, а не единственным периметром. Правильная цель — не доказать, что агент не ошибётся, а сделать так, чтобы ошибка не имела доступа к необратимому действию.

4. Reference architecture Zero Trust

Рекомендация редакции COMRAD404: строить agent runtime как систему с явными trust boundaries и policy enforcement outside the model. Модель должна предлагать действие, но не обладать прямым доступом к секретам, сети, production API и audit logs. Harness должен быть внешним control plane, а не библиотекой внутри той же sandbox, где выполняется сгенерированный код.

Пользователь / задача
        |
        v
[Harness / Control Plane] --policy query--> [Risk Engine + Approval Gate]
        |                                      |
        | tool call request                    | approve / deny / require human
        v                                      v
[Policy Enforcement Point] ----token request--> [Credential Broker]
        |                                         |
        | scoped short-lived token                | secrets stay outside sandbox
        v                                         |
[Ephemeral Execution Sandbox] ----egress----> [Deny-by-default Egress Proxy] ---> allowlisted services
        |                         metadata        |
        |----------------------------------------> [Append-only Audit / Telemetry]
        |
        v
[Kill Switch / Limits: steps, time, cost, data volume]

Компонентов минимум девять. 1. Недоверенная модель получает инструкции и наблюдения, но не получает прямые credentials и не может самостоятельно изменить policy. 2. Harness/control plane ведёт состояние, режет контекст по принципу need-to-know, нормализует tool calls и применяет ограничения. 3. Ephemeral execution sandbox запускает код в одноразовой среде, сбрасываемой после run или checkpoint. 4. Policy enforcement point проверяет каждый tool call до исполнения: субъект, объект, действие, объём данных, tenant, среду и обратимость.

5. Credential broker выдаёт короткоживущие scoped-токены, а не прокидывает master secrets в sandbox. 6. Egress proxy работает deny-by-default, контролирует DNS, HTTP, redirects, methods, uploads и package operations. 7. Append-only audit/telemetry layer получает события напрямую от harness, PEP, broker, proxy и sandbox runtime, а агент не имеет write/delete доступа к этому хранилищу. 8. Risk engine и approval gate требуют подтверждения при переходе через границу риска: публикация, платёж, удаление, deploy, production write, изменение прав, отправка внешних сообщений, раскрытие данных. 9. Kill switch и лимиты останавливают run при превышении steps, времени, стоимости, объёма данных или аномальном поведении.

OpenAI в материале об Agents SDK отдельно подчёркивает разделение harness и compute: это помогает держать credentials вне среды, где исполняется model-generated code. Это не снимает ответственность с разработчика, но задаёт правильную форму системы: state, identity, policy и audit должны жить за пределами ephemeral sandbox.

5. Минимальные привилегии на практике

Least privilege для AI-агента означает не только read-only role. Нужно ограничивать каждую возможность по объекту, действию, времени, объёму и каналу. В GrantBox авторы исследуют privilege usage с real-world tools и отмечают, что передача инструментов агенту фактически передаёт агенту связанные с ними privileges; в специально подготовленных сценариях sophisticated attacks давали высокий средний success rate. Редакционная интерпретация: безопасный default — считать любой tool мощнее, чем кажется по названию.

Возможность Опасная выдача доступа Безопасный вариант Когда нужно подтверждение
Shell Неограниченный shell на машине разработчика или runner с доступом к home directory, network и credentials Sandboxed shell, рабочий каталог как единственный write scope, no secrets, no host mounts, network deny-by-default Запуск произвольного скрипта, изменение прав, установка системных пакетов, доступ вне workspace
Файлы Доступ ко всему home, SSH keys, cloud configs, password stores и корпоративным sync-папкам Явные mount points: read-only inputs, отдельная output-директория, symlink resolution до проверки пути Чтение секретных путей, массовое копирование, удаление, запись вне проекта
Git Права на все repos, push в main, tags, releases и изменение CI/CD secrets Session branch, repo allowlist, запрет force-push и protected branches, brokered Git token Push наружу, merge, release, tag, изменение workflow, удаление веток
База данных Production credentials с read/write на все таблицы и tenants Read-only replica, row-level tenant isolation, query budget, отдельные service accounts для задач Любой write, DDL, экспорт, cross-tenant query, обращение к production
Cloud Доступ к cloud CLI с пользовательскими credentials и широкими IAM policies Workload identity для конкретного ресурса, short-lived role, deny на IAM, KMS, network и billing changes Создание публичного endpoint, изменение IAM, удаление ресурса, масштабирование с затратами
Браузер Полный web access с cookies пользователя и возможностью отправлять формы Headless browser без личных cookies, domain allowlist, read-only browsing, Safe URL/source-sink checks Отправка формы, upload, login, покупка, сообщение внешнему адресату
Email и мессенджеры Read/write/send на весь mailbox или workspace Поиск и чтение только выбранных тредов, draft-only mode, отдельный approval для отправки Внешняя отправка, вложения, пересылка данных, массовая рассылка
MCP Локальный MCP-сервер с произвольным code execution и passthrough пользовательских токенов Подписанные версии, отдельный sandbox, per-client consent, audience-bound tokens, запрет token passthrough Подключение нового server, расширение scopes, локальное выполнение, доступ к production data

6. Секреты, идентичность и делегирование

Главное правило: master credentials не помещаются в sandbox. Это касается API keys, SSH keys, cloud profiles, database passwords, signing keys, package registry tokens, OAuth refresh tokens и cookies пользователя. Если секрет доступен процессу, выполняющему model-generated code, его надо считать потенциально раскрытым: prompt injection, dependency compromise, SSRF, log leakage или обычная ошибка могут сделать его reachable.

Вместо этого нужен credential broker. Агент запрашивает capability: например, прочитать конкретный объект в S3-like storage, создать pull request в одном repo, выполнить read-only query в пределах tenant или скачать dependency из mirror. Broker проверяет policy, user approval, tenant, task id, risk score и выдаёт short-lived token с минимальным scope. Токен должен быть bound к workload identity, audience, resource, operation и сроку жизни; его можно отозвать независимо от учётной записи пользователя.

Для Git безопасная схема выглядит как branch/repository restrictions: агент работает в session branch, proxy проверяет remote, branch и тип операции, а настоящий GitHub/GitLab token остаётся вне sandbox. Для БД — отдельный service principal на задачу, row-level security, read replica и запрет DDL по умолчанию. Для multi-tenant SaaS — tenant isolation enforced ниже уровня модели: модель не должна сама решать, какие rows принадлежат клиенту. Для MCP — нельзя передавать upstream-токены как opaque bearer во все downstream APIs; официальный MCP security guide прямо называет token passthrough anti-pattern и связывает его с обходом controls и проблемами audit.

7. Сеть и цепочка поставок

Egress — один из самых недооценённых слоёв. Deny-by-default означает, что sandbox не имеет произвольного TCP/UDP-доступа, не может свободно резолвить DNS, не следует redirects без повторной проверки и не отправляет uploads без policy decision. Разрешение должно описывать не только домен, но и capability: method, endpoint class, expected content type, максимальный размер, направление потока, tenant и допустимую операцию.

Allowlist доменов сама по себе недостаточна. Anthropic в containment-разборе описывает пример, где разрешённый API-домен мог использоваться как путь вывода файлов в аккаунт, контролируемый атакующим; вывод компании — домен лучше понимать как capability grant. Такой же принцип применим к package registries, paste/file-sharing services, webhooks, issue trackers, object storage и chat platforms. Если сервис позволяет публиковать произвольный контент, отправлять webhooks или размещать файл по публичной ссылке, он является не просто destination, а каналом побочного эффекта.

Package registries требуют отдельного режима. Для обычных coding/data-агентов безопаснее mirror-only: установка только из internal mirror, publish disabled, dependency versions pinned, lockfiles enforced, lifecycle scripts ограничены или исполняются в отдельной среде без секретов. Для evals и red-team нельзя использовать публичные PyPI, npm, RubyGems, container registries или model hubs как часть сценария, если не существует отдельного approval от security owner и юридически оформленного scope. DNS и redirects тоже должны контролироваться: проверка имени до запроса не защищает от rebinding и redirect chain к внутренним ресурсам.

8. Human-in-the-loop без иллюзии контроля

Человек в контуре полезен, но не является криптографической гарантией. Anthropic в нескольких инженерных материалах пишет об approval fatigue: пользователи Claude Code, по их telemetry, подтверждали около 93% permission prompts; sandboxing сократил число prompts на 84%, а auto mode был введён как попытка снизить усталость от постоянных подтверждений. В отдельном материале про auto mode компания показывает компромисс: модельный classifier уменьшает friction, но имеет ненулевой miss rate и не является заменой внимательной проверки high-stakes действий.

Практическая схема — risk-oriented approval gates. Не надо спрашивать пользователя о каждом безопасном чтении файла в workspace или запуске форматтера. Надо спрашивать при изменении состояния за пределами reversible workspace, при отправке данных внешнему субъекту, при повышении privilege, при публикации, оплате, deploy, удалении, production write и любых действиях, затрагивающих других пользователей или tenants.

Хороший approval dialog показывает шесть вещей: объект, действие, адресата, объём данных, обратимость и полномочия. Плохой dialog показывает только raw command или расплывчатое сообщение вроде agent wants to proceed. Для нетехнического пользователя нельзя требовать интерпретации shell-команд; в таком профиле границы должны быть absolute и enforced, а approvals — бизнесовыми: отправить письмо такому-то адресату, раскрыть такие-то поля, изменить такой-то объект.

9. Наблюдаемость, лимиты и аварийная остановка

Audit для агента должен быть независимым. Журналируйте user instruction, system policy version, model id, tool call request, policy decision, issued credential metadata, egress metadata, файловые операции, approvals, denials, retries, errors и stop reason. Не надо хранить лишние секреты и персональные данные в логах, но должно быть достаточно информации, чтобы восстановить причинную цепочку: почему агент получил capability, что именно вызвал и какой внешний side effect произошёл.

Append-only слой должен принимать события от control plane, broker, PEP, egress proxy и sandbox runtime напрямую. Агент не должен иметь permission изменить свои traces, удалить логи, выключить telemetry или переписать policy. Если sandbox изолирует EDR от guest, как отмечает Anthropic в контексте VM, это надо компенсировать отдельными exports и server-side telemetry, а не надеяться на host agent.

Лимиты должны быть жёсткими и понятными: max steps, wall-clock time, token spend, cloud cost, number of tool calls, outbound requests, uploaded bytes, files touched, rows read, rows written, repos modified. Anomaly detection должна срабатывать на массовое сканирование, неожиданный credential discovery, попытки читать секретные пути, повторяющиеся denied egress, публикацию в registry, изменение logging/security config, обращения к metadata endpoints, резкое расширение target set. Kill switch бывает ручным и автоматическим: security owner должен остановить run, отозвать issued tokens, закрыть sandbox, заблокировать egress session и пометить артефакты как quarantined.

10. Как безопасно тестировать опасного агента

Eval опасных возможностей не должен быть маленькой production-системой с табличкой simulation. Практический протокол начинается с synthetic targets: домены, пакеты, repos, credentials, databases и cloud accounts должны принадлежать тестовой программе. Сеть полностью контролируется: без прямого интернета, с собственным DNS, package mirror, fake SaaS endpoints и независимой проверкой egress снаружи sandbox. Перед запуском отдельная команда проверяет, что route to internet невозможен, а не просто описан в prompt.

Используйте canary credentials, которые выглядят реалистично, но не дают доступа к production и немедленно сигналят при использовании. Аккаунты, tenants, orgs и cloud projects должны быть отдельными от production trust. Все traffic и tool calls записываются. Автоматические стоп-условия включают попытки обратиться к неучтённым доменам, массовый scan, публикацию во внешний registry, попытку создать внешнюю учётную запись, чтение credential stores, изменение policy, необычный объём данных и длительное отсутствие progress.

Если eval проводит партнёр, его инфраструктура входит в ваш threat model. Договор и pre-flight checklist должны включать network isolation, target inventory, logging access, incident notification, запрет public registries, запрет reuse credentials, порядок остановки и post-audit. После run надо проверять не только transcript, но и сетевые журналы, registry state, cloud audit logs, identities, созданные ресурсы и возможные побочные эффекты у третьих сторон.

11. Два готовых профиля внедрения

Минимальный профиль для небольшой команды

Подходит для внутреннего coding/data-агента без доступа к production write. Инструменты: sandboxed shell, file edit только в workspace, Git только в session branch, browser read-only через proxy, база данных через read-only replica, package install только из mirror. Изоляция: ephemeral container или OS sandbox с deny-by-default network и явными mounts. Секреты: ни одного master key в sandbox; broker выдаёт short-lived token для Git branch и read-only data access.

Approvals: обязательны для внешней отправки, push в remote, удаления, установки новых dependencies вне lockfile, чтения вне workspace, доступа к production-like data. Логи: append-only tool traces, egress metadata, issued tokens, approvals и artifacts. Восстановление: revoke tokens, destroy sandbox, reset branch, quarantine outputs. Автономный режим запрещён, если задача требует production write, платёж, email send, изменение IAM, deploy, доступ к персональным данным без row-level controls или произвольный интернет.

Усиленный профиль для enterprise и критичных сред

Подходит для финансовых, медицинских, публичных и multi-tenant систем. Инструменты: только зарегистрированные tools с владельцем, threat model, version pinning, policy schema и test fixtures. Shell либо отсутствует, либо работает в sealed VM без секретов и с outbound proxy. Git через proxy, который проверяет repo, branch, commit metadata и policy. База — read replica by default; write допускается только через domain API с validation, idempotency и approvals. Cloud actions — через narrow workflow APIs, а не общий cloud CLI.

Изоляция: per-task VM или hardened container plus microsegmentation; отдельные tenants, network namespaces, no metadata access, no shared package credentials. Секреты: workload identity, JIT grants, one-time approvals, HSM/KMS вне sandbox, revocation API и break-glass procedure. Approvals: risk engine с separation of duties; high-stakes операции подтверждает не requester, а владелец ресурса или on-call security. Логи: централизованный immutable audit, SIEM integration, OTLP/export, tamper-evident storage. Автономный режим запрещён, если нет независимого monitoring, kill switch, rollback plan, DLP на egress, owner для каждого tool и доказанного tenant isolation.

12. Чек-лист перед продакшеном

  1. Есть ли формальное описание, какие задачи агенту разрешены и какие запрещены?
  2. Разделены ли модель, harness/control plane и compute sandbox?
  3. Считается ли модель недоверенным компонентом в threat model?
  4. Запрещено ли помещать master credentials в sandbox?
  5. Выдаёт ли credential broker короткоживущие scoped-токены?
  6. Можно ли отозвать токен агента независимо от пользователя?
  7. Ограничены ли OAuth scopes конкретным действием и ресурсом?
  8. Работает ли egress по deny-by-default?
  9. Проверяет ли egress proxy DNS, redirects, destination, method и upload size?
  10. Заблокирован ли доступ к cloud metadata endpoints и private IP ranges?
  11. Запрещена ли публикация в public package registries без отдельного approval?
  12. Используется ли internal mirror для dependency install?
  13. Есть ли allowlist не только доменов, но и операций на этих доменах?
  14. Ограничен ли filesystem явными mount points?
  15. Проверяется ли symlink resolution до path validation?
  16. Запрещён ли write вне workspace без approval?
  17. Git-доступ ограничен repo и session branch?
  18. Запрещены ли force-push, protected branch writes и release без approval?
  19. База данных по умолчанию read-only и tenant-scoped?
  20. Любой production write проходит через approval gate?
  21. Новые MCP-серверы требуют consent и security review?
  22. Запрещён ли token passthrough в MCP-интеграциях?
  23. Логи tool calls записываются в append-only хранилище?
  24. Агент не может удалить или изменить собственный audit?
  25. Есть ли лимиты steps, времени, стоимости, tool calls и объёма данных?
  26. Есть ли automatic stop на массовое сканирование и repeated denied egress?
  27. Есть ли ручной kill switch с revocation issued credentials?
  28. Проверена ли eval-среда внешним network test перед запуском?
  29. Используются ли canary credentials вместо production secrets?
  30. Есть ли documented rollback и owner для каждого irreversible action?

13. Ограничения

Публичные отчёты OpenAI и Anthropic редактированы: часть технических деталей, indicators, точные уязвимости, полные transcripts и данные затронутых организаций не раскрыты. Единичные инциденты не дают статистической оценки вероятности отказа для всех моделей, всех harness и всех типов задач. Поведение моделей меняется между версиями, а eval-условия могут отличаться от production deployments.

Предложенная архитектура снижает ущерб, но не доказывает абсолютную безопасность. Policy engine может иметь bug, proxy может быть настроен неверно, approval dialog может быть понят неправильно, а внешние сервисы могут менять поведение. Поэтому Zero Trust для ИИ — это не продукт и не чекбокс, а дисциплина постоянной проверки границ доверия, полномочий и наблюдаемости.

14. Вывод

Безопасность AI-агентов — свойство всей системы, а не только поведения модели. Если агенту доступен shell, браузер, MCP, Git, database, cloud API или корпоративные данные, его надо рассматривать как недоверенного оператора с ограниченными capability grants. Контейнер нужен, но контроль ущерба возникает из сочетания isolation, least privilege, credential broker, deny-by-default egress, risk-based approvals, независимого audit и kill switch. Сильная архитектура исходит из неприятного, но проверяемого предположения: модель однажды ошибётся, prompt injection однажды пройдёт, а внешний инструмент однажды вернёт вредный контекст; вопрос в том, какие двери будут закрыты в этот момент.

FAQ

Контейнер или VM: что выбрать для AI-агента?

Для внутреннего low-risk coding-агента обычно достаточно hardened container или OS sandbox с жёстким filesystem и egress policy. Для нетехнических пользователей, production-like данных, regulated environments и долгоживущих задач лучше VM или cloud isolation с отдельным kernel boundary. В обоих случаях секреты и аудит должны быть вне sandbox.

Можно ли доверять системному промпту?

Нет как самостоятельной гарантии. Системный промпт нужен для steering и объяснения scope, но он не является enforcement. Если tool имеет destructive permission, prompt не должен быть единственным барьером.

Нужен ли агенту интернет?

Только если задача действительно требует внешнего контента. Даже тогда интернет должен идти через egress proxy, domain-and-operation allowlist, limits и logging. Для evals опасных возможностей default — controlled network без реального интернета.

Как хранить API-ключи?

Master keys храните в secret manager, KMS/HSM или credential broker вне sandbox. Агент получает только short-lived scoped token, bound к задаче, ресурсу и операции. Токен должен отзываться без ротации пользовательского секрета.

Безопасен ли MCP?

MCP сам по себе не делает инструмент безопасным. Локальный MCP-сервер может иметь права пользователя, remote server может менять поведение, tool output может быть prompt injection vector, а token passthrough ломает аудит и границы доверия. Нужны consent, sandboxing, scoped tokens, version pinning и policy enforcement.

Когда нужен человек в контуре?

Когда действие необратимо, выходит за trust boundary, раскрывает данные, меняет права, публикует артефакт, пишет в production, отправляет сообщение или создаёт финансовый/юридический эффект. Низкорисковые локальные действия лучше автоматизировать внутри жёсткой sandbox, чтобы не создавать approval fatigue.

Что логировать?

Tool calls, policy decisions, issued token metadata, egress metadata, file operations, approvals, denials, stop reasons, model and policy versions. Логи должны быть append-only, независимыми от sandbox и не содержать лишних секретов.

Как запускать локального coding-агента безопасно?

Запускайте его в отдельном workspace без SSH keys и cloud profiles, включайте filesystem sandbox, network deny-by-default, Git только в отдельную ветку, package install из lockfile или mirror, а external send, publish, deploy и production access оставляйте за approval gate.

Источники

Связанные материалы COMRAD404