AgentJail 1.7、エージェント権限をセッションに紐づく単発 grant に変更、ホストコネクタは転送をデフォルト拒否

AgentJail 1.7.0 は、coding agent の一時的な権限を、単純な allow／deny から、厳密かつ譲渡不能な runtime grant へと進化させた。各 grant は、エージェント、ユーザープリンシパル、セッション、アクション、正規化されたリソースとパラメーター、ポリシーバージョン、スコープ、有効期限、使用済みかどうかに紐づけられ、requested、approved、active、consumed、expired、revoked の各状態を順に遷移する。明示的な deny は引き続き grant より優先され、承認されたからといって直ちに使用可能になるわけではない。コネクタの起動または readiness probe に失敗した場合、権限は active にならない。

この分離は、エージェントセキュリティで頻繁に見られる時間差の問題を対象としている。ユーザーがある操作を承認した後に、セッション、ポリシー、または対象リソースが変更されている可能性があるためだ。新版では、承認と有効化の記録を先に永続化してから、エージェントに権限を公開することが求められる。有効期限の境界でも厳密に拒否されるようになった。また、コネクタの有効化と失効処理を直列化し、セッションをクリーンアップする前に broker route を失効させる。さらに、シンボリックリンクである、所有者が不正である、または権限設定が不適切である Linux runtime root と socket を拒否する。

現在、ホストコネクタは、固定されたローカル Chrome CDP endpoint など、信頼済みのグローバルポリシーによって事前定義できる。サンドボックス内のエージェントは connector ID のみを参照でき、ホストやポートを独自に指定することはできない。診断ツールでは grant、認可、有効化、転送、上流側の capability が個別に表示される一方、承認証跡は漏えいしない。注目すべき点として、本番環境の MCP forwarding はまだ開放されていない。プロジェクトでは、ネイティブな承認証跡と grant-aware data plane が完成するまで fail-closed が解除されない。

デプロイ担当者は、コマンドスクリプトをセキュリティ境界と見なすことは依然としてできない。公式ドキュメントでは、PreToolUse hook は協調的なインターセプトにすぎず、変数展開、`eval`、その他のインタープリターによって文字列ベースのポリシーが回避される可能性があると明記されている。機密性の高い環境では、Landlock、macOS Seatbelt、またはコンテナを併用する必要がある。Windows には現在、同等のネイティブサンドボックスがなく、CI には公式の Action とイメージもまだ用意されていない。エンジニアリングチームが次に検証すべきなのは、正常な承認フローだけではなく、grant の失効、再試行、監査失敗の各経路である。