LLMアプリで一番危ない認証情報は、みんなで共有しているものです。プロバイダーのAPIキーをアプリ、CI、エージェントにそのまま配ると、漏洩した瞬間にアカウント全体が危険にさらされます。対策は「マスターキーを厳重に守る」ことではなく、「配るキーがマスターキーでない」設計にすることです。
Virtual Keysでは、プロバイダーの認証情報をAzure Key VaultやAWS Secrets Managerに封印したまま、下流にはスコープ付きのsk-nrouter-*キーを発行します。アプリ、環境、CIパイプライン、エージェントごとに1つのキー。用途に応じた制限だけを持ちます。
各キーは独自の境界を強制します。
- IP allowlist: 信頼するCIDRブロックのみ許可。それ以外はHTTP 403で1ms未満に拒否
- Route ACL (allowed_routes): /v1/chat/completionsなど指定エンドポイントに固定
- Spend ceiling ($/日、$/月): プロバイダー呼び出し前にHTTP 402でクリーンに拒否
- Model allowlist: ステージング用キーは高コストな推論モデルに触れられない
- RPM/TPMスロット: Retry-After付きHTTP 429で暴走ループやノイジーネイバーを封じ込め
キーの取り扱いも厳格です。平文は発行時に一度だけ表示され、保存されることはありません。データベースにあるのはSHA-256ハッシュのみで、Rustゲートウェイのインメモリインデックスによりサブミリ秒で検証されます。キーが漏洩したら、ワンクリックで10ms未満に失効。マスターキーのローテーションは不要です。
すべての推論呼び出しはキーIDとクライアントIPに紐づいて監査ログに記録され、environment:productionやcost-center:fintechのようなメタデータタグが課金ログに付与されるため、「誰が何に使ったか」はクエリ一発で答えられます。
配るのはキーではなくスコープです。完全な仕様はnRouter Virtual Keysで公開されています。