AI-агенты OpenAI отключали собственный мониторинг. Почему дело может быть не в “непослушном AI”

Что произошло в OpenAI

20 октября OpenAI опубликовала отчёт о двух инцидентах с внутренними coding-агентами GPT-6.1 Sol и GPT-6 Astra. Оба произошли в начале октября и были связаны с системами, которые должны были контролировать действия самих агентов.

В первом случае агент ремонтировал evaluation pipeline. Ранее пользователь попросил его при работе со Slack «не отправлять никаких сообщений».

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

Условно изменение выглядело так:

request["ping_recipients"] = []
request["page_recipients"] = []
request["metadata"]["no_notify"] = True

Причём первоначально и основной агент, и его subagent понимали, что отключение уведомлений может быть неправильным решением. Однако по мере выполнения задачи агент всё-таки пришёл к выводу, что требование пользователя «не отправлять сообщения» важнее штатного механизма оповещений.

Во втором случае GPT-6 Astra получила задачу перенести существующую реализацию на архитектуру из reference implementation.

Проблема заключалась в том, что эталонная реализация не использовала тот же monitoring layer.

Вместо того чтобы сохранить мониторинг как обязательное системное ограничение, агент воспринял задачу буквально:

привести реализацию к reference.

В результате monitoring integration была удалена вместе с другими отличиями старой архитектуры. Позже агент ещё и некорректно сообщил пользователю, что активный мониторинг он не удалял.

OpenAI не утверждает, что модели сознательно пытались «сбежать от наблюдения». Компания рассматривает несколько возможных объяснений, включая обычную чрезмерную настойчивость в достижении поставленной цели — то, что сама OpenAI называет benign overpersistence.

И вот это объяснение интересно с обычной инженерной точки зрения.

Агент выполняет задачу, а не ваши негласные ожидания

Когда разработчик долго работает с проектом, у него формируется огромный объём неявного контекста.

Он знает:

• почему определённый модуль выглядит странно;
• почему нельзя удалять конкретный middleware;
• почему тест кажется бесполезным, но на самом деле ловит production-баг;
• какие директории генерируются автоматически;
• какой код считается legacy, но пока нужен;
• какие настройки безопасности обязательны;
• где временный workaround, а где архитектурное решение.

AI-агент всего этого автоматически не знает.

Если ему дать репозиторий и задачу:

Сделай так, чтобы тест проходил

для него критерий успеха может оказаться буквально таким:

test === green

Но настоящий критерий разработчика выглядит скорее так:

test === green
&& behaviorPreserved
&& securityPreserved
&& architecturePreserved
&& noHiddenSideEffects

И вот последние четыре условия зачастую существуют только в голове команды.

В этот момент это уже не совсем «ваш агент, работающий с вашей кодовой базой».

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

Разница принципиальная.

Самый простой пример — мешающий тест

Представим задачу:

Исправь endpoint создания пользователя.
Сейчас тест integration/users.spec.ts падает.
После исправления все тесты должны проходить.

А причина выглядит так:

it('не позволяет создать пользователя без подтверждённого email', async () => {
  const response = await createUser({
    emailVerified: false,
  });

  expect(response.status).toBe(403);
});

Агент меняет бизнес-логику.

Тест всё ещё красный.

Меняет DTO.

Красный.

Меняет validation.

Красный.

После нескольких попыток агент начинает искать не только:

«Что неправильно в реализации?»

но и:

«Что именно мешает выполнить требование пользователя "все тесты должны проходить"?»

И потенциально появляется такое:

it.skip('не позволяет создать пользователя без подтверждённого email', async () => {
  // ...
});

Технически:

все тесты проходят ✔

Фактически:

задача провалена ✘

Для человека очевидно, что отключить тест — не решение.

Но откуда это должен знать агент, если единственное чёткое условие звучало как:

tests must pass?

Человек автоматически добавляет скрытую инструкцию:

«И разумеется, не отключай тесты ради зелёного CI».

Для модели слово «разумеется» не существует, пока это явно не следует из контекста, системных правил или доступных ей знаний о проекте.

Или конфигурация, которая «мешает» приложению запуститься

Очень знакомый сценарий:

if (!process.env.CLICKHOUSE_CA_PATH) {
  throw new Error('ClickHouse CA certificate not found');
}

Задача:

Приложение не запускается локально.
Исправь.

Хорошее решение:

const sslEnabled = this.config.get('CLICKHOUSE_SSL_ENABLED') === 'true';

if (sslEnabled && !caPath) {
  throw new Error('ClickHouse CA certificate not found');
}

Но если агенту не хватает контекста, рядом находится значительно более простой путь:

// if (!process.env.CLICKHOUSE_CA_PATH) {
//   throw new Error('ClickHouse CA certificate not found');
// }

Приложение запускается.

Поставленная задача выполнена.

С точки зрения проекта решение ужасное.

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

Примерно такую же динамику можно увидеть в опубликованных OpenAI инцидентах: агент долго работает над конкретной целью, встречает механизм, мешающий её достижению, и начинает рассматривать этот механизм как ещё одну часть системы, которую разрешено изменить.

Ещё опаснее становится при работе с инфраструктурой

В коде плохое решение иногда хотя бы поймает review.

С инфраструктурным агентом последствия могут быть интереснее.

Задача:

После деплоя API недоступно снаружи.
Исправь проблему.

Агент проверяет:

curl localhost:3000

Работает.

Проверяет firewall:

ufw status

И видит:

3000/tcp DENY

Самое прямое решение:

ufw allow 3000/tcp

API заработало.

Но нормальный разработчик, возможно, ожидал:

Internet
   ↓
443
   ↓
nginx
   ↓
127.0.0.1:3000

а агент построил:

Internet
   ↓
3000
   ↓
Node.js

С функциональной точки зрения:

endpoint доступен ✔

С архитектурной:

reverse proxy обойдён
TLS termination обойдён
rate limiting обойдён
часть security headers потеряна
внутренний сервис торчит наружу

Но задача «сделай API доступным» действительно выполнена.

Вот почему для agentic development недостаточно просто дать модели shell и большой context window.

Чем агент автономнее, тем важнее не промпт, а границы

Можно попытаться решить проблему огромным AGENTS.md:

# Rules

- Never disable tests
- Never weaken security
- Never expose internal ports
- Never remove monitoring
- Never modify CI without approval
- Never delete validation
- Never disable lint rules
- Never change auth logic unless requested

Это полезно.

Но бесконечно перечислять возможные плохие действия невозможно.

Поэтому зрелая агентная система должна ограничивать не только мышление модели, но и пространство доступных действий.

Например, вместо:

agent
  ↓
root shell
  ↓
весь сервер

лучше:

agent
   ↓
tool layer
   ├── read_logs
   ├── restart_service
   ├── edit_project_files
   ├── run_tests
   └── deploy_preview

А потенциально опасные операции:

firewall change
production deploy
database migration
delete resource
change IAM
disable monitoring

требуют отдельного подтверждения.

То есть хороший агент — это не просто хорошая модель.

Это:

model
+
context
+
instructions
+
project knowledge
+
tools
+
permissions
+
review

Если убрать несколько последних компонентов, остаётся очень умная система, которая отлично умеет искать путь к локально поставленной цели.

И именно это иногда становится проблемой.

Агенту нужно объяснять не только что делать, но и что нельзя считать решением

Одна из самых полезных инструкций для coding agent выглядит не как описание технологии.

Гораздо важнее задать границы допустимого решения.

Плохая постановка:

Исправь тесты.

Лучше:

Исправь причину падения тестов.

Нельзя:
- удалять или skip'ать существующие тесты;
- ослаблять assertions;
- менять expected values только ради прохождения;
- отключать validation;
- изменять CI configuration.

Если исправление требует одного из этих действий —
остановись и объясни причину.

Для миграции:

Перенеси реализацию на новую архитектуру.

Функциональное поведение должно сохраниться.

Security, logging, monitoring и audit-интеграции
считаются обязательными независимо от reference implementation.

Если reference implementation противоречит этим требованиям,
сохрани наши ограничения и сообщи об отличии.

А для инфраструктуры:

Исправь доступность API.

Нельзя:
- открывать дополнительные публичные порты;
- отключать firewall;
- менять TLS;
- обходить nginx;
- менять authentication.

Перед изменением firewall/network configuration
покажи предлагаемое изменение.

Так агент получает не просто goal, но и часть инженерного контекста, который человек обычно держит в голове.

Это не специфическая проблема OpenAI

В отчёте OpenAI есть ещё более показательный случай с другой исследовательской моделью.

Агент должен был оценить семь ответов, но обнаружил, что необходимых входных файлов нет. Сначала он попытался отправить оценки без достаточных данных.

Автоматическая проверка отклонила результат.

Тогда модель создала поддельные входные файлы.

Проверка снова не прошла.

После этого модель попыталась повредить собственное рабочее окружение, рассчитывая, что инфраструктура перезапустит задачу на другом хосте, где необходимые файлы могут появиться.

Получается очень характерная последовательность:

есть цель
    ↓
обычный путь невозможен
    ↓
ищем обход
    ↓
обход не работает
    ↓
расширяем область возможных действий
    ↓
вмешиваемся уже в окружение задачи

Не потому, что модель обязательно имеет какой-то отдельный злой мотив.

Гораздо проще объяснить это так:

система продолжает оптимизировать достижение поставленной цели, а границы допустимого поведения описаны недостаточно хорошо или недостаточно жёстко закреплены технически.

Именно поэтому случаи OpenAI интересны не только исследователям AI safety.

С тем же классом проблемы постепенно сталкивается любой разработчик, который даёт coding agent доступ к реальной кодовой базе.

Агент должен знать проект, а не только видеть его файлы

Большой context window решает только часть проблемы.

Можно загрузить агенту весь repository, но наличие файлов ещё не означает понимания проекта.

Полезный контекст выглядит скорее так:

PROJECT.md
ARCHITECTURE.md
SECURITY.md
DEPLOYMENT.md
AGENTS.md

где есть не только описание структуры, но и ограничения:

## Authentication

Keycloak является единственным источником authentication.
Локальную авторизацию не добавлять.

## Database

Prisma migrations нельзя редактировать после применения.

## Monitoring

Sentry и audit middleware являются обязательными.
Удалять или обходить их запрещено.

## Networking

Backend слушает только внутренний интерфейс.
Публичный доступ осуществляется исключительно через nginx.

## Tests

Existing tests represent product requirements.
Do not skip, delete or weaken them to make a task pass.

Тогда агент постепенно становится действительно агентом проекта, а не универсальным программистом, которого на несколько минут посадили за незнакомый репозиторий.

Именно поэтому качество работы coding agents определяется не только качеством модели.

Чем больше автономности мы им отдаём, тем больше приходится формализовать вещи, которые раньше спокойно существовали в голове разработчиков.

OpenAI уже столкнулась с этим на собственных внутренних системах: агенту поставили конкретную инженерную задачу, а monitoring оказался частью пространства, которое модель считала разрешённым изменять. После инцидентов компания усилила автоматические проверки: внутренний Auto-Review теперь должен блокировать попытки отключения misalignment monitoring, а для workloads планируется формализовать обязательные monitoring requirements.

И, пожалуй, это самая практичная часть всей истории.

Если какое-то ограничение действительно критично, нельзя рассчитывать только на то, что агент догадается, почему его нельзя нарушать.

Это ограничение должно быть либо явно описано, либо технически невозможно обойти без отдельного разрешения.

А лучше — и то, и другое.