エージェントにスコープ限定の認証情報を渡す

これは Agent-Safe Change Control の認証情報側の話です。エージェントが安全に保持できるキーを発行し、より強力なものを漏らすことなく引き渡す方法を説明します。強制側 — 予算、レーン、リスクリント、プロモートポリシー — は Guardrails です。本日よりお使いいただけます。

エージェントに対して安全な認証情報とは、3つの境界 — ケイパビリティ、スコープ、有効期限 — を備え、クリーンな環境で エージェントに渡される Kisenon API キーです。一言でいえば、エージェントの認証情報の スコープを限定し、より強力なものをエージェントの手の届く場所に残さないこと。

1. スコープ限定のエージェント認証情報を発行する

3つの次元をすべて設定して API キーを発行します。

• capability = agent — サンドボックスは操作できますが、keon connection-string main（および書き込み可能な main へのすべてのルート）は 403 を返します。エージェントは 変更を提案できますが、本番に書き込む認証情報を保持することは決してありません。
• scope = project — 1つのプロジェクトに限定されます。漏洩しても他の プロジェクトには到達できません。
• expires_at（短く） — 漏洩時の影響範囲を限定します。永遠ではなく、数日単位で。

コンソールで発行します — Settings → API keys （kisenon.com）で、Capability = agent、Scope = 特定のプロジェクト、Expires を設定してください。API キーは サインイン済みのブラウザセッションから発行されます。プレーンな CLI キーで別のキーを発行することは できません。書き込み可能な main ルートでキーを使用すると、正確に次を返します。

agent-scoped API keys cannot retrieve data-plane credentials or perform
branch-admin role/database operations; use the sandbox flow

2. エージェントに正しく渡す

クリーンなシェルまたはコンテナで、スコープ限定のキーをエージェントの唯一の 認証情報として渡します。

export KEON_API_KEY=nsk_<agent-key>   # the scoped agent key, and ONLY this
unset DATABASE_URL                    # no full connection string in the env
# also: no personal `keon login` session (no ~/.config/keon/credentials.json),
# no ~/.pgpass, no admin DATABASE_URL reachable from the agent's process.

PowerShell でも同じルールです。

$env:KEON_API_KEY = "nsk_<agent-key>"   # the scoped agent key, and ONLY this
Remove-Item Env:DATABASE_URL -ErrorAction SilentlyContinue
# also: no personal `keon login` session (no %USERPROFILE%\.config\keon\credentials.json),
# no %APPDATA%\postgresql\pgpass.conf, no admin DATABASE_URL reachable from the agent's process.

2部構成のルール、両方とも必須です。

• エージェントに渡す認証情報のスコープを限定する（ステップ1）。
• エージェントが拾い上げかねないより強力なものを取り除く — 完全な DATABASE_URL、~/.pgpass、または同じシェル内のログイン済み keon セッション。

libpq のパスワードファイルは、macOS と Linux では ~/.pgpass ですが、 Windows では %APPDATA%\postgresql\pgpass.conf です（どちらも PGPASSFILE で上書きされます）。 Windows ではこのファイルを確認してください — ~/.pgpass は Windows では読まれません。

自分のセッション用にパスワードファイルを残す場合は、自分のユーザーだけに制限してください。 macOS と Linux では chmod 0600 ~/.pgpass です。グループやその他のユーザーに何らかのアクセス権があると、 libpq はそのファイルを無視します。Windows では libpq はこのチェックを行わないため、ACL が唯一の保護になります。 継承されたエントリを削除し、自分だけにアクセス権を付与します。

icacls "$env:APPDATA\postgresql\pgpass.conf" /inheritance:r /grant:r "${env:USERNAME}:F"

いずれの場合も、これで防げるのは他のユーザーです。あなたとして実行されるエージェントは防げません — だからこそ、ファイルは単に非公開にするのではなく、エージェントの手の届かない場所に置く必要があります。

3. 安全なループ

エージェントが提案し、人間 — またはエージェント自身の境界付きプロモート — が処理します。

keon sandbox run \
  --migrate "alembic upgrade head" \
  --verify  "pytest tests/db"

keon sandbox run はブランチをフォークし、短命なエージェントトークンを 隔離されたホームに発行し、フォークのスコープ限定 URL をコマンドの DATABASE_URL として 注入します — そのため、サンドボックス内で keon connection-string main を試みるコマンドでさえ エージェントキーに当たって 403 を得ます。キャプチャされた差分を確認してから、 プロジェクトの promote_mode に従ってプロモートします。

keon projects update --promote-mode human で人間によるレビューを有効にします。

これが何であって、何でないか

• 協調的なエージェントのためのガードレールであり、敵対的なコードのための牢獄ではありません。 認証情報のスコープを限定することは、エージェントに渡すものを制限しますが、 すでにホストのファイルシステムやネットワークにアクセスできるサブプロセスを 封じ込めるわけではありません。真の封じ込め — 洗浄された環境、ホスト認証情報への アクセスなし、サンドボックスエンドポイントに限定された送信 — は別のレイヤーです。 エージェントのコードが信頼できない場合は、それも追加してください。
• cp だけが main への書き込み手です。 プロモートはキャプチャされた ステートメントをサーバー側で再生します。エージェントが書き込み可能な main の 認証情報を保持することはありません。

ブレークグラス

設計上、特別な「ブレークグラス」スイッチはありません。書き込み可能な main への 直接パスは、人間が保持する通常の read_write 認証情報にすぎません（keon connection-string main、またはコンソール） — 意図的にエージェントキーからは 到達できないようにしてあります。監査対象のインシデントパスでは、オペレーターが自身の read_write セッションを使用します。すべてのプロモートと承認はサーバー側で帰属付けられます。