Vault と credential

Session の tool credential が置かれる場所。Broker が呼び出し時に使い、engine もモデルもそれを目にすることはありません。

Agent が真価を発揮するのは、本物のシステムに到達した瞬間です。そしてそこに到達するには本物の credential が要ります。その credential が決して行き着いてはならない唯一の場所が、モデルのコンテキストです。

Vault は workspace スコープの credential ストアです。Session は自分が引き出せる vault を指定します。Tool call が出ていくとき、broker がそれをそれらの vault と照合し、credential を付与して呼び出します。Engine に渡されるのは broker の URL と run token であって、シークレットではありません。

Vault を作る

subako vault create --display-name "Acme production"
subako vault list

--metadata は、vault と一緒に保存する任意のデータを JSON ファイルで受け取ります — テナント id、リージョン、自分のルーティングに必要なものなら何でも。

Credential を追加する

ペイロードは JSON として標準入力から読まれるので、シークレットはシェルの履歴にもプロセス一覧にも残りません。

subako vault add-credential <vault-id> \
  --protocol mcp \
  --target https://mcp.acme.example/sse \
  --display-name "Acme MCP" < credential.json

Protocol は必ず明示され、既定値はありません。これが --target の読み方を決めます。また、vault は protocol ごとに 1 つの target につき同時にひとつの credential しか持てません。すでに持っている target に 2 つ目の live な credential を追加しようとすると、credential target already exists で拒否されます。

ペイロードは JSON として標準入力に届き、その auth_scheme を名乗ります — これが残りのフィールドが何であるかを決めます。

{ "auth_scheme": "static_bearer", "token": "..." }

もうひとつの scheme は oauth で、access_token を持ち、任意で expires_at と refresh ブロックを持ちます。

一覧と削除

subako vault credentials <vault-id>

一覧されるのは credential であって、そのペイロードではありません。読み戻す手段はなく、シークレットは入るだけで、次にそれを見るのは broker だけです。

subako vault delete-credential <vault-id> <credential-id>
subako vault delete <vault-id>

どちらも id を入力し直すよう求めます。スクリプトでは --yes でこれを省けます。Credential を削除するとそのシークレットが消去され、占有していた target が解放されるので、同じ target に新しい credential を与えられます — これがローテーションの方法です。Vault を削除すると、その中のすべての credential と、それらのシークレットすべてが消えます。

なぜ session が vault を指定するのか

Vault は agent version に焼き付けられるのではなく、session ごとに指定されます。だからこそ、ひとつの公開済み version が、ある顧客には本番の vault で、別の顧客にはサンドボックスで動けます。その間に再公開するものは何もありません — version は agent に何ができるかを定め、session はそれを誰の credential で行うかを定めます。