メインコンテンツまでスキップ

承認ゲート

承認は 2 つのことを同時にします。人が決めるまで実行をあるステップで止めること、そしてその決定を、以後その承認が対象とするステップが何をしてよいかを言い切る署名済みの許可に変えることです。

「止まる」とは何か​

この停止は、エージェントが行儀よく待っているという意味ではありません。

承認が決まっていないあいだ
対象のステップが呼べるもの束ねられた MCP ツールはどれも呼べません。呼び出しはサーバーに届く前に拒否されます
誰が強制するかゲートウェイが規則として確認します。エージェントへの指示文ではありません
ゲートの引き金そのステップを対象とする承認が存在することです。保留中も却下済みも同じく止めるので、ゲートは閉じる方向に倒れます
影響を受けないものどの承認の対象でもないステップです。通常のツールバインディングの規則のまま動き続けます

つまりプロンプトインジェクションやバグがゲートを言いくるめることはできません。説得する相手がいないからです。ゲートを開けるのは、その承認に対して記録された決定だけです。

証明書​

承認が対象とする各ステップは、開始した時点で短命な証明書を受け取ります。署名するのは、配備が最初の使用時に自分のために生成する認証局です。

証明書は承認が足すものではありません。ツールを呼ぶステップはどれも持っています。承認が変えるのは、それが誰の権限かです。誰にも承認を求めなかったステップはその実行を始めた人の権限で証明書を受け取り、承認はそれを承認者自身の権限に差し替えます。だから記録が答えるのは「この呼び出しは許可されていたか」ではなく、つねに「誰の許可だったか」です。

証明書が持つものなぜ効くのか
どのテナント・どの実行・どのステップのものか、そして誰の権限を持つのか(承認者か、実行を始めた人か)ある実行のために発行された証明書は別の実行では役に立たず、片方の権限がもう片方の代わりになることもありません
そのステップが開始した瞬間に束ねられていたツール一覧実行のステップとそのツールは、公開されたワークフローの設計から実行時に固定され、証明書が発行時にもう一度それを固定し、承認の対象になったステップのツールはそもそも変更できなくなります。ですからエージェントも、あとからの変更も、許可を広げられません。ファイルを読む承認がファイルを消す承認に化けることはありません

判断が対象とする呼び出し​

証明書が答えるのは「どのツールか」だけで、「どんな値で呼ぶか」には答えません。そして結果を 左右するのは、たいてい入力のほうです。そこで依頼は、証明書が持たないものをもう 1 つ持ちます。 許可する呼び出しの一覧です。ツールごとに、入力が取りうる値の範囲を書きます。依頼した時点で 記録され、承認者が判断する前に示され、あとからは誰にも変更できません。エージェントにもです。

ゲートウェイを通る呼び出しは、証明書と並べてこの一覧とも照合されます。

照合されるもの拒否される場合
ツール判断がそれを挙げていないとき。証明書が許可していても拒否されます
渡された各入力判断がその入力を挙げていないとき。承認者が見ていない入力です
判断が挙げた各入力それが欠けているとき。ただし optional と書かれていれば省けます
各値承認者が同意した範囲から外れているとき

承認済みの枝が 2 つ合流するステップは、両方の判断を満たさなければなりません。そもそも両方の 判断を必要とするのと同じ理由です。緩いほうの承認者が、もう一方の代わりに話すことはできません。 入力の承認が要るかどうかで 2 つが食い違うときは、厳しいほうが通ります。

読むだけだとワークフローの設計が示したツールも、除外されるのではなく Any input として 並びます。判断の記録は、それが許可するものの完全な説明であり続けます。だから承認者は どのツールが縛られていないかを見て取れますし、関門も、ステップのツールを読み直す 2 つ目の 規則ではなく 1 つの一覧を見るだけで済みます。この項目を書けるのは依頼の処理だけです。 エージェントが自分で書こうとすれば拒否されます。

実行を始めた人自身の権限で動くステップは、この照合を受けません。承認者がいないので、そこから 外れるという話が成り立たないからです。そのステップを縛るものは変わりません。自分のツールと、 証明書の署名済みの許可です。

承認が対象とするステップ​

承認は、指定されたステップと、その後ろに続くステップすべてを、次の承認までの範囲で対象とします。ですから依頼そのものを 1 つのステップにしておけば、その決定は後続の作業まで届きます。

承認 A が対象とするのは「承認を依頼する」「インスタンスを起動する」「インスタンスにタグを付ける」です。「もう一度依頼する」から先は承認 B が引き継ぎます。依頼より前にあるものが対象になることはありません。承認が届くのは前方だけです。

状況どうなるか
指定したステップ自体はツールを使わない問題ありませんし、それが普通です。決定は後続のステップが担います
別々の分岐にある 2 つの承認の後ろにステップがある両方が承認されるまで動けません。片方の承認者の判断が、もう片方の代わりにはなりません
すでに別の承認の対象になっているステップに、あとから承認を依頼した近いほうの依頼がただちに引き継ぎ、前の決定はそのステップを認可しなくなります
ステップが差し戻され、再提出された新しい依頼が古い決定に代わってそのステップのゲートになるので、却下によってステップが永久に止まったままになることはありません

以後、対象のステップから出るツール呼び出しは、すべてその証明書を提示しなければなりません。ゲートウェイは、呼び出しをどこかへ通す前に次のすべてを確認します。

  • 証明書がこの実行・このステップのものであること
  • この配備が発行したもので、失効していないこと
  • 背後の承認がいまもそのステップを対象としていて、対象とする承認がすべて承認されたままであること
  • 呼び出し元が、コピーしただけではなく本当にその証明書の持ち主だと示せること
  • 呼ぼうとしているツールが署名済みの集合に入っていること

証明書は、そのステップが終端ステータスに達した時点で失効します。安全性はこれに依存しません(終わったステップはもう動いていないので、呼び出しはすでに拒否されます)。これが足すのは、その許可が「なぜ効かなくなったのか」を記録が語ることと、証明書の寿命が、それが認可した作業の長さに沿うことです。対象の各ステップは自分が開始したときに自分の証明書を受け取るので、長く続くステップの連なりが 1 枚の証明書の有効期間に収まる必要はありません。その最大の有効期間は設定リファレンスで変えられます。

記録が答えられること​

判定されたツール呼び出しは、許可も拒否も、提示された証明書とともに記録されます。だから「この操作を誰が、どんな根拠で許可したのか」に、実行が終わってからずっとあとでも答えられます。引数はダイジェストだけが残り、生の値は保存されません。この記録を読む場所は、実行の Tool Invocations の画面です。

判断から外れたために拒否された呼び出しは、その理由も記録します。問題になった入力の名前と、承認者が同意した範囲です。ただし実際に渡された値は残しません。理由は書かれたまま保存され、しかもそれは引数をダイジェストでしか持たない同じ記録の上です。そこに拒否された値を書けば、ダイジェストがわざわざ省いているものを書き戻すことになります。

保証の範囲。 ゲートウェイはバックエンドのプロセスの中で動くので、証明書は同じプロセスを共有する検証者に対して所持を証明します。すでにバックエンドを掌握した攻撃者への防御ではありません。得られるのは、閉じる方向に倒れる単一の強制点、あとから広げられない許可、そしてあとから確認できる記録です。