Когда агент может сам читать репозитории, выполнять 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"]
Логика простая: агент должен уметь выполнять стандартные рабочие процессы - обращаться к нужным сервисам, работать с localhost, но при этом не иметь возможности отправить данные куда попало. Незнакомый домен вне списка приведет к паузе и запросу одобрения.
Слой 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. Один ИИ смотрит за другим и объясняет команде безопасности, было ли это штатным поведением, безобидной ошибкой или чем-то, что реально стоит эскалировать.
Если смотреть на всё это системно, OpenAI выстроили несколько независимых слоёв контроля, которые работают вместе:
Техническое ограничение (sandbox) → поведенческое ограничение (правила на команды) → сетевая изоляция → управление идентичностью → телеметрия с контекстом → ИИ-триаж поверх телеметрии.
Каждый слой решает свою задачу и не полагается на то, что предыдущий сработает идеально. Это и есть defence in depth, хоть м не новая концепция, но применённая к агентным системам довольно последовательно.
Еще больше обзоров нейросетей, лайфхаков по использованию ИИ и последних новостей индустрии в моем тг-канале Первые в ИИ. Ну почти