🔱 Aquaman

🔱 AIエージェントのための唯一の独立型認証情報プロキシ：独自のボールト分離と最小権限リクエストポリシーを提供。あなたのキーは、エージェントのメモリではなく、既に保管している場所に留まります。1Password、keychain、keepassxcなどに対応。

Claude Code、OpenClaw、Hermesをセットアップしたものの、貴重なAPIキーが平文で.envファイルに置かれている現実に直面している。記事を読んだはずだ。エージェントがプロンプトインジェクションを受けたとき何が起こるかは理解している。

Aquamanは3層の防御でこれを解決します：

プロセス分離：APIキーは別のプロキシプロセス内に存在。エージェントはそれらを一切参照しません。エージェント内でRCEが発生しても認証情報には到達できません。別のアドレス空間にあります。
リクエストポリシー：サービスごとのルールにより、エージェントが呼び出せるエンドポイントを制御。管理APIをブロック、削除を防止、下書きは許可するが送信は拒否。拒否されたリクエストには実際の認証情報が渡されることはありません。
改ざん検出可能な監査：すべての認証情報の使用はSHA-256ハッシュチェーンで記録されます。アクセスされた内容を証明でき、事後の改ざんを検出できます。

自分の道を選ぶ

Aquamanは4つの連携パッケージとして提供され、1つのボールト＋1つのデーモンを共有します。必要なものだけをインストールしてください：

パッケージ	機能	インストールするタイミング
`aquaman-proxy`	コア：ボールト、デーモン、監査、ポリシー、CLI。全員が必要な構成要素。	常に。
`aquaman-plugin`	OpenClaw Gatewayアダプタ。Gateway起動時にプロキシを起動し、チャンネルトラフィックをインターセプト。5つの認証モードで25の組み込みサービス。	OpenClaw Gatewayを運用する場合。https://clawhub.ai/plugins/aquaman-plugin からも入手可能。
`aquaman-coder`	AIコーディングエージェントアダプタ。プロジェクトスコープの`aquaman://service/key`参照をBashツール呼び出しごとに解決。	Claude Code（現時点）を使用する場合。Codex / OpenCode / Cursorは今後対応予定。
`aquaman-hermes`	Hermesエージェントホストプラグイン（Python、PyPIに公開）。Hermesを、ネイティブの`ANTHROPIC_BASE_URL`/`OPENAI_BASE_URL`を介してオプトイン・トークンゲート方式のループバックリスナーに向けます。セッション内に`/aquaman-status`コマンド、ツール、ヘルスプローブを追加。分離はプロキシ側で行われ、プラグインは認証情報を保持しません。	Hermesエージェントホストを実行する場合。`pip install aquaman-hermes`

単一のaquaman CLIですべてを操作可能：vaultとauditのトップレベルコマンド、aquaman openclaw ...（OpenClaw統合用）、aquaman coder ...（コーディングエージェント統合用、内部でaquaman-coderに委譲）、そしてaquaman hermes ...（Hermes Pythonパッケージ用）。

クイックスタート

aquaman help、aquaman doctor を活用しましょう。

1. Vaultのみ（プロキシ＋シークレットのみ）

npm install -g aquaman-proxy
aquaman setup                                # バックエンドウィザード＋キー保存
aquaman daemon &                             # プロキシ起動
aquaman credentials list                     # 確認

プロキシは~/.aquaman/proxy.sock（UDS、chmod 0o600）で待機します。任意のツールをhttp://aquaman.local/<service>/<path>に向けると、プロキシが選択したボールトバックエンドから当該サービスの認証ヘッダを注入します。

2. OpenClaw Gateway

openclaw plugins install aquaman-plugin           # 1. プラグイン＋プロキシをインストール
openclaw aquaman setup                            # 2. バックエンド＋キー＋プラグインの配線
openclaw                                          # 3. 完了 - プロキシが自動起動

トラブルシューティング：openclaw aquaman doctor。

npmを直接使う場合？ npm install -g aquaman-proxy && aquaman openclaw setup でも同じ動作をします。プロキシCLIをインストールし、キーを保存し、プラグインを~/.openclaw/extensions/aquaman-plugin/にインストールし、認証情報を配線します（OpenClaw ≥ 2026.6.5 ではSecretRef参照、旧バージョンではauth-profiles.jsonプレースホルダ）。

プラグインのHTTPインターセプタは、services設定に含まれるサービスのトラフィックのみをリダイレクトします（デフォルトはAnthropic + OpenAI）。openclaw.jsonのプラグイン設定でさらに追加できます。対応チャンネルにはSlack、Discord、Telegram、MS Teams、Matrix、LINE、Twitch、Twilio、BlueBubbles、Mattermost、Nostr、Tlon、Feishu、Google Chat、ElevenLabs、xAI、Cloudflare AI Gateway、Mistral、Hugging Faceなどがあります（全25種）。

3. AIコーディングエージェント（現時点ではClaude Code）

npm install -g aquaman-proxy aquaman-coder        # 1. デーモン＋アダプタをインストール
aquaman setup                                      # 2. vaultウィザード
aquaman daemon &                                   # 3. プロキシ起動

aquaman coder project add my-app --path ~/code/my-app \
  --env ANTHROPIC_API_KEY=aquaman://anthropic/api_key \
  --env GITHUB_TOKEN=aquaman://github/token         # 4. プロジェクトを宣言
aquaman coder setup claude-code                    # 5. Claude Codeフックを配線
aquaman doctor                                     # 6. 確認 - vaultとcoder両方が緑色になるはず

実際に見てみましょう（30秒のaha体験）： Claude Codeを再起動し、~/code/my-app内で新しいセッションを開き、エージェントに以下を実行するよう依頼します：

printenv | grep ANTHROPIC_API_KEY

トランスクリプトに次のように表示されます：

ANTHROPIC_API_KEY=[REDACTED:injected-value]

⏺ ANTHROPIC_API_KEY is set and available (injected via aquaman vault).

子プロセスは実際のキーを見ることができます（テスト、ビルド、MCPサーバー、インポートスクリプトなど、実際にキーを必要とするすべての処理が動作します）。エージェント（マシン上で実行するコードを決定する存在）はその値を決して見ません。したがって、会話履歴、モデルプロバイダのログ、後で端末のスクリーンショットを撮った誰もがその値を目にすることはありません。

自分の端末からも使用できます。 同じラッパーがエージェントなしでも機能します。カバーされたプロジェクトにcdしてコマンドの前に付けるだけです：

cd ~/code/
aquaman-coder exec -- python app/scripts/import.py

同じ環境変数の注入、同じstdout/stderrの編集が行われます。Makefileのターゲット、シェルエイリアス、CIランナーなど、.envファイルを使いたくなるあらゆる場面で使用できます。

Claude Codeが~/code/my-app内でBashツールを実行すると、aquamanのフックはupdatedInput.commandを経由してコマンドを書き換え、aquaman-coder execでラップします。そのラッパーは：

各aquaman://service/key参照をブローカー経由で解決します（UDS上のPOST /broker/resolve）。認証情報は1つのコマンドのために具体化され、エージェントの生存期間中は保持されません。
stdout/stderrを編集パイプに通し、解決された各値に対して値ベースのパターンを先頭に追加します。注入された文字列は、その形状に関係なく編集されます（Atlassianトークン、Notionシークレット、内部APIキーなど、既知のプロバイダ形式に一致する必要はありません）。さらに、汎用的な形状ベースのパターン（sk-ant-、ghp_、sk_live_、AKIA…、JWT、PEMブロック、ATATT3xF…）も、子プロセスが自ら露出したシークレットに対する防御層として事後的に実行されます。
コマンド終了時にクリーンアップします。

4. Hermes（エージェントホスト）

Hermesは外部（Python）ホストであり、トランスポートフックを注入する手段がないため、分離はプロキシ側で行われます。プロキシはオプトインのトークンゲートループバックリスナーを公開し、Hermesは独自の環境変数を介してそのリスナーに向けられます。

npm install -g aquaman-proxy                       # 1. デーモンをインストール
aquaman setup                                      # 2. vaultウィザード
aquaman credentials add anthropic api_key sk-ant-... # 3. プロバイダキーを保存

aquaman hermes setup                               # 4. ループバックを有効化＋~/.hermes/.envを書き込み
aquaman daemon &                                   # 5. プロキシ起動（UDS＋ループバック）
aquaman hermes doctor                              # 6. 確認 - リスナー、env、vault、Hermes

aquaman hermes setupはループバックリスナーを有効化し、インストールごとのトークンを生成し、~/.hermes/.env（HERMES_HOMEを尊重）にaquaman管理ブロックを書き込みます。そのブロックには、ネイティブのANTHROPIC_BASE_URL/OPENAI_BASE_URLと、トークンを値とするプレースホルダとしてのapi_keyが含まれます。Hermesはそのトークンをプロバイダキーとして送信し、プロキシがそれを取り除き、実際のボールト認証情報を注入して上流に転送します。現在対応しているのはLLMプロバイダ（Anthropic、OpenAI）のみです。

オプションのセッション内機能 - PythonプラグインはHermes内に/aquaman-statusコマンド、aquaman_statusツール、セッション開始時のヘルスプローブを追加します（認証情報は保持しません）：

pip install aquaman-hermes            # または: uv tool install aquaman-hermes
aquaman-hermes install                # プラグインを~/.hermes/plugins/aquaman/に配置
hermes plugins enable aquaman

動作の仕組み

Agent / OpenClaw / Coding Agent             Aquaman Proxy
┌──────────────────────┐                    ┌──────────────────────┐
│                      │                    │                      │
│  ANTHROPIC_BASE_URL  │═══ UDS / HTTP ════>│  Keychain / 1Pass /  │
│  = aquaman.local     │                    │  Vault / Encrypted   │
│                      │<══════════════════ │                      │
│  fetch() interceptor │═══ broker:resolve  │  + Policy enforced   │
│   (channel APIs)     │                    │  + Auth injected:    │
│                      │                    │    header / url-path │
│  No credentials.     │  ~/.aquaman/       │    basic / oauth     │
│  No open ports.      │  proxy.sock        │                      │
│  Nothing to steal.   │  (chmod 0o600)     │                      │
└──────────────────────┘                    └──┬─────────┬─────────┘
                                               │         │
                                               │         ▼
                                               │  ~/.aquaman/audit/
                                               │  (hash-chained)
                                               ▼
                                     api.anthropic.com
                                     api.telegram.org
                                     slack.com/api …

保存：認証情報は、あなたが既に運用しているボールトバックエンド（Keychain、1Password、HashiCorp Vault、Bitwarden、KeePassXC、systemd-creds、暗号化ファイル）に保存されます。Aquaman自体は認証情報を保持しません。
ポリシー：プロキシは認証情報にアクセスする前に、メソッド＋パスのルールをチェックします。拒否されたリクエストは403を返し、実際の認証ヘッダは渡されません。
注入：プロキシは認証情報を検索し、転送前に認証ヘッダを追加します。25の組み込みサービス、4つの注入認証モード（ヘッダ、URLパス、HTTP Basic、OAuth）。5番目のnoneは保存専用で、プロキシはトラフィックを拒否します。
ブローカー（coderパス）：POST /broker/resolveはツール呼び出しごとに認証情報を具体化し、単一コマンドの環境にスコープし、その後失効します。
監査：すべての認証情報の使用はSHA-256ハッシュチェーンで記録されます。

エージェントは常にセンチネルホスト名（aquaman.local）またはプレースホルダマーカー（aquaman-proxy-managed）だけを認識します。実際のキーを見ることは決してなく、他のプロセスが調査できるTCPポートも開いていません。

セキュリティモデル

レイヤー	機能	防止する脅威
プロセス分離	認証情報は別プロセスに格納され、Unixドメインソケット（`chmod 0o600`）で接続	侵害されたエージェントがキーを読み取れない - 別のアドレス空間、TCPポートなし
サービス許可リスト	`proxiedServices`でエージェントがアクセスできるAPIを制御	許可していないサービスにエージェントが通信できない
リクエストポリシー	サービスごとのメソッド＋パスルール、認証情報注入前に強制	エージェントはAnthropicにアクセスできるが管理APIには不可；メールの下書きは可能だが送信は不可
監査証跡	SHA-256ハッシュチェーンによる認証情報使用の記録	インシデント後のフォレンジック、改ざん検出、コンプライアンス証拠
ツール呼び出しごとのブローカー（coder）	`aquaman-coder exec`がコマンドごとに認証情報を具体化	認証情報がエージェントのシェル環境に拡散しない
出力編集（coder）	`aquaman-coder exec`がstdout/stderrを編集パイプに通し、注入した各値をそのまま除去。さらに汎用プロバイダパターンをフォールバックとして実行	形状不定の認証情報でもエージェントのトランスクリプトに到達しない

詳細なモデル（統合ごとの詳細：HTTPインターセプターのスコープ、認証プロファイル、スキャナー結果、ClawScanパブリッシャーノート）は packages/plugin/README.md および packages/coder/README.md にあります。

コンプライアンス態勢

Aquamanには、以下のフレームワークに対応した実行可能な適合テストが test/compliance/ の下に含まれています：

MITRE ATLAS v5.4.0：技術AML.T0055、T0012、T0062、T0090、T0098（test/compliance/atlas/）
NIST SP 800-53 Rev 5：IA-5、AC-3、AC-6、AU-2/9/10、SC-12/28、SI-10（test/compliance/nist/）

さらに、CISA/Five-Eyes「エージェント型AIサービスの慎重な採用」（2026年4月）、CSA MAESTRO、OWASP Top 10 for Agentic Applicationsへのアラインメントの説明も含みます。テストはnpm testの一部として実行されます。マッピングについてはdocs/compliance/を参照してください。

リクエストポリシー

OAuthスコープでは「メールを下書きする」と「メールを送信する」を区別できません。どちらもgmail.sendです。リクエストポリシーがそのギャップを埋めます。

# ~/.aquaman/config.yaml
policy:
  anthropic:
    defaultAction: allow
    rules:
      - method: "*"
        path: "/v1/organizations/**"
        action: deny          # block admin/billing API
  openai:
    defaultAction: allow
    rules:
      - method: "*"
        path: "/v1/organization/**"
        action: deny
      - method: DELETE
        path: "/v1/**"
        action: deny          # no deletions
  slack:
    defaultAction: allow
    rules:
      - method: "*"
        path: "/admin.*"
        action: deny
  gmail:
    defaultAction: allow
    rules:
      - method: POST
        path: "/v1/users/*/messages/send"
        action: deny          # drafts ok, sending blocked

ポリシーなし＝すべて許可（後方互換性あり）
最初に一致したルールが優先：ルールは上から順に評価され、一致しないリクエストはdefaultActionにフォールスルー
認証前に拒否：ブロックされたリクエストには実際の認証情報が渡されない
パスグロブ：*はセグメント内の文字に一致、**は0個以上のセグメントに一致
aquaman setupは保存されたサービス（anthropic、openai、slack、gmail）に対して安全なデフォルトを適用します。
aquaman policy list / aquaman policy test <svc> <method> <path> で検査・ドライランが可能です。

認証情報バックエンド

自分のボールトを持ち込んでください - aquamanは独自のストアを持ちません。既に運用しているバックエンドを選択してください。シークレットはそこに留まり、プロキシはその場で読み取ります。

バックエンド	最適な用途	セットアップ
`keychain`	macOSでのローカル開発（デフォルト）	そのまま動作
`encrypted-file`	Linux、WSL2、CI/CD	AES-256-GCM、パスワード保護
`keepassxc`	既存のKeePassユーザー	`AQUAMAN_KEEPASS_PASSWORD`またはキーファイルを設定
`1password`	チームの認証情報共有	`brew install 1password-cli && op signin` — 無人エージェントにはサービスアカウントを使用（`OP_SERVICE_ACCOUNT_TOKEN`）
`vault`	エンタープライズシークレット管理	`VAULT_ADDR` + `VAULT_TOKEN`を設定
`systemd-creds`	systemd ≥ 256のLinux	TPM2バックアップ、root不要
`bitwarden`	Bitwardenユーザー	`bw login && export BW_SESSION=$(bw unlock --raw)`

aquaman setupは適切なデフォルトを自動検出します（macOS → keychain；Linux → keychain（libsecretがある場合）、さもなければ systemd-creds（systemd ≥ 256の場合）、さもなければ encrypted-file）。

encrypted-fileは、ネイティブのキーリングがないヘッドレスLinux/CI環境のための最終手段です。Linuxでより高いセキュリティを求める場合は、libsecret-1-dev（GNOME Keyring）をインストールするか、systemd-creds（TPM2バインディング）、または1Password/Vaultを使用してください。

認証情報キャッシュ（v0.13.1以降）

アクセスごとにコストがかかるバックエンド — 1password（デスクトップアプリモードでは1回の読み取りごとにバイオメトリックプロンプト）、bitwarden（約1〜2秒のCLI起動）、vault（HTTPラウンドトリップ） — はデフォルトで15分間デーモンのメモリ内にキャッシュされます。これにより、ビジーなエージェントセッションではリクエストごとではなく、ウィンドウごとに1回ボールトをロック解除するだけで済みます。他のバックエンドは十分に高速か内部的にキャッシュしているため、デフォルトではキャッシュはオフになっています。~/.aquaman/config.yamlのcredentials.cacheTtlSeconds（またはAQUAMAN_CACHE_TTL）で調整できます。0で無効化。

正直なトレードオフ：アクセスごとのバイオメトリックプロンプトはユーザー存在確認であり、キャッシュはTTLウィンドウの間、アクセスごとの存在確認を削除します。無人エージェントではそのプロンプトは決して応答されず、平文の.envのためにボールトが放棄されることになり、これは厳密にはより悪い状態です。キャッシュは分離境界を移動させるものではありません。値はプロキシプロセス内（すでにすべてのリクエストで転送される場所）にのみ存在し、ディスクに書き込まれることはなく、aquaman credentials addでローテーションすると直ちに無効化されます。書き込みは常にボールトへ行われます。適合テストはtest/compliance/cache-residency.test.tsで行われています。1Passwordでプロンプトをゼロにするには、aquamanボールトにスコープされたサービスアカウントを使用してください — aquaman doctorがその方法を案内します。

ライセンス

MIT - LICENSEを参照してください。

aquaman v0.14.1

カテゴリ