Как сделать ИИ-агентов безопасными? Разбор архитектуры безопасности агентского ИИ от OpenAI

Когда агент может сам читать репозитории, выполнять shell-команды и взаимодействовать с инструментами разработки, возникает закономерный вопрос: как обеспечить информ.безопасность? OpenAI опубликовали подробности о том, как они сами у себя внутри работают с агентами. Разберём по частям.

Что такое Codex, для тех, кто еще не успел попробовать

Codex – это ИИ-агент: он автономно обходит репозитории, запускает команды, дёргает внешние API и инструменты разработчика. Агенты могут работать параллельно, в изолированных копиях кода, а пользователь переключается между задачами, смотрит изменения и забирает результат.

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

Именно поэтому у OpenAI сформировался чёткий принцип развёртывания: низкорисковые действия – без остановок, высокорисковые – с проверкой.

Слой 1: Песочница и система одобрений

Первая линия контроля sandbox. Он определяет техническую границу выполнения, куда Codex может писать, к каким путям имеет доступ, что остаётся защищённым.

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

Чтобы агент не превращался в машину по генерации диалогов “разрешить/запретить”, OpenAI добавили режим автопроверки (auto_review). Это субагент, который запущен рядом и молча одобряет рутинные низкорисковые запросы без прерывания пользователя. Но стоит появиться чему-то нестандартному или потенциально опасному – управление передаётся человеку.

# config.toml
approvals_reviewer = "auto_review"
sandbox_workspace_write.writable_roots = ["~/development"]

# requirements.toml
allowed_sandbox_modes = ["read-only", "workspace-write"]

Слой 2: Управление сетью

Codex не получает открытый исходящий доступ. Сетевая политика строится по принципу allowlist: разрешено только то, что явно прописано.

# requirements.toml
allowed_web_search_modes = ["cached"]

[experimental_network]
enabled = true
allow_local_binding = true
denied_domains = ["pastebin.com"]
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

Логика ^[1] простая: агент должен уметь выполнять стандартные рабочие процессы – обращаться к нужным сервисам, работать с localhost ^[2], но при этом не иметь возможности отправить данные куда попало. Незнакомый домен вне списка приведет к паузе и запросу одобрения.

Слой 3: Правила на уровне команд

Не все shell-команды одинаково безопасны. Это очевидно, но агент сам по себе этого не понимает и ему нужны явные правила.

OpenAI прописывают гранулярные политики через prefix_rule: стандартные команды для чтения и инспекции (к примеру, логи Kubernetes) разрешены без одобрения, потенциально деструктивные паттерны сразу блокируются или требуют явного разрешения.

# default.rules
prefix_rule(
    pattern = ["gh", "pr", ["view", "list"]],
    decision = "allow",
    justification = "Allows read-only GitHub PR inspection via gh CLI.",
)
prefix_rule(
    pattern = ["kubectl", ["get", "describe", "logs"]],
    decision = "allow",
    justification = "Allows Kubernetes resource inspection for debugging.",
)

Это позволяет Codex быстро справляться с повседневными инженерными задачами, не останавливаясь на каждом git status, но при этом не выполнять ничего разрушительного молча.

Слой 4: Аутентификация и управление учётными данными

Учётные данные CLI и MCP OAuth хранятся в системном keychain ОС, а не в конфиг-файлах или переменных окружения. Вход только через корпоративный ChatGPT Workspace.

# config.toml
cli_auth_credentials_store = "keyring"
mcp_oauth_credentials_store = "keyring"
forced_login_method = "chatgpt"
forced_chatgpt_workspace_id = "<workspace-uuid>"

Подход даёт два плюса: во-первых, вся активность Codex привязана к конкретному воркспейсу и попадает в платформу соответствия OpenAI. Во-вторых, компрометация конфига не равна компрометации credentials.

Слой 5: Телеметрия уровня агента и вот здесь самое интересное

Традиционные security-логи фиксируют факты: процесс запущен, файл изменён, сетевое соединение установлено. На вопрос почему они не отвечают.

Codex экспортирует OpenTelemetry-логи с полным агентным контекстом: пользовательский запрос, решения по одобрению инструментов, результаты выполнения, использование MCP-серверов, сетевые события (разрешено/заблокировано).

# config.toml
[otel]
log_user_prompt = true
environment = "prod"

[otel.exporter.otlp-http]
endpoint = "http://localhost:14318/v1/logs"
protocol = "binary"

Эти логи можно гнать в любой SIEM. Но OpenAI пошли дальше: они добавили поверх ИИ-агента по классификации безопасности, который разбирает логи Codex в контексте алертов от endpoint security. Один ИИ смотрит за другим и объясняет команде безопасности, было ли это штатным поведением ^[3], безобидной ошибкой ^[4] или чем-то, что реально стоит эскалировать.

Если смотреть на всё это системно, OpenAI выстроили несколько независимых слоёв контроля, которые работают вместе:

Техническое ограничение (sandbox) → поведенческое ограничение (правила на команды) → сетевая изоляция → управление идентичностью → телеметрия с контекстом → ИИ-триаж поверх телеметрии.

Каждый слой решает свою задачу и не полагается на то, что предыдущий сработает идеально. Это и есть defence in depth, хоть м не новая концепция, но применённая к агентным системам довольно последовательно.

Еще больше обзоров нейросетей, лайфхаков по использованию ИИ и последних новостей индустрии в моем тг-канале Первые в ИИ. Ну почти ^[5]