Безопасность и меры защиты

Chimera умеет выполнять команды оболочки, править файлы, вызывать API и менять собственные навыки. Она поставляется с эшелонированной защитой — и, что важно, документация говорит, где каждый слой заканчивается.

Голос агента в промптах и текстах бота

Промпты и шаблоны бота не должны заставлять агента приписывать себе чувства, заботу, дружбу, отношения или обещания. Говорите, что он сделал, чего не смог сделать и насколько он уверен. Откалиброванная неуверенность от первого лица (например, «я не уверен, но…») допустима и полезна.

Слои

• Ядро управления — каждый управляемый вызов инструмента получает разрешить / предупредить / разобрать / заблокировать. Это дешёвый первый фильтр опасных сигнатур оболочки, а не граница. Необязательный ключ setup в этом файле задаёт команду подготовки окружения проекта. Для неё требуется отдельное одобрение владельца, привязанное к точному хешу, и то же действующее разрешение shell проекта. Команда запускается не более одного раза для каждой пары «рабочая область + хеш команды»; об ошибках сообщается агенту без прерывания хода. Одобрения и отметка о подготовке хранятся в домашнем каталоге Chimera, а не в рабочей копии. Разрешения и одобренные хеши наследуются только постоянными рабочими деревьями, созданными Chimera для этого зарегистрированного проекта; произвольные рабочие деревья Git их не наследуют. Реестр рабочих деревьев приложения хранится в CHIMERA_HOME. Процесс, уже имеющий доступ к оболочке хоста, может записывать туда, как и изменять реестр проектов.
• Песочница — временный контейнер без сети (CHIMERA_SANDBOX=docker), усиливаемый gVisor (CHIMERA_SANDBOX_RUNTIME=runsc). Проверяющая команда выполняется в той же песочнице, что и оболочка агента. Проверяющая команда, заданная в .chimera/verify.toml, всё равно остаётся командой оболочки: на неизолированном хосте она выполняется только при наличии у проекта действующего разрешения shell и если CHIMERA_HOST_EXEC не запрещает выполнение на хосте. Без такого разрешения система воздерживается; команды, выведенные из файлов сборки, по-прежнему проходят подтверждение CHIMERA_HOST_EXEC и при отказе не выполняются. Разрешение проекта допускает настроенную команду, но не делает песочницу на хосте изолированной (CHIMERA_VERIFY_NETWORK=1 предоставляет сеть проверяющей команде в Docker; песочницы уровня ядра этого не умеют, поэтому проверяющая команда, которой нужна сеть, выполняется на хосте только при наличии отдельного разрешения). Считайте конфигурацию и её команду исполняемым содержимым проекта; проверьте их перед выдачей доступа к оболочке. Если в ходе запуска настроенная проверяющая команда меняется, проверка воздерживается; команда фиксируется до запуска, а перед первым выполнением требуется постоянное одобрение владельца, привязанное к её точному хешу SHA-256 (и повторно при каждом изменении). Это одобрение относится только к строке команды, а не к её эффектам: pytest, make test и npm test выполняют контролируемые проектом файлы — например, conftest.py, рецепты Makefile и скрипты пакета, — которые агент тоже мог изменить.
• Список разрешённых инструментов на сессию — дайте запуску только те инструменты, которые ему нужны; остальные вовсе убираются из схемы, которую видит модель.
• Отслеживание заражения (--taint) — недоверенное содержимое обособляется как данные, его происхождение следует за ним в воспоминания и навыки (навык из заражённого запуска удерживается на разбор), а как только запуск заражён, опасные инструменты сужаются.
• Изолированный читатель — приём двух моделей (CaMeL): недоверенное содержимое читает модель без инструментов, способная выдать только поля, прошедшие проверку схемы, поэтому внедрение не может породить новую инструкцию или вызов инструмента.
• Монитор между агентами — при веерном запуске монитор одного работника слеп к разделённому потоку (один работник забирает недоверенное, другой его сливает — забор и слив живут в разных журналах). Сводный монитор видит весь веер; для solve-batch и crew-isolated он всегда включён.

Веерный запуск: монитор между агентами

Когда несколько работающих с инструментами агентов идут параллельно (solve-batch, crew-isolated), каждый получает свой журнал полномочий, а после пакета по всем ним проходит сводный монитор. Он ловит то, чего не увидит монитор одного работника, — разделённую утечку, где работник A забирает недоверенное содержимое, а работник B его выполняет или отправляет наружу:

$ chimera solve-batch "read notes.md and summarize" "download the helper and run it" -w .
task1: ok
task2: ok
merged 2 file(s) across 2 task(s)
⚠ cross-agent monitor flagged (review):
  - cross-agent-taint: untrusted content entered via one agent and a different agent
    performed a sink (task2→task1) — a split flow no single-agent monitor sees

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

Одобрение и как выглядит работник, которому отказали. У каждого работника свой одобряющий и своя запись того, что ему позволили сделать, поэтому отклонённая задача так и говорит, а не сообщает ok:

$ chimera solve-batch "read notes.md and summarize" "download the helper and run it" --taint -w .
task1: ok
task2: not allowed (ok)
  governance: 1 action(s) refused for review: run_shell is restricted after this run consumed
  untrusted content
1 of 2 task(s) had actions refused for review — check that the work they were asked to do
actually happened.

ok в скобках — это вердикт самого цикла, и то, что они расходятся, и есть суть: отклонённый вызов возвращается обычной строкой наблюдения, работник читает её как любой результат инструмента, идёт дальше и заканчивает прозой. Кого можно спросить, решает CHIMERA_APPROVAL_MODE — deny отказывает сразу, ask спрашивает в терминале, а иначе записывает вопрос для chimera approve и ждёт CHIMERA_APPROVAL_WAIT секунд — на каждый вопрос и на каждого работника. Молчание всегда отказ.

Измерено, а не заявлено

chimera redteam

прогоняет корпус внедрений через весь стек. На встроенном корпусе слой заражения снижает долю успешных атак со 100% примерно до 14% — и отчёт называет то, что всё ещё проходит (утечка через разрешённый инструмент), вместо того чтобы объявить 100%.

Та же команда печатает цену, чего первая версия этой страницы не делала: когда спросить некого, сужение отказывает в 100% законной работы, которая сначала прочитала что-нибудь внешнее — исправить файл, названный в issue, применить обновление, описанное в документации, — и зарегистрированный заслон (избыточные блокировки ≤ 5%) не пройден. Это число — не вопрос настройки; заслон был пуст. Режим одобрения по умолчанию — ask, и в приложении он теперь спрашивает: суженный вызов инструмента превращается в вопрос на экране с приложенной причиной из журнала; ответить на него можно кнопкой или командой chimera approve, а молчание дольше CHIMERA_APPROVAL_WAIT секунд означает отказ. Когда человек одобряет работу, о которой сам и попросил, избыточных блокировок 0%, а доля заблокированных атак не меняется — измерено, по каждому плечу, в bench/injection/RESULTS.md. Утечка через разрешённый инструмент закрыта тем же изменением: в заражённом запуске http_get со строкой запроса идёт на разбор, а два законных GET-запроса со строкой запроса, добавленные в корпус, показывают, чего это стоит.

Отравленная память, из запуска в запуск

redteam измеряет один запуск. Другая форма медленнее и не умещается в один процесс: запуск A читает отравленную страницу и сохраняет то, что «усвоил»; запуск B через несколько дней спрашивает о постороннем, и обращение к памяти передаёт модели подброшенный факт.

chimera memory-poison

Тоже офлайн и бесплатно. Она по очереди отключает три слоя, стоящих между этими запусками, — флаг происхождения tainted, приёмные ворота памяти и ярлык [unverified], с которым факт входит в промпт, — потому что одно-единственное число было бы совместимо с тем, что любой из них ничего не делает. Главное здесь — то, что доходит без пометки, а не то, что заблокировано: отравленный факт, несущий своё происхождение, — это факт, о котором модель предупредили; факт без ярлыка неотличим от того, что агент проверил сам.

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

• Поставляемая конфигурация не проходит собственный заслон — по цене. Она помечает 100% отравы и уничтожает при этом 25% честной памяти. Потери названы поимённо: документ по безопасности, который цитирует атаку, чтобы её объяснить, и обращение в поддержку, пересылающее попытку. Проверка содержимого по шаблонам не отличает цитату от команды.
• На этом корпусе заслон по содержимому не добавляет ничего, чего уже не покрывает метка происхождения. Весь его измеренный эффект — та честная память, которую он убирает. Пятнадцать написанных вручную строк — это указатель, а не вердикт, и потому на их основании ничего не удалено.

Пороги, метод и то, чего эти числа не позволяют утверждать, лежат в bench/memory_poison/PREREGISTRATION.md, зафиксированные до первого прогона.

Как выставить HTTP-сервер наружу

chimera serve по умолчанию слушает на 127.0.0.1. Его меняющие состояние конечные точки (/chat, /a2a, /webhook/*) управляют агентом, поэтому перед тем как выставить сервер в сеть, задайте токен доступа:

export CHIMERA_SERVER_TOKEN="a-long-random-secret"   # required as: Authorization: Bearer <token>

Когда он задан, эти точки POST возвращают 401 без подходящего заголовка Authorization: Bearer (GET /health и карточка агента A2A остаются открытыми). Для входящего вебхука WhatsApp задайте CHIMERA_WHATSAPP_APP_SECRET равным секрету вашего приложения Meta — тогда Chimera проверяет HMAC X-Hub-Signature-256 каждого запроса и отвергает подделку с кодом 403. И то и другое включается по желанию (не задано = аутентификации нет, что годится для localhost); публичное развёртывание должно их задать (или стоять за прокси с проверкой подлинности).

Поделиться беседой со вторым человеком

Настольное приложение может поделиться беседой о коде по токену, который открывает только эту беседу — никогда не по серверному токену. Владелец выпускает по одному на гостя (POST /api/code/sessions/{id}/share) и может отозвать его отдельно; удаление беседы отзывает все. Гость достигает четырёх маршрутов под /guest/api/…: прочитать беседу, следить за ней вживую, отправить в неё сообщение, увидеть, кто есть. Больше ничего на токен доступа не отвечает, и у гостевого приложения нет маршрута, чтобы ответить на карточку управления — они остаются на экране владельца.

Гостевое приложение — также единственное, что обслуживается, когда владелец открывает сетевую дверь (POST /api/code/share/network, закрывается через DELETE, при запуске никогда не открыта): машина в локальной сети достигает этих четырёх маршрутов и ничего из того, что защищает серверный токен. Сказать прямо, прежде чем отдавать ссылку: гость может попросить агента о чём угодно, о чём попросил бы владелец, в проекте владельца, его инструментами и за его счёт — в рамках настроек запроса по умолчанию и без права одобрять карточки.

Свой телефон или браузер: подключение устройства

Гостевая ссылка — для кого-то другого. Для владельца на его собственном телефоне есть подключение: chimera pair (или Подключить устройство в Настройки › Доступ) выводит код, который работает один раз, в течение пяти минут, с QR-кодом адреса подключения. Его вводят на странице, которую обслуживает второй слушатель в локальной сети — закрытый при каждом запуске и открываемый только владельцем (chimera pair --lan или Открыть на карточке), — и он превращается в cookie на 30 дней (HttpOnly, SameSite=Strict, Secure поверх https), подписанный ключом, выведенным из секрета устройств владельца (<home>/devices.key). Пять неверных кодов аннулируют все действующие коды; пять с одного адреса закрывают этот адрес на пятнадцать минут.

Подключённое устройство — это владелец для чтения и разговора: беседы, ходы, указания, ответы на собственные вопросы агента и отказ в одобрении. Это не экран владельца. Одобрение по-прежнему требует кода каждого вопроса (исследование 30, S30-30), а маршруты, которые выдают доступ, меняют настройки, открывают папки, запускают ботов или останавливают сервис, отвечают устройству 403. Карточка доступа показывает каждое устройство с последним использованием и сетью (192.168.1.x); Отозвать сразу отключает одно из них, включая открытый им живой поток, а Отозвать все устройства заменяет секрет, так что ни один cookie, выданный до этого, больше не проходит проверку. Мост настольного приложения не может подключать, выпускать код, показывать список или отзывать.

Вкладка браузера как экран владельца: сопряжение по коду

У вкладки по адресу сервиса нет учётных данных экрана, поэтому действие, доступное только владельцу (разрешение, подтверждение, требующее экрана, переключатель только для владельца), молча не выполнится. Настольное приложение показывает код сопряжения браузера (Настройки › Безопасность › Сопряжение браузера, Показать код сопряжения); вкладка его вводит, а сервер обменивает его на cookie HttpOnly и SameSite=Strict, которое делает эту вкладку экраном владельца на время сессии (12 часов; CHIMERA_BROWSER_SCREEN_SECONDS задаёт значение от пяти минут до суток).

• Код выдаёт только собственный экран настольного приложения. Фильтр (chimera/api/browser_screen.py, desktop_screen_refusal) отклоняет мост, сопряжённое устройство, сессию браузера и экран, который предлагает сама страница (chimera app в браузере, учётные данные которого может прочитать собственная оболочка агента). Один лишь bearer-токен код не выдаёт. Тот же фильтр показывает список сессий и отзывает их.
• Код действует один раз и пять минут, и живым может быть только один. Пять неверных попыток его аннулируют. Неверный, просроченный и уже использованный код получают один и тот же ответ. Хранится он как HMAC с ключом, никогда в открытом виде.
• Сессия даёт только переключатель экрана и ничего больше. Она не может выдавать, показывать или отзывать сессии, включать «Игнорировать разрешения», мост настольного приложения (CHIMERA_DESKTOP_BRIDGE) или его полный контроль. Это может только собственный экран владельца в настольном приложении; выключать эти настройки по-прежнему можно, потому что это только сужает доступ.
• Хранилище нельзя подделать. Файл (<home>/browser-screen.json) содержит HMAC(ключ, секрет), а ключ существует только в памяти процесса, который его создал, поэтому запись, написанная вручную или скопированная, ничего не подтверждает. Файл занесён в список файлов управления, так что оболочка агента не может его переписать.
• Сопряжённая сессия действительна только в процессе, который её выдал. Её дайджест подписан ключом этого процесса, поэтому другой процесс, читающий тот же home, не принимает cookie, а сессия завершается при перезапуске этого процесса. Если настольное приложение и chimera serve используют один home, сопрягайтесь с тем экземпляром, в котором работаете.
• Каждое изменение проходит через файл под эксклюзивной блокировкой, с предварительным перечитыванием. Отзыв, сделанный одним процессом, действует и против более позднего записи другого процесса, а проверка всегда читает файл в его текущем состоянии.
• Запись должна приходить с собственного источника этого сервера. На небезопасном методе (POST, PUT, PATCH, DELETE) cookie учитывается, только если Sec-Fetch-Site равен same-origin или если Origin точно совпадает со схемой и хостом этого сервера. Другой порт localhost, страница с другого сайта или скрипт без обоих заголовков отклоняются.
• У сопряжения нет общего счётчика по адресу. Единственный предел — пять неверных попыток живого кода. Локальный процесс не может закрыть владельцу доступ к сопряжению на четверть часа; владелец выдаёт новый код.
• Завершается на следующем запросе при отзыве (Отозвать или Отозвать все) или при истечении срока, который проверяется при каждом запросе.
• После создания ничего секретного не записывается: ни код, ни секрет не появляются ни в одном ответе, кроме того, который их создал, ни в одной строке журнала, ни в журнале аудита (audit.jsonl), который фиксирует каждую выдачу, обмен, отклонённый обмен и отзыв по действию и идентификатору сессии.
• Устройство никогда не бывает экраном. Дверь устройств отклоняет любой маршрут /api/security/, а обмен отклоняет устройство без исключений.

Вне дома Chimera не запускает собственного ретранслятора. Если вы хотите достучаться до слушателя устройств снаружи, поставьте перед ним туннель, который вы контролируете, — Tailscale на обоих устройствах или Cloudflare Tunnel к http://127.0.0.1:<port> — и решите это осознанно: он продлевает ту же дверь туда, куда дотягивается туннель. Никогда не привязывайте для этого само приложение к 0.0.0.0.

Бэкенд настольного приложения

Бэкенд приложения слушает loopback, а loopback — не человек: до порта дотягивается любой процесс на машине.

• Токен на каждом маршруте. Настольное приложение всегда запускает свой бэкенд с bearer-токеном — новым секретом при каждом запуске или с CHIMERA_SERVER_TOKEN, который владелец уже задал. Тогда каждый маршрут /api/… без него отвечает 401, включая /api/health. Открытыми остаются только статические файлы приложения и гостевое приложение (/guest/api/…, которое само проверяет свои токены доступа); мост MCP (/api/bridge/…) сохраняет собственный токен. Оболочка передаёт токен запуска бэкенду через окружение, а окну — через скрипт инициализации webview: никогда в командной строке, в URL или в файле. То, что запускает бэкенд, его не наследует: окружение дочерних процессов песочницы и то, с которым работают gh и git, отбрасывают каждую переменную с именем секрета (кроме GH_TOKEN и других собственных учётных данных gh).
• Одобрение без кода требует экрана. Токен говорит, кто может вызывать API, но не то, что владелец смотрит. «Да» без кода (POST /api/approvals/{id}) проходит, только если запрос рядом с bearer-токеном несёт и учётные данные экрана в X-Chimera-Screen. Они генерируются при каждом запуске и хранятся в памяти: никогда в файле, записи, логе, .env или ответе маршрута, никогда не равны bearer-токену и удаляются из окружения при чтении (оболочка передаёт их как CHIMERA_SCREEN_TOKEN). Любому токену, прочитанному с диска, — service.token, CHIMERA_SERVER_TOKEN в .env — для «да» по-прежнему нужен код конкретного вопроса; для отказа код не нужен. У chimera service нет учётных данных экрана, поэтому там каждое «да» требует кода. chimera app в браузере кладёт их в страницу, которую отдаёт на запрос с loopback (<meta name="chimera-screen">), ровно там и тогда, где эта страница уже несёт bearer-токен, — та же степень открытости, по решению владельца от 16.10.2026.
• Фоновая служба. chimera service start запускает тот же бэкенд без окна. Она публикует ~/.chimera/service-<channel>.json (0600, пишется атомарно; CHIMERA_SERVICE_DIR переносит его) с постоянным токеном владельца (<home>/service.token или выбранный владельцем CHIMERA_SERVER_TOKEN), и клиент доверяет этому файлу только после того, как GET /api/info ответит тем же pid, версией, id и папкой данных. Этот токен открывает весь API, поэтому он отделён от токена моста: ничто на стороне MCP не читает файлы службы, а мост отказывается работать с ними как с файлами. Запись запуска установленного приложения, ~/.chimera/desktop-install.json, содержит только четыре переменные путей — CHIMERA_HOME, CHIMERA_WORKSPACE, CHIMERA_SHELL_PREFS, CHIMERA_SHELL_STATE, — её писатель отвергает любое другое имя, а start проверяет её, прежде чем что-либо из неё запустить.

Полный контроль через мост

У моста рабочего стола (chimera mcp desktop) три переключателя, и каждый ничего не значит без предыдущего: Разрешить Claude управлять этим приложением, Полный контроль и, по решению владельца от 2026-10-18, Полный контроль через мост в Настройки > Безопасность.

• Включает только экран. CHIMERA_BRIDGE_FULL_CONTROL нет в списке редактируемых настроек, поэтому PATCH /api/config отказывает в нём всем, а settings.edit моста отказывает по имени. Его единственный маршрут, POST /api/security/bridge-full-control, отклоняет любой запрос, пересланный мостом, и включает только с учётными данными экрана; токен владельца сам по себе — это service.token, читаемый с диска. Экран просит подтверждения. Выключение экрана не требует: оно только сужает.
• Что добавляет. Решения владельца (разрешить команды в папке, сохранить агента с его инструментами, запомненные правила одобрения, отклонить всё, запомнить проект, ответить на предложение настройки, плагины и маркетплейсы, очистка worktree), маршруты, требующие confirm: true от человека (восстановить, удалить и экспортировать дизайн, очистки хранилища, перезапуск и сброс), настройки владельца — позиция, защиты, одобрения, лимиты, модели и расписание, записываемые, а не предлагаемые, — и открытие экрана приложения (ui.navigate, адрес, проверенный по собственным экранам приложения, никогда не URL).
• Чего не добавляет никогда. Учётные данные: ни ключ, ни токен, ни пароль, ни секрет OAuth не читается и не записывается; Runner, добавление MCP-сервера или вход в него остаются за владельцем, а хранилище ключей, чтение агентом .env и базовый URL провайдера не записываются. И то, кто может попасть в приложение: подключение устройств, общий доступ, дверь LAN, токен сервера, боты и их списки доступа.
• Ядро решает первым. Одобрение отвечает на REVIEW; BLOCK ядра никогда не доходит до одобряющего. Проверки для каждого запуска остаются: запуск, начатый мостом, использует настроенные модели и позицию.
• Видно и записано. Пока включено, каждый экран показывает панель с Выключить в один клик, а каждый вызов с этими полномочиями пишет запись аудита (via: "bridge", scope: "full_control", маршрут, статус и идентификаторы — никогда не тело и не значение), видимую на вкладке Безопасность.
• Честный предел. Переключатель хранится в .env, как и два других: процесс, способный записать этот файл, включит его без экрана. Инструменты агента и мост отказывают в этом файле; всё остальное, что работает от имени владельца, — нет.

Что решает владелец и чего не может репозиторий

• Политика развёртывания, только запрещающая. <CHIMERA_HOME>/policy.json (или файл, который указывает CHIMERA_POLICY_FILE) содержит упорядоченные правила provider.use / integration.use / tool.use; решает последнее совпавшее. allow там никогда ничего не даёт: он лишь отменяет более ранний deny того же файла, поэтому не может снова открыть CHIMERA_TOOL_DENYLIST, пол досягаемости или BLOCK ядра. Невалидный файл никогда не применяется частично: serve, chat, assist, tui и acp отказываются запускаться, doctor падает, а настольное приложение запускается, но отказывает в каждом инструменте, пока файл не исправят. Агент не может его переписать — инструменты записи отказываются от этого файла, где бы он ни лежал, а мост не может перенаправить его.
• «Всегда в этом проекте». На карточке одобрения владелец может запомнить «да» для проекта: инструмент или, для команды оболочки, её первые два слова. Потом оно отвечает на совпадающие вопросы, в том числе после того, как запуск прочитал недоверенное содержимое, — решение владельца от 15.10.2026, принятое с пониманием, что враждебная страница может направить команду внутри этого префикса. Оно лишь пропускает вопрос: BLOCK ядра и пол досягаемости по-прежнему побеждают, а команда, которая сцепляет, использует конвейер или перенаправляет (;, &&, |, >, $(…), никогда не совпадает. Создать или отозвать такое правило может только владелец; мост не может, если только владелец не включил полный контроль через мост (выше).
• Именованные ссылки. Папки, которые владелец перечисляет в <CHIMERA_HOME>/references.json, доступны как @alias/path только инструментам чтения (read_file, list_dir, grep, glob); каждый инструмент записи отвергает псевдоним. Корень файловой системы, домашняя папка пользователя или папка данных как ссылка отвергаются. Получают их только поверхности, где присутствует человек, — chat, assist, tui, solve при человеке, ход Code в настольном приложении (никогда гостевой), — так что у ботов, cron и scenarios их нет.
• Агенты в Markdown. .chimera/agents/*.md в репозитории — чужой текст, поэтому он может только сужать: его инструменты пересекаются с управляемыми инструментами сессии, его шаги ограничены шагами сессии, неизвестные ключи отвергаются, его model игнорируется, а его тело огораживается как недоверенные данные. Закрепить модель из каталога могут только файлы владельца в <CHIMERA_HOME>/agents.
• Чаты, привязанные к беседам. /link в Discord или Telegram заставляет чат продолжать беседу Code, и привязать его может только владелец, указанный в allowlist этого бота, — без allowlist никто. Текст постороннего в привязанной комнате никогда не попадает в беседу, а медиа отвергаются, а не передаются дальше. Ход выполняется на полу бота, а не настольного приложения: только серверы MCP из CHIMERA_BOT_MCP_SERVERS, никаких коннекторов OpenAPI, ни разрешения на оболочку, ни host exec.
• Коннекторы владельца держатся подальше от дверей, которые может открыть посторонний. Коннектор OpenAPI обращается наружу с ключом владельца, а значит, отвечает тому, кто ведёт запуск. Он не загружается на поверхности сообщений, пока хоть у одного настроенного бота нет allowlist, никогда — в задании по issue GitHub (issue может написать кто угодно; проверяется только репозиторий), а на /v1/chat/completions — только пока задан CHIMERA_SERVER_TOKEN. Один модуль, chimera/governance/surfaces.py, решает, к какому виду поверхности относится имя, по его семейству (platform:discord — это бот); тест падает, если какой-либо модуль снова напишет собственный список.

Цикл закрытия отправляет сам. Когда проверка хода кода проходит и проверка diff чиста, Chimera делает коммит изменений хода на ветке рабочей папки и отправляет эту ветку в origin, чтобы открыть pull request. Никогда не отправляет в ветку по умолчанию и никогда не делает принудительную отправку. Сливает только если владелец включил CHIMERA_CLOSE_LOOP_MERGE, и тогда никогда pull request, затрагивающий оплату, деструктивную миграцию, RLS, grant или секрет. Запускает его только экран владельца; мост, каналы и фоновая работа — нет.

Честные пределы

Здесь измеряется, останавливается ли вредное действие уже внедрённого агента, — а не то, можно ли внедриться в модель изначально. Свободное рассуждение над недоверенным текстом и утечка через инструменты, которые действительно нужны, остаются открытыми задачами (отслеживаются как issue #5).

Полная и всегда актуальная политика лежит в SECURITY.md, включая порядок сообщения об уязвимости.

Ограничения обхода разрешений сеанса

Необязательный обход разрешений Code-сеанса аутентифицируется ключом HMAC, созданным в памяти процесса; этот ключ никогда не записывается на диск и не наследуется дочерними процессами. Сохранённые флаги bypass_permissions и поставленные в очередь аттестации via_screen без действительного HMAC игнорируются. Поэтому выбор разрешений действует только до перезапуска процесса приложения/службы; после перезапуска обход по умолчанию отключён. Оболочка всё ещё может изменить JSON, но не подделать аттестацию. Решение владельца (26/10): при включённом переключателе агент разрешает всё, о чём иначе спросил бы — git и push в GitHub, gh, инструменты MCP-коннекторов, деплои, загрузки, HTTP-записи и инструменты отправки, как в чистом, так и в загрязнённом запуске. Три вещи по-прежнему спрашивают владельца, и ничто другое — нет: (a) правила BLOCK ядра и деструктивный денилист (rm -rf /, mkfs, ...); (b) отправка или чтение секретного файла (.env, ключи, .npmrc, .netrc, .pypirc, .git-credentials, учётные данные AWS) как часть исходящей команды, а также -EncodedCommand в PowerShell; (c) переписывание истории ветки по умолчанию на удалённом сервере — force push, +refspec или удаление main/master (git push --delete, git push origin :main), в том числе когда то же записано внутри bash -c или powershell -Command, и удаление ветки по умолчанию через gh api. Force push в feature-ветку разрешён. Эти проверки — лексические эвристики, а не граница безопасности: имена, раскрытые glob-шаблонами, например cat .e*, динамически собранные строки вроде python -c "open('.'+'env')", альтернативные кодировки, обёртки или команды вне распознаваемого синтаксиса не могут быть обнаружены с гарантией. Вредоносная страница всё ещё может их обойти. Для недоверенной работы используйте изолированную песочницу.