このページは英語版ドキュメントの翻訳です。コマンド、識別子、例はそのままです。ランタイム 7.24.4 · SDK 2.6.7。 英語版

セキュリティ方針

サポートされる版

セキュリティ修正を受け取るのは、最新のマイナー系列だけです。より古い系列の脆弱性を報告する前に、現在のマイナーへアップグレードしてください。

脆弱性を報告する

私たちはセキュリティを真剣に扱います。脆弱性を発見した場合は、責任を持って報告してください。

1. 非公開の連絡: AutomatosX の連絡経路 を使い、機密のセキュリティ報告ルートを依頼してください。公開のコミュニティメッセージに、攻撃の詳細や認証情報を含めないでください。
2. Discord: 私たちの Discord で報告してください: https://discord.gg/gf9UyPxaN2

報告は 6 営業日 以内に受領を伝え、修正に向けた進捗をお知らせします。

注: AI が生成したセキュリティ報告は受け付けません。提出すると、プロジェクトから追放されます。報告には具体的な再現手順を含め、実際の影響を示してください。

脅威モデル

概要

AX Code は、あなたのマシン上でローカルに動く、AI を使ったコーディング支援です。シェル実行、ファイル操作、ウェブアクセスを含む強力なツールへアクセスするエージェントシステムを提供します。

ランタイム隔離の既定は full-access（サンドボックスオフ）で、ファイルシステム書き込みとネットワークアクセスは制限されません。これは信頼されたローカルプロジェクトのための便宜の姿勢であり、セキュリティ境界ではありません。信頼できないリポジトリや無人の作業負荷で AX Code を使う前に、workspace-write または read-only を選んでください。

実行隔離サンドボックス

AX Code には、AI エージェントがアクセスできるものを制限する、組み込みの実行隔離サンドボックスがあります。3 つのモードが使えます。

主な性質:

• 既定の挙動 — AX Code は full-access で開始します。--sandbox、AX_CODE_ISOLATION_MODE、または設定が別のモードを設定しない限り、そうなります
• 推奨される制限モード — 信頼できないリポジトリやチームのリポジトリには workspace-write を使います。書き込みをワークスペースに閉じ込め、ネットワークを既定で無効にします
• ツール単位の強制 — すべての変更ツール（bash、edit、write、apply_patch）とネットワークツール（webfetch、websearch、codesearch）は、実行前に隔離方針を検査します
• 保護されたパス — .git と .ax-code のディレクトリは、ワークスペース書き込みモードでも、書き込みから常に保護されます
• 昇格プロンプト — 制限モードでは、隔離違反は黙って失敗せず、承認ダイアログを出します。利用者は設定を変えずに、遮断された操作を 1 回だけ許可できます
• 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 の OS 隔離は、ワークスペースルートの外への書き込みを拒否し、network: false のときネットワークを拒否します。アプリ層の検査は常に走ります。Seatbelt や bubblewrap がないプラットフォームでは、backend: "app" またはコンテナ / VM を使います。

サーバーのセキュリティ

• 既定ではローカルホストのみ — サーバーは 127.0.0.1 に束縛され、ネットワークからは到達できません
• ネットワークアクセスにはパスワードが必要 — 0.0.0.0 またはローカルホスト以外のアドレスへ束縛するには AX_CODE_SERVER_PASSWORD の設定が必要です。それがないとサーバーは起動を拒否します
• Basic 認証が強制される — AX_CODE_SERVER_PASSWORD が設定されているとき、すべての API エンドポイントで HTTP Basic 認証が必要です
• CORS は設定可能 — 追加で許すオリジンは --cors で指定できます

認証情報の保存

プロバイダーの API キーは、PBKDF2 による鍵導出を伴う AES-256-GCM で保存時に暗号化され、ローカルの AX Code データディレクトリ（~/.local/share/ax-code/）に、ユーザーだけのファイル権限（0600）で保存されます。

暗号化鍵は、ローカルマシンの属性（ホスト名、プラットフォーム、アーキテクチャ）から導出されます。これは偶発的なオフライン開示（たとえば誤ったファイル共有）から守りますが、ホストへアクセスできる決意した攻撃者からは 守りません。OS のキーチェーンやハードウェアに裏打ちされた秘密情報の保管と同等ではありません。

MCP の OAuth トークン、クライアント秘密、アカウントのアクセスおよび更新トークンも、同じ仕組みで保存時に暗号化されます。機密でないメタデータ（サーバー URL、期限のタイムスタンプ、メール、アカウント ID）は平文のままです。

リリース成果物の検証

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 を確認し、キャッシュする前に抽出した実行ファイルを再度確認します。PATH にすでにある minisign バイナリは運用者のツールであり、再ハッシュされません。検証できないリリースのダウンロードを意図的に受け入れるときだけ AX_CODE_SKIP_MINISIGN_VERIFY=1 を設定します。

便宜の 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

AX_CODE_MINISIGN_PASSWORD が設定されていないとき、リリースツールはその Keychain 項目を自動で読みます。

タグ駆動の GitHub リリースワークフローは、アップロード前にアーカイブへ署名します。次のリポジトリ秘密が必要です。

AX_CODE_MINISIGN_SECRET_KEY_B64
AX_CODE_MINISIGN_PASSWORD

AX_CODE_MINISIGN_SECRET_KEY_B64 は、暗号化された ax.minisign.key の minisign 秘密鍵の内容を base64 符号化したものでなければなりません（ローカルパスは ax.sec へのシンボリックリンクであることがあります）。ワークフローはそれを一時的な 0600 鍵ファイルへ書き、ピン留めされた公開鍵を検証し、各リリースアーカイブに署名し、対応する .minisig 資産をアーカイブとともにアップロードします。

macOS CLI アーカイブについて、ワークフローは次のリポジトリ秘密を使って 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 の同一性で署名され、macOS の ZIP が 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 と lint、型検査、テスト）が、監査でき可逆な変更を提供します。
• 認証情報の管理: すべてのキーとトークンに対する AES-256-GCM 暗号化。InstanceState によるディレクトリごとの隔離。
• オプトインのサンドボックス強制: bash コマンド解析（tree-sitter）を伴うアプリケーションレベルの隔離。サンドボックス境界を強制するには workspace-write または read-only を選びます。保護パス（.git、.ax-code）はサンドボックスモードで適用されます。
• サーバーの強化: 既定ではローカルホストのみ。Basic 認証付きのパスワード保護されたリモートアクセス。
• コード知能と走査: 組み込みの秘密情報とハードコードの検出、依存関係の影響分析。

CodeQL を補助にしたコーディングのフィードバック

リポジトリは、プルリクエスト、dev への push、スケジュールされた走査、手動の起動に対する背景のセキュリティ分析層として CodeQL を走らせます。CodeQL はライブの LSP やコード知能の経路の一部ではありません。データフロー、汚染、セキュリティ品質の所見のための、より遅くより深い証拠源であり、ソース変更が安定したあとに扱う方が向いています。

現在のワークフローが分析するのは次のとおりです。

• JavaScript と TypeScript のランタイム、TUI、SDK、連携、スクリプトのコード。
• GitHub Actions のワークフローとローカルの複合アクション。
• crates/ の下にある Rust クレート。ネイティブアドオンと TUI のコードが一貫して抽出されるよう、手動の Cargo ビルドを使います。

意図された開発者体験は次のとおりです。

1. PR の著者は、既存の型検査、決定的テスト、OSV の依存関係走査、リポジトリ構造のガードとともに、GitHub のコード走査で CodeQL アラートを受け取ります。
2. メンテナーは、CodeQL を硬いマージ関門として扱う前に初期結果を選別し、新しい所見がノイズではなく役立つようにします。
3. 将来の AX Code のレビューやデバッグの流れは、CodeQL の SARIF または GitHub のコード走査アラートを、出自フィールド付きの明示的なセキュリティ証拠として取り込めます。たとえば source: "codeql"、規則 ID、重大度、ファイル、行、データフローの追跡、分析されたコミット SHA です。
4. CodeQL の証拠は、ローカルの security_scan、hardcode_scan、LSP 診断、グラフに裏打ちされた影響分析のそばに示されるべきであり、それらの隠れた置き換えではありません。

独自の CodeQL クエリを追加するときは、広い lint 風の検査より、リポジトリ固有のセキュリティ境界を優先してください。価値の高い対象には、サンドボックス脱出経路、サニタイズされていない引数でのコマンド実行、ワークスペース封じ込めの周囲のパストラバーサル、子プロセスへの秘密情報や環境の伝播、欠けているサーバー経路の検証が含まれます。

完全な企業ガバナンス（RBAC、コードとしての方針、SIEM エクスポート、暗号学的監査）には、AX Trust（ロードマップ項目）と統合してください。

隔離の設定とランタイム挙動は docs/guides/sandbox.md を参照してください。