janee

Janee 🔐

MCP による AI エージェント向けのシークレット管理

AI エージェントが役立つためには API アクセスが必要です。しかし、エージェントに生の API キーを持たせるべきではありません。 Janee はエージェントと API の間に位置し、認証情報を注入し、ポリシーを適用し、すべてをログに記録します。

✨ 機能

🔒 ゼロ知識エージェント	エージェントはキーを一切見ることなく API を呼び出せます
📋 完全な監査証跡	すべてのリクエストをタイムスタンプ、メソッド、パス、ステータスとともに記録
🛡️ リクエストポリシー	ケイパビリティごとの許可/拒否ルール（例: 読み取り専用の Stripe）
⏱️ セッション TTL	時間制限付きアクセスと即時失効
🔌 あらゆる MCP クライアントで動作	Claude Desktop、Cursor、OpenClaw など
🏠 ローカルファースト	キーはお使いのマシン上で暗号化され、クラウドには送信されません
🖥️ Exec モード	認証情報を注入して CLI ツールを実行 — エージェントはキーを見ることができません
🤖 GitHub App 認証	自律型エージェント向けの短命トークン — 静的な PAT は不要
🐦 Twitter/X OAuth 1.0a	リクエストごとの OAuth 署名 — 4 つのシークレットは暗号化されたまま
☁️ AWS SigV4	サーバーサイドで AWS API リクエストに署名 — SES、S3 など
🔧 自動 git 認証	認証情報に GitHub トークンが含まれていれば git push/pull がそのまま動作します

---

課題

AI エージェントが役立つためには API アクセスが必要です。現在のアプローチは、エージェントにキーを渡し、適切に振る舞うことを願うというものです。

• 🔓 エージェントは Stripe、Gmail、データベースへの完全なアクセス権を持ちます
• 📊 何にアクセスしたか、なぜアクセスしたかの監査証跡がありません
• 🚫 問題が発生したときのキルスイッチがありません
• 💉 プロンプトインジェクション一つで大惨事になりかねません

---

解決策

Janee は、AI エージェント向けに API シークレットを管理する MCP サーバーです:

1. API キーを保存 — ~/.janee/ にローカルで暗号化
2. janee serve を実行 — MCP サーバーが起動します
3. エージェントがアクセスを要求 — execute MCP ツール経由
4. Janee が実際のキーを注入 — エージェントは決して見ることができません
5. すべてがログに記録される — 完全な監査証跡

キーはお使いのマシン上に留まります。エージェントは決して見ることができません。制御はあなたが握ります。

---

一度設定すれば、どこでも使える

Janee で API を一度設定するだけ:

services:
  stripe:
    baseUrl: https://api.stripe.com
    auth: { type: bearer, key: sk_live_xxx }
  github:
    baseUrl: https://api.github.com
    auth: { type: bearer, key: ghp_xxx }
  openai:
    baseUrl: https://api.openai.com
    auth: { type: bearer, key: sk-xxx }

これで、Janee に接続するすべてのエージェントがそれらを使えるようになります:

• Claude Desktop — あなたの API にアクセス
• Cursor — あなたの API にアクセス
• OpenClaw — あなたの API にアクセス
• あらゆる MCP クライアント — あなたの API にアクセス

ツール間でキーをコピーする必要はもうありません。「どのエージェントにどの API が設定されているか？」と悩むこともありません。新しいエージェントを追加しますか？ すでにすべてにアクセスできます。キーを失効させますか？ Janee で一度更新するだけです。

1 つの設定。すべてのエージェント。完全な監査証跡。

---

クイックスタート

インストール

npm install -g @true-and-useful/janee

初期化

janee init

これにより、サンプルサービスを含む ~/.janee/config.yaml が作成されます。

サービスの追加

オプション 1: 対話形式（初めての方に推奨）

janee add

Janee がサービスの追加をガイドします:

Service name: stripe
Base URL: https://api.stripe.com
Auth type: bearer
API key: sk_live_xxx

✓ Added service "stripe"

Create a capability for this service? (Y/n): y
Capability name (default: stripe): 
TTL (e.g., 1h, 30m): 1h
Auto-approve? (Y/n): y

✓ Added capability "stripe"

Done! Run 'janee serve' to start.

AI エージェントを使用していますか？ プロンプトをスキップするフラグについては非対話形式のセットアップを、以下のエージェント別ガイドをご覧ください。

オプション 2: 設定を直接編集

~/.janee/config.yaml を編集します:

services:
  stripe:
    baseUrl: https://api.stripe.com
    auth:
      type: bearer
      key: sk_live_xxx

capabilities:
  stripe:
    service: stripe
    ttl: 1h
    autoApprove: true

CLI ツールを追加する（exec モード）

一部のツールでは、認証情報を HTTP ヘッダーではなく環境変数として渡す必要があります。exec モードはこれを処理します:

janee add twitter --exec \
  --key "tvly-xxx" \
  --allow-commands "bird,tweet-cli" \
  --env-map "TWITTER_API_KEY={{credential}}"

これで、エージェントは API キーを一切見ることなく、Janee を通じて CLI ツールを実行できます:

// Agent calls janee_exec tool
janee_exec({
  capability: "twitter",
  command: ["bird", "post", "Hello world!"],
  cwd: "/home/agent/project",  // optional working directory
  reason: "User asked to post a tweet"
})

Janee は TWITTER_API_KEY を注入してプロセスを起動し、コマンドを実行して、stdout/stderr を返します。認証情報がエージェントのコンテキストに入ることはありません。

主要なフラグ:

• --exec — exec モードとして設定する（HTTP プロキシの代わりに CLI ラッパー）
• --allow-commands — 許可する実行ファイルのホワイトリスト（セキュリティ）
• --env-map — 認証情報を環境変数にマッピングする
• --work-dir — サブプロセスの作業ディレクトリ
• --timeout — 最大実行時間（デフォルト: 30 秒）

Git 操作（HTTPS 認証の自動化）

GitHub の認証情報を使って exec モードを使用すると、Janee は git 認証を自動的に処理します。追加の設定は不要です — git push、git pull、git clone がそのまま動作します:

capabilities:
  - name: git-ops
    service: github
    mode: exec
    allowCommands: [git]
    env:
      GH_TOKEN: "{{credential}}"

// Agent can push code without ever seeing the token
janee_exec({
  capability: "git-ops",
  command: ["git", "push", "origin", "main"],
  cwd: "/workspace/my-repo"
})

Janee は環境内に GH_TOKEN/GITHUB_TOKEN がある git コマンドを検出し、HTTPS 認証用の一時的な askpass スクリプトを作成します。このスクリプトはコマンドの完了後に自動的にクリーンアップされます。

GitHub App 認証を追加する（自律型エージェント向け）

静的トークンは長時間実行されるエージェントにとってリスクがあります。GitHub App 認証は、必要に応じて短命なインストールトークンを生成します — 長期間有効な PAT は不要です。

オプション 1: create-gh-app を使用する（推奨）

npx @true-and-useful/create-gh-app create my-agent --owner @me
# Opens browser → creates app → saves credentials locally

# Install the app on your repos
# https://github.com/apps/my-agent/installations/new

# Register with Janee in one command
npx @true-and-useful/create-gh-app janee-add my-agent

完了です。これでエージェントは Janee の MCP プロキシを通じて短命な GitHub トークンを取得できます。

オプション 2: 手動セットアップ

janee add github-app \
  --auth-type github-app \
  --app-id 123456 \
  --pem-file /path/to/private-key.pem \
  --installation-id 789

または設定ファイル経由で:

services:
  github:
    baseUrl: https://api.github.com
    auth:
      type: github-app
      appId: "123456"
      pemFile: /path/to/private-key.pem
      installationId: "789"

仕組み: エージェントがアクセスを要求すると、Janee はアプリの秘密鍵で JWT に署名し、GitHub の API を介して 1 時間有効なインストールトークンと交換し、有効期限までトークンをキャッシュします。エージェントが秘密鍵を見ることはありません — API に届くのは短命なトークンだけです。

MCP サーバーを起動する

janee serve

エージェントで使用する

MCP をサポートするエージェント（Claude Desktop、Cursor、OpenClaw）は、execute ツールを呼び出して Janee を通じて API リクエストを実行できるようになりました:

// Agent calls the execute tool
execute({
  capability: "stripe",
  method: "GET",
  path: "/v1/balance",
  reason: "User asked for account balance"
})

Janee はキーを復号し、リクエストを実行し、すべてをログに記録して、レスポンスを返します。

---

連携

MCP に対応するあらゆるエージェントで動作します:

• OpenClaw — ネイティブプラグイン（@true-and-useful/janee-openclaw）
  • コンテナ化されたエージェントですか？ コンテナセットアップガイドを参照してください
• Cursor — セットアップガイド
• Claude Code — セットアップガイド
• Codex CLI — セットアップガイド
• 任意の MCP クライアント — janee serve を指定するだけです

---

OpenClaw 連携

OpenClaw を使用している場合は、ネイティブツールサポートのためにプラグインをインストールしてください:

npm install -g @true-and-useful/janee
janee init
# Edit ~/.janee/config.yaml with your services

# Install the OpenClaw plugin
openclaw plugins install @true-and-useful/janee-openclaw

エージェントの設定で有効にします:

{
  agents: {
    list: [{
      id: "main",
      tools: { allow: ["janee"] }
    }]
  }
}

これでエージェントは以下のツールを利用できます:

• janee_list_services — 利用可能な API を検出する
• janee_execute — Janee を通じて API リクエストを実行する

プラグインは janee serve を自動的に起動します。すべてのリクエストは ~/.janee/logs/ にログ記録されます。

---

MCP ツール

Janee は 3 つの MCP ツールを公開します:

ツール	説明
list_services	利用可能な API とそのポリシーを検出する
execute	Janee を通じて API リクエストを実行する（HTTP プロキシモード）
exec	注入された認証情報で CLI コマンドを実行する（exec モード）
manage_credential	エージェントスコープの認証情報へのアクセスを表示、付与、または取り消す
reload_config	サービスの追加・削除後にディスクから設定を再読み込みする（janee serve で起動した場合に利用可能）

エージェントは利用可能なものを検出し、Janee を通じて API を呼び出します。同じ監査証跡、同じ保護です。

---

設定

設定は ~/.janee/config.yaml にあります:

server:
  host: localhost

services:
  stripe:
    baseUrl: https://api.stripe.com
    auth:
      type: bearer
      key: sk_live_xxx  # encrypted at rest

  github:
    baseUrl: https://api.github.com
    auth:
      type: bearer
      key: ghp_xxx

capabilities:
  stripe:
    service: stripe
    ttl: 1h
    autoApprove: true

  stripe_sensitive:
    service: stripe
    ttl: 5m
    requiresReason: true

Services = 実際のキーを持つ実際の API
Capabilities = エージェントが要求できるもの、ポリシー付き

対応する認証タイプ

タイプ	説明	例
bearer	Authorization ヘッダーのベアラートークン	Stripe、OpenAI、GitHub
basic	HTTP Basic 認証 (ユーザー名 + パスワード)	内部 API
hmac-bybit	Bybit 用の HMAC-SHA256 署名	Bybit 取引所
hmac-okx	OKX 用の HMAC-SHA256 + パスフレーズ	OKX 取引所
hmac-mexc	MEXC 用の HMAC-SHA256 署名	MEXC 取引所
headers	カスタムのキーと値のヘッダー	非標準 API
service-account	Google サービスアカウントの JSON キー	Google Cloud
github-app	短命な GitHub インストールトークン	GitHub API
oauth1a-twitter	OAuth 1.0a のリクエストごとの署名	Twitter/X API v2
aws-sigv4	AWS Signature V4 のリクエストごとの署名	SES、S3、その他の AWS サービス

Twitter/X OAuth 1.0a

Janee は OAuth 1.0a 署名 (HMAC-SHA1) をサーバー側で計算するため、4 つの Twitter シークレットは保存時に暗号化されたままで、エージェントのコンテキストに入ることはありません:

services:
  twitter:
    baseUrl: https://api.x.com
    auth:
      type: oauth1a-twitter
      consumerKey: xxx        # encrypted at rest
      consumerSecret: xxx     # encrypted at rest
      accessToken: xxx        # encrypted at rest
      accessTokenSecret: xxx  # encrypted at rest

capabilities:
  twitter:
    service: twitter
    ttl: 1h
    autoApprove: true

または、組み込みテンプレートを使用します:

janee add twitter

AWS SigV4

Janee は AWS Signature V4 (HMAC-SHA256) をリクエストごとに計算し、アクセスキーを保存時に暗号化されたままにします。シークレットでないフィールド (region、awsService) は平文の設定に残ります:

services:
  aws-ses:
    baseUrl: https://email.us-east-1.amazonaws.com
    auth:
      type: aws-sigv4
      accessKeyId: AKIA...     # encrypted at rest
      secretAccessKey: xxx     # encrypted at rest
      region: us-east-1
      awsService: ses

capabilities:
  aws-ses:
    service: aws-ses
    ttl: 1h
    autoApprove: true

一般的な AWS サービス向けの組み込みテンプレート:

janee add aws-ses    # Amazon SES
janee add aws-s3     # Amazon S3

アクセス制御

どのエージェントがどのケイパビリティを使用できるかを制御します:

server:
  host: localhost
  defaultAccess: restricted   # capabilities require explicit allowlist

capabilities:
  stripe:
    service: stripe
    ttl: 1h
    allowedAgents: ["agent-a", "agent-b"]   # only these agents can use it

  github:
    service: github
    ttl: 1h
    # no allowedAgents + defaultAccess: restricted → no agent can use this

• defaultAccess: restricted — allowedAgents リストのないケイパビリティはすべてのエージェントから隠されます
• defaultAccess: open (デフォルト) — allowedAgents リストのないケイパビリティはすべてのエージェントが利用できます
• allowedAgents — ケイパビリティごとのエージェント名のリスト (MCP の初期化ハンドシェイクの clientInfo.name と照合されます)

実行時にエージェントが作成した資格情報は、デフォルトで agent-only アクセスになります — 作成したエージェントが manage_credential ツールで明示的にアクセスを許可しない限り、そのエージェントだけが使用できます。

Exec モードのケイパビリティ

services:
  twitter:
    auth:
      type: bearer
      key: tvly-xxx

capabilities:
  twitter:
    service: twitter
    mode: exec
    allowCommands: ["bird", "tweet-cli"]
    envMap:
      TWITTER_API_KEY: "{{credential}}"
    ttl: 1h
    autoApprove: true

Exec モードのケイパビリティは execute ではなく janee_exec を使用します。資格情報は環境変数として注入され、エージェントには stdout/stderr だけが見えます。

Exec モードにおけるランナーのデフォルトのハードニング:

• 分離された最小限の環境 (ホストの完全な環境は継承されません)
• コマンドごとの一時的な HOME
• タイムアウトによりプロセスグループを強制終了

Runner/Authority モード (コンテナ向け)

エージェントが Docker コンテナ内で実行されている場合、リモートホスト上の janee_exec はコンテナのファイルシステムにアクセスできません。Runner/Authority アーキテクチャはこれを解決します:

• Authority はホスト上で実行されます: 資格情報を保持し、ポリシーを適用し、API リクエストをプロキシします
• Runner は各コンテナ内で実行されます: エージェントに MCP を提供し、exec 以外の呼び出しを Authority に転送し、janee_exec をローカルで実行します

# Host: start Authority (MCP + exec authorization on one port)
janee serve -t http -p 3100 --host 0.0.0.0 --runner-key "$JANEE_RUNNER_KEY"

# Container: start Runner (agent talks to this)
janee serve -t http -p 3200 --host 127.0.0.1 \
  --authority http://host.docker.internal:3100 --runner-key "$JANEE_RUNNER_KEY"

エージェントに必要なのは JANEE_URL=http://localhost:3200 だけです。

Authority をスタンドアロンのプロセスとして実行することもできます:

janee authority --runner-key "$JANEE_RUNNER_KEY" --host 127.0.0.1 --port 9120

完全なアーキテクチャ、exec の認可フロー、Docker Compose の例、トラブルシューティングについては、Runner/Authority ガイドを参照してください。

---

リクエストポリシー

rules を使用して、各ケイパビリティが実行できるリクエストを正確に制御します:

capabilities:
  stripe_readonly:
    service: stripe
    ttl: 1h
    rules:
      allow:
        - GET *
      deny:
        - POST *
        - PUT *
        - DELETE *

  stripe_billing:
    service: stripe
    ttl: 15m
    requiresReason: true
    rules:
      allow:
        - GET *
        - POST /v1/refunds/*
        - POST /v1/invoices/*
      deny:
        - POST /v1/charges/*  # Can't charge cards
        - DELETE *

ルールの仕組み:

1. deny パターンが最初にチェックされます — 明示的な拒否が常に優先されます
2. 次に allow パターンがチェックされます — 続行するには一致する必要があります
3. ルールが定義されていない → すべて許可 (後方互換)
4. ルールが定義されているが一致しない → デフォルトで拒否

パターンの形式: METHOD PATH

• GET * → 任意の GET リクエスト
• POST /v1/charges/* → /v1/charges/ とそのサブパスへの POST
• * /v1/customers → /v1/customers への任意のメソッド
• DELETE /v1/customers/* → 任意の顧客への DELETE

これによりセキュリティが実効的なものになります: エージェントが「理由」について嘘をついたとしても、ポリシーが許可するエンドポイントにしかアクセスできません。適用はサーバー側で行われます。

---

CLI リファレンス

janee init                    # Set up ~/.janee/ with example config
janee add                     # Add a service (interactive)
janee add stripe -u https://api.stripe.com -k sk_xxx  # Add with args
janee remove <service>        # Remove a service
janee remove <service> --yes  # Remove without confirmation
janee list                    # List configured services
janee list --json             # Output as JSON (for integrations)
janee search [query]          # Search service directory
janee search stripe --json    # Search with JSON output
janee cap list                # List capabilities
janee cap list --json         # List capabilities as JSON
janee cap add <name> --service <service>  # Add capability
janee cap edit <name>         # Edit capability
janee cap remove <name>       # Remove capability
janee serve                   # Start MCP server (stdio, default)
janee serve --transport http --port 9100  # Start with HTTP transport (for containers)
janee serve --authority https://janee.example.com --runner-key $JANEE_RUNNER_KEY  # Runner mode
janee authority --runner-key $JANEE_RUNNER_KEY  # Start authority API
janee logs                    # View audit log
janee logs -f                 # Tail audit log
janee logs --json             # Output as JSON
janee sessions                # List active sessions
janee sessions --json         # Output as JSON
janee revoke <id>             # Kill a session

非対話型セットアップ (AI エージェント向け)

AI エージェントは対話型プロンプトに応答できません。環境変数から認証情報を読み取るには --*-from-env フラグを使用してください — これにより、シークレットがエージェントのコンテキストウィンドウに入りません:

# Bearer auth (Stripe, OpenAI, etc.)
janee add stripe -u https://api.stripe.com --auth-type bearer --key-from-env STRIPE_KEY

# HMAC auth (Bybit)
janee add bybit --auth-type hmac-bybit --key-from-env BYBIT_KEY --secret-from-env BYBIT_SECRET

# HMAC auth with passphrase (OKX)
janee add okx --auth-type hmac-okx --key-from-env OKX_KEY --secret-from-env OKX_SECRET --passphrase-from-env OKX_PASS

# GitHub App auth (short-lived tokens)
janee add github --auth-type github-app --app-id-from-env GH_APP_ID --pem-from-env GH_PEM --installation-id-from-env GH_INSTALL_ID

# Twitter/X OAuth 1.0a (per-request signing)
janee add twitter --consumer-key $TWITTER_CONSUMER_KEY --consumer-secret $TWITTER_CONSUMER_SECRET \
  --access-token $TWITTER_ACCESS_TOKEN --access-token-secret $TWITTER_ACCESS_TOKEN_SECRET

# AWS SigV4 (SES, S3, etc.)
janee add aws-ses --access-key-id $AWS_ACCESS_KEY_ID --secret-access-key $AWS_SECRET_ACCESS_KEY \
  --region us-east-1 --aws-service ses

必要な認証情報がすべてフラグ経由で提供されると、Janee は:

• readline を一切開きません (stdin でのハングなし)
• 適切なデフォルト (1h TTL、自動承認) でケイパビリティを自動作成します

必要であれば ~/.janee/config.yaml を直接編集することもできます。

---

仕組み

┌─────────────┐      ┌──────────┐      ┌─────────┐
│  AI Agent   │─────▶│  Janee   │─────▶│  Stripe │
│             │ MCP  │   MCP    │ HTTP │   API   │
└─────────────┘      └──────────┘      └─────────┘
      │                   │
   No key           Injects key
                    + logs request

1. エージェントがケイパビリティ、メソッド、パスを指定して execute MCP ツールを呼び出します
2. Janee がサービスの設定を参照し、実際のキーを復号します
3. キーを使って実際の API に HTTP リクエストを送信します
4. ログを記録します: タイムスタンプ、サービス、メソッド、パス、ステータス
5. エージェントにレスポンスを返します

エージェントが実際のキーに触れることはありません。

📐 詳細解説: 詳細な図、脅威モデル、代替手段との比較については Architecture & Security Model をご覧ください。

---

セキュリティ

• 暗号化: キーは AES-256-GCM で保存されます
• エージェントの識別: MCP initialize ハンドシェイクの clientInfo.name から導出されます — カスタムヘッダーは不要です
• エージェントの分離: 各エージェントは分離された識別情報を持つ独自のセッションを取得します (HTTP トランスポートはセッションごとに Server+Transport を作成します)
• アクセス制御: ケイパビリティごとの allowedAgents ホワイトリスト + サーバー全体の defaultAccess ポリシー
• 認証情報のスコープ: エージェントが作成した認証情報はデフォルトで agent-only になります
• 監査ログ: すべてのリクエストは ~/.janee/logs/ に記録されます
• セッション: 時間制限付きで、失効可能です
• キルスイッチ: janee revoke または設定を削除します

---

Docker

Janee をコンテナとして実行できます — ローカルの Node.js は不要です:

# Build
docker build -t janee .

# Run in HTTP mode
docker run -d -p 3000:3000 \
  -v ~/.janee:/root/.janee:ro \
  janee --transport http --port 3000 --host 0.0.0.0

または Docker Compose を使用します:

mkdir -p config && cp ~/.janee/config.yaml config/
docker compose up -d

Docker で Claude Desktop を使用する場合は、Docker docs をご覧ください。

---

コントリビューション

コントリビューションを歓迎します! PR を送信する前に CONTRIBUTING.md をお読みください — 必須の PR チェックリスト (テスト、変更履歴、バージョンアップなど) が含まれています。

---

ライセンス

MIT — True and Useful LLC によって開発されました

---

AI エージェントにキーを渡すのはやめましょう。アクセスを制御し始めましょう。 🔐