コマンドリファレンス

trustless secret — 認証情報ストア操作

get の出力（デフォルトJSON）:

{"key": "github_token", "value": "ghp_..."}

trustless oauth — OAuth 認証情報管理

Google / Lark などのプロバイダ向けに OAuth 認証情報（RFC 8628 デバイスフロー + refresh grant）を管理します。trustless oauth login はデバイス認可フローを実行し、得られたトークンをコンパクトな単一行 JSON エントリ（type=oauth）として認証情報バックエンドに保存します。このエントリは他の認証情報と同じように解決され — trustless run -s <key> / trustless proxy は有効なアクセストークンを返し、期限切れ時は自動でリフレッシュします。

login は確認 URL を stdout に出力し、ユーザーの承認をポーリングします:

$ trustless oauth login google api/google
https://oauth2.googleapis.com/device/code?user_code=ABCD-1234   # ブラウザで開く
{"key":"api/google","provider":"google","expires_at":"2026-08-13T12:00:00Z"}

refresh は期限切れを待たずにアクセストークンを強制リフレッシュします。アクセストークンの値が出力されることはありません。status はトークンが有効な間 valid、リフレッシュトークンが失効している場合（invalid_grant）reauth_required を報告します:

$ trustless oauth status api/google
{"key":"api/google","provider":"google","expires_at":"...","status":"valid"}

設定（[oauth.providers]）: プロバイダのトークン/デバイスエンドポイントと認証情報を定義します。組み込みの google と lark 定義は以下のエンドポイントが同梱されており、client_id / client_secret（プロバイダの開発者コンソールでアプリ登録）と追加スコープを埋めるだけで使えます:

[oauth.providers.google]
client_id = "YOUR_CLIENT_ID"
client_secret = "YOUR_CLIENT_SECRET"
scopes = ["https://www.googleapis.com/auth/gmail.readonly"]

[oauth.providers.lark]
client_id = "YOUR_CLIENT_ID"
client_secret = "YOUR_CLIENT_SECRET"
# scopes 未設定時は既定の offline_access が使われる（refresh token 取得に必須）

client_id / client_secret はプロバイダの開発者コンソール（Google Cloud Console / Lark Open Platform）で登録したものを使います — 絶対にコミットしないでください。バックエンドに保存されるのはトークンのみで、クライアント認証情報は保存されません。

trustless audit — 構造化監査ログ

すべてのイベント（proxy 注入/拒否、run 起動、DLP 秘匿化、OAuth リフレッシュ/失敗/再認証）が JSONL で記録されます。イベントにトークンやシークレットの値が現れることはありません — キー名・ホスト・判定・最小限の詳細のみです。

[audit]
sink = "file"        # "journald" | "file" | "off"（未設定はコマンド別デフォルト）
file = "~/.local/state/trustless/audit.jsonl"
buffer = 1024

$ journalctl --user -u trustless | grep '"event"'
{"ts":"...","event":"proxy.inject","key":"edinet","host":"api.edinet-fsa.go.jp","verdict":"inject","detail":"header=Ocp-Apim-Subscription-Key"}
{"ts":"...","event":"oauth.refresh","key":"iria/api/lark-oauth","verdict":"refresh","detail":"provider=lark"}

イベント: proxy.inject / proxy.deny / run.spawn / dlp.redact / oauth.refresh / oauth.fail / oauth.reauth_required。

注意:

• アクセストークンはメモリにキャッシュされます（有効期限から60秒の安全マージンを引いた期間）。期限切れ時は Resolve で自動リフレッシュされます。
• プロバイダがリフレッシュトークンをローテーションする場合（Lark）、更新エントリは CAS ガード付きで書き戻されるため、並行書き込みで上書きされることはありません。
• invalid_grant（リフレッシュトークン失効）はリトライされません — 再認証するには trustless oauth login を再実行してください。

trustless run — サブプロセス認証情報注入（中核機能）

1つ以上の認証情報を環境変数としてサブプロセスに注入して実行します。 注入された値は呼び出し元に一切返らず、サブプロセスの stdout/stderr だけが返ります。出力に含まれる認証情報パターンは自動的に [REDACTED] に置換されます。

trustless run -s iria/api/xai -- curl -s https://api.x.ai/v1/models
trustless run -s GITHUB_TOKEN -s OPENAI_KEY -- gh pr list

セキュリティ機能:

• --scan-args（デフォルト: true）: サブプロセス起動前に全コマンド引数をスキャンし、認証情報パターンや注入値を検出したら exit code 3 でブロック（fail closed）。curl -H "Authorization: Bearer sk-..." のような引数経由の露出を防止。
• --sanitize（デフォルト: true）: サブプロセス出力の認証情報パターンをスキャン・Redact。
• ポリシーエンジン: コマンド単位のアクセス制御（設定セクション参照）。

trustless proxy — HTTPフォワードプロキシ（認証情報置換）

__KEY_NAME__ 形式のプレースホルダーを実際の認証情報に置換するローカルHTTPフォワードプロキシを起動します。

trustless proxy start --port 8080
trustless proxy start --port 8080 --mitm  # HTTPSインターセプションモード

エージェントのプロキシ設定:

export HTTPS_PROXY=http://127.0.0.1:8080

プレースホルダー形式: __KEY_NAME__（大文字アンダースコア区切り）。 解決順: 小文字キーで pass 検索 → フォールバック: iria/api/小文字キー

MITMモード（--mitm）:

• HTTPS通信をインターセプトし、暗号化されたリクエスト内のプレースホルダーも置換

• 初回起動時にルートCA証明書を自動生成（~/.config/trustless/trustless-ca.{crt,key}）

• ホスト名ごとにエフェメラル証明書を生成（24時間有効、ECDSA P-256）

• システム全体で証明書を有効にするには:

  sudo cp ~/.config/trustless/trustless-ca.crt /usr/local/share/ca-certificates/
  sudo update-ca-certificates
  

trustless dlp — 送信DLPリバースプロキシ（旧 dlp-proxy 統合）

trustless dlp は旧 github.com/ikkun1222/dlp-proxy の後継サブコマンド。LLM API へのリクエスト本文を既知秘密（bitwarden / pass）と照合し <redacted> に置換する送信 DLP を提供する。

trustless dlp start -config ~/.config/dlp-proxy/config.json   # リバースプロキシ起動（既定 127.0.0.1:8787）
trustless dlp scrub-db  <db-path> [--apply] [--backup]        # SQLite DB の秘密スキャン / スクラブ
trustless dlp scrub-text <path>   [--apply]                   # テキスト / ディレクトリのスキャン / スクラブ

• config スキーマは旧 dlp-proxy と同一（JSON）: listen / min_secret_len / secrets_source（pass | bitwarden・既定 pass）/ secrets_refresh_interval（必須・例 "10m"）/ routes（prefix → upstream URL）
• 秘密ロードは共通 backend 経由（backend.Values）— 旧 bitwardenloader/passstore は廃止
• fail-closed: 起動時の秘密ロード失敗は即終了（無防備で走らない）。リロード失敗時は既存セット維持 + WARN（fail-safe）
• ホットリロード: secrets_refresh_interval の定期リロード + SIGHUP で即時リロード
• 旧 dlp-proxy リポジトリは凍結（2026-08-13・trustless dlp に統合）

Scrub コマンド — すでにディスクに残ってしまったシークレット（エージェントのセッションDB・ログ・ダンプ）を、稼働中のプロキシと同じ二層脱敏で掃除します:

trustless dlp scrub-db  ~/.local/state/hermes/sessions.db            # dry-run: スキャンのみ
trustless dlp scrub-db  ~/.local/state/hermes/sessions.db --apply    # 変更を書き込む
trustless dlp scrub-db  ~/.local/state/hermes/sessions.db --apply --backup  # 先に .bak コピーを残す
trustless dlp scrub-text ~/.hermes/sessions --apply                  # テキストファイル/ディレクトリを掃除

• デフォルトは dry-run: どちらのコマンドもテーブル/ファイルごとのヒット数を表示するだけで書き込みません。実際に掃除するには --apply を追加。scrub-db はさらに --backup（書き込み前に <db>.bak へコピー）と --min-len（最小シークレット長、デフォルト8）を受け付けます。
• scrub-db は SQLite データベースを対象に: Layer 1 の既知値置換 + Layer 2 のパターンマスクを行い、その後 FTS 仮想テーブルを再構築し VACUUM を実行するため、ファイルに物理的な残骸が残りません（テストで検証済み）。
• scrub-text はファイル/ディレクトリツリー（エージェントの sessions/・ログ・ダンプ）を同じ二層脱敏で走査します。
• どちらも DLP 設定の secrets_source（pass / bitwarden）からシークレットを読み込み、pattern_mode を尊重します — "log" はマスクせずヒット数だけ数え、"mask" はその場で秘匿化します。

trustless setup — 初回セットアップウィザード

初回セットアップを自動化する対話型ウィザード:

trustless setup

4ステップの流れ:

スキルインストール先:

インストールされるスキルは、AIエージェントにcredential管理のルール（trustless run で注入、trustless secret set で登録、平文保存禁止）を教えます。

オプション:

対応エージェント: OpenCode、Claude Code、Codex、Hermes。

trustless doctor — システムヘルスチェック

trustlessのセットアップ全体を検証する診断ツール:

trustless doctor           # 人間が読める形式で出力
trustless doctor --json    # JSON出力（cron/SIEM連携用）
trustless doctor --fix     # 検出された問題を自動修復（スタブ）

チェック項目: GPG鍵の有効性、passストアの状態、gpg-agentの応答、.envファイルのセキュリティ、エージェント連携状況、MITM CA証明書のインストール状態。

trustless config — 設定管理

設定キー:

設定ファイル: ~/.config/trustless/config.toml（TRUSTLESS_CONFIG 環境変数で上書き可能）

backend = "pass"
output = "json"

run_defaults = { sanitize = true, timeout = "5m" }

[proxy]
port = 8080

[sanitize]
patterns = [
  "(sk_live|sk_test)_[A-Za-z0-9]+",
  "(ghp|gho|ghu|ghs)_[A-Za-z0-9_]+",
  "Bearer [A-Za-z0-9._-]+",
]

[policy.default]
denied_commands = ["sh", "bash", "zsh"]

[[policy.overrides]]
secret_key = "iria/api/xai"
denied_commands = ["curl"]

trustless completion — シェル補完

bash、zsh、fish の補完スクリプトを生成:

trustless completion bash > /etc/bash_completion.d/trustless
trustless completion zsh > /usr/local/share/zsh/site-functions/_trustless
trustless completion fish > ~/.config/fish/completions/trustless.fish

trustless version — バージョン情報

trustless version