セキュリティモデル

trustless が保証すること

  1. 認証情報の値がLLMコンテキストに入らない

    • run: 環境変数としてサブプロセスにのみ注入、出力はスキャン・Redact
    • proxy: プロキシプロセス内部で置換、agent はAPI応答のみ見える
    • secret get: 値を出力するが明示的な呼び出しが必要（通常ワークフローでは使われない）

  2. コマンド引数スキャン（--scan-args）

    • サブプロセス起動前に全コマンド引数をスキャン
    • 認証情報パターンや注入値を検出したら exit code 3 でブロック（fail closed）
    • エージェントが curl -H "Authorization: Bearer sk-..." のように引数に認証情報を埋め込むのを防止

  3. ポリシーエンジン — コマンド単位のアクセス制御

    • policy.default.denied_commands: 危険なコマンドをグローバルに禁止（例: sh, bash）
    • policy.<key>.denied_commands: 認証情報ごとに特定コマンドを禁止
    • Fail-closed: ポリシー違反は exit code 3 でブロック

  4. サブプロセス出力サニタイズ

    • デフォルトパターン: GitHub tokens, OpenAI keys, xAI keys, AWS keys, Bearer tokens 他
    • 注入値自体もパターンスキャン: サブプロセスが認証情報をエコーしても Redact
    • カスタムパターンは設定ファイルまたは --sanitize-policy で追加

  5. 最小攻撃表面

    • プロキシはデフォルトで 127.0.0.1 のみ待受
    • Unixソケットモード対応（ファイルパーミッション制御）
    • MITMプロキシはホスト名ごとにエフェメラル証明書（24時間有効）
    • 単一静的バイナリ、ランタイム依存無し（既存の pass+gpg ストアを読む。bitwarden バックエンドは追加で bw CLI が必要）

  6. ブローカープロセス内に認証情報を永続化しない

    • 認証情報はオンデマンド解決、サブプロセス終了後に解放
    • HTTPプロキシはアクティブなリクエスト処理中のみメモリに保持

v1 で対応していないこと

  • 動的/ローテーション認証情報 — pass store は静的。ローテーションは外部で
  • 完全な監査証跡 — 基本ログのみ。SIEM連携は将来対応
  • ハードウェアバックアップ鍵 — GPGキーリングのセキュリティに依存
  • HTTPS MITM CA管理 — MITMプロキシはCA証明書を生成するが、OSのトラストストアへのインストールはユーザー作業

← Docs