Эта страница переведена с английской документации. Команды, идентификаторы и примеры не изменены. Среда выполнения 7.24.4 · SDK 2.6.7. Английский оригинал

Политика безопасности

Поддерживаемые версии

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

Сообщение об уязвимости

Мы относимся к безопасности серьёзно. Если вы нашли уязвимость, сообщите о ней ответственно:

1. Частный контакт: используйте канал связи AutomatosX, чтобы запросить конфиденциальный маршрут сообщения о безопасности. Не включайте подробности эксплуатации и учётные данные в публичные сообщения сообщества.
2. Discord: сообщите в нашем Discord: https://discord.gg/gf9UyPxaN2

Мы подтвердим получение в течение 6 рабочих дней и будем держать вас в курсе движения к исправлению.

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

Модель угроз

Обзор

ax-code — помощник для кодирования на ИИ, который работает локально на вашей машине. Он даёт систему агента с доступом к мощным инструментам, включая выполнение оболочки, операции с файлами и доступ к вебу.

Значение изоляции среды выполнения по умолчанию — full-access (песочница выключена), с неограниченной записью в файловую систему и доступом к сети. Это удобная позиция для доверенных локальных проектов, а не граница безопасности. Выберите workspace-write или read-only, прежде чем использовать AX Code с недоверенными репозиториями или нагрузками без присмотра.

Песочница изоляции выполнения

В ax-code есть встроенная песочница изоляции выполнения, которая ограничивает, к чему может обращаться агент ИИ. Доступны три режима:

Ключевые свойства:

• Поведение по умолчанию — AX Code стартует в full-access, если --sandbox, AX_CODE_ISOLATION_MODE или конфигурация не задают другой режим
• Рекомендуемый ограниченный режим — используйте workspace-write для недоверенных репозиториев и репозиториев команды; он ограничивает запись рабочей областью и по умолчанию отключает сеть
• Принуждение на уровне инструментов — все инструменты изменения (bash, edit, write, apply_patch) и сетевые инструменты (webfetch, websearch, codesearch) проверяют политику изоляции до выполнения
• Защищённые пути — каталоги .git и .ax-code всегда защищены от записи, даже в режиме записи в рабочую область
• Запросы повышения — в ограниченных режимах нарушения изоляции показывают диалог одобрения вместо тихого сбоя; пользователь может один раз разрешить заблокированную операцию, не меняя конфигурацию
• Управление из CLI — --sandbox read-only, --sandbox workspace-write, --sandbox full-access
• Переменная окружения — AX_CODE_ISOLATION_MODE

Бэкенды изоляции

{
  "isolation": {
    "mode": "workspace-write",
    "network": false,
    "backend": "auto"
  }
}

Или задайте AX_CODE_ISOLATION_BACKEND=os|auto|app.

Изоляция ОС для bash запрещает запись вне корней рабочей области и запрещает сеть, когда network: false. Проверки слоя приложения всё равно выполняются всегда. На платформах без Seatbelt и bubblewrap используйте backend: "app" или контейнер либо виртуальную машину.

Безопасность сервера

• По умолчанию только localhost — сервер привязывается к 127.0.0.1 и недоступен из сети
• Для доступа из сети нужен пароль — привязка к 0.0.0.0 или любому адресу не localhost требует задать AX_CODE_SERVER_PASSWORD; без этого сервер отказывается запускаться
• Принуждается базовая аутентификация — когда задан AX_CODE_SERVER_PASSWORD, HTTP Basic Auth требуется на всех конечных точках API
• CORS настраивается — дополнительные разрешённые источники можно указать через --cors

Хранение учётных данных

Ключи API провайдеров шифруются при хранении с помощью AES-256-GCM и вывода ключа PBKDF2 и хранятся в локальном каталоге данных AX Code (~/.local/share/ax-code/) с правами файла только для пользователя (0600).

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

Токены OAuth MCP, секреты клиента и токены доступа и обновления аккаунта тоже шифруются при хранении тем же механизмом. Нечувствительные метаданные (URL серверов, метки срока, почта, идентификаторы аккаунтов) остаются открытым текстом.

Проверка артефактов выпуска

И установщик Bash (install), и установщик Windows PowerShell (install.ps1) проверяют скачанные архивы выпуска GitHub с помощью minisign до распаковки. Архивы выпуска и сам скрипт установщика PowerShell несут отсоединённые подписи. Закреплённый публичный ключ выпуска AX Code:

RWSlDu++afxCz01OqhYWhfo8+L8pVbSYXJBEb2zoWBuK0WACIzbGVZRO

Каждый установщик скачивает соответствующий ресурс .minisig для выбранного архива и закрыто отказывает, если проверка не проходит. Если minisign ещё нет в PATH, установщики скачивают закреплённые официальные архивы minisign 0.12 с https://download.ax-code.com/vendor/minisign/0.12/, проверяют SHA-256 архива и снова проверяют извлечённый исполняемый файл перед кэшированием. Двоичный файл minisign, уже лежащий в PATH, — инструмент оператора, и его хеш заново не считается. Задавайте AX_CODE_SKIP_MINISIGN_VERIFY=1, только когда сознательно принимаете загрузку выпуска, которую нельзя проверить.

Удобная однострочная команда irm …/install.ps1 | iex не проверяет скрипт установщика до выполнения. Для установок, чувствительных к безопасности, скачайте install.ps1 и install.ps1.minisig, проверьте скрипт с помощью minisign и запустите его локально (см. Каналы установки и среды выполнения).

Сопровождающим следует держать секретный ключ minisign зашифрованным. Для локальной подписи выпуска в macOS храните парольную фразу в Keychain, а не в файле открытым текстом:

security add-generic-password -U -a ax-release -s ax-minisign -w

Инструменты выпуска читают эту запись Keychain автоматически, когда AX_CODE_MINISIGN_PASSWORD не задан.

Рабочий процесс выпуска GitHub, ведомый тегом, подписывает архивы до загрузки. Ему нужны эти секреты репозитория:

AX_CODE_MINISIGN_SECRET_KEY_B64
AX_CODE_MINISIGN_PASSWORD

AX_CODE_MINISIGN_SECRET_KEY_B64 должен быть содержимым в base64 зашифрованного секретного ключа minisign ax.minisign.key (локальный путь может быть символической ссылкой на ax.sec). Процесс записывает его во временный файл ключа 0600, проверяет закреплённый публичный ключ, подписывает каждый архив выпуска и загружает соответствующие ресурсы .minisig вместе с архивами.

Для архивов CLI macOS процесс требует и импортирует сертификат Apple Developer ID с помощью этих секретов репозитория:

APPLE_CERTIFICATE
APPLE_CERTIFICATE_PASSWORD
APPLE_TEAM_ID
APPLE_API_KEY_B64
APPLE_API_KEY_ID
APPLE_API_ISSUER

На этом пути комплектные нативные библиотеки подписываются импортированной личностью Developer ID Application, ZIP macOS отправляется в службу нотариального заверения Apple, а неизменённый ZIP затем защищается отсоединённой подписью minisign. К архивам ZIP нельзя прикрепить билет, поэтому нотариальное заверение должно произойти до загрузки артефакта и до порождения .minisig. Сборки выпуска закрыто отказывают, если нет любых учётных данных подписи или нотариального заверения Apple.

История ключа подписи выпуска

Ключ подписи выпуска в последний раз сменяли 2026-07-19. Установщик и процесс выпуска закрепляют только текущий ключ, поэтому архивы, подписанные выведенным ключом, не проходят проверку подписи. После смены сопровождающие должны заново подписать исторические архивы выпуска через script/resign-release-assets.ts, чтобы каждый опубликованный выпуск проверялся закреплённым ключом без доверия к выведенным ключам.

Чтобы заново подписать и заново загрузить ресурсы .minisig существующего выпуска текущим ключом:

tsx script/resign-release-assets.ts --tag v5.5.0 --key-dir ~/signkey

Область

В области

Вне области

Возможности безопасности предприятия

AX Code рассчитан на корпоративное использование со следующими средствами укрепления:

• Тонкие разрешения: наборы правил по агенту и по шаблону (allow/deny/ask). Агент безопасности по умолчанию только читает. Правила оцениваются по проекту, агенту и одобренным спискам.
• Журналы аудита сессии: каждый вызов инструмента, решение о разрешении и изменение файла записываются в SQLite со снимками. Поддерживаются воспроизведение, ветвление и экспорт для рецензий соответствия.
• Детерминированный рефакторинг (DRE): impact_analyze, refactor_plan и refactor_apply (теневой worktree плюс линтер, проверка типов и тесты) дают проверяемые обратимые изменения.
• Управление учётными данными: шифрование AES-256-GCM для всех ключей и токенов. Изоляция по каталогам через InstanceState.
• Принуждение песочницы по согласию: изоляция на уровне приложения с разбором команд bash (tree-sitter). Выберите workspace-write или read-only, чтобы принудить границы песочницы; защищённые пути (.git, .ax-code) применяются в режимах песочницы.
• Укрепление сервера: по умолчанию только localhost; удалённый доступ защищён паролем и Basic Auth.
• Понимание кода и сканирование: встроенное обнаружение секретов и жёстко заданных значений, анализ влияния зависимостей.

Обратная связь кодирования с помощью CodeQL

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

Текущий процесс анализирует:

• код среды выполнения, TUI, SDK, интеграции и скриптов на JavaScript и TypeScript;
• рабочие процессы GitHub Actions и локальные составные действия;
• крейты Rust в crates/ с ручной сборкой Cargo, чтобы код нативного дополнения и TUI извлекался согласованно.

Задуманный опыт разработчика:

1. Авторы запросов на слияние получают оповещения CodeQL в сканировании кода GitHub рядом с существующими проверкой типов, детерминированными тестами, сканированием зависимостей OSV и защитами структуры репозитория.
2. Сопровождающие разбирают первые результаты, прежде чем считать CodeQL жёстким шлюзом слияния, чтобы новые находки были полезны, а не шумны.
3. Будущие процессы рецензии и отладки AX Code смогут принимать SARIF CodeQL или оповещения сканирования кода GitHub как явные свидетельства безопасности с полями происхождения вроде source: "codeql", идентификатора правила, серьёзности, файла, строки, трассировки потока данных и SHA проанализированного коммита.
4. Свидетельства CodeQL следует показывать рядом с локальными security_scan, hardcode_scan, диагностикой LSP и анализом влияния с опорой на граф, а не как скрытую замену любому из них.

Добавляя свои запросы CodeQL, предпочитайте границы безопасности, специфичные для репозитория, широким проверкам в стиле линтера. Ценные цели включают пути побега из песочницы, выполнение команд с неочищенными аргументами, обход пути вокруг удержания рабочей области, распространение секретов и окружения в дочерние процессы и отсутствующую проверку маршрутов сервера.

Для полного корпоративного управления (RBAC, политика как код, экспорт в SIEM, криптографический аудит) интегрируйтесь с AX Trust (пункт дорожной карты).

Настройку изоляции и поведение среды выполнения см. в docs/guides/sandbox.md.