AL1 設計による監視
構造化された計画、追跡可能なツール呼び出し、そして人が判断を下す明確な引き継ぎ点。
エージェント型システムのための安全性手法
監視、ケイパビリティ境界、安全なツール使用、および堅牢な拒否行動に関する研究。
良い依頼には役に立ち続け、悪い依頼には揺るがず信頼できるシステム。
監視 境界 拒否
私たちの安全性の捉え方
安全性は最終層のプロンプトではなく、アーキテクチャ上の特性である
私たちの安全性への取り組みはアーキテクチャに組み込まれています。すなわち、ランタイムで強制されるケイパビリティ境界、人的レビュアーを迅速かつ的確な情報のもとに保つ監視のための表層、そして敵対的な圧力に対して評価される拒否行動です。目指すのは、良い依頼には役立ち続け、悪い依頼には信頼できるシステムです。
プロンプト層の安全性 → 次のジェイルブレイクまでしか持たない
アーキテクチャ層 → プロンプトが崩れても境界は持ちこたえる
三つのコミットメント
安全性の取り組みが位置するところ
AL2 ケイパビリティ境界
エージェントはツールとデータに対する明示的な許可リストの内側で動作します。境界はプロンプトだけでなく、ランタイム層で強制されます。
AL3 堅牢な拒否
拒否行動は、敵対的なプロンプト、プロンプトインジェクション、そしてインセンティブの圧力に対してテストされます。基準は「悪い依頼を拒否すること」ではなく「良い依頼に役立ち続けること」です。
許可リスト · ランタイムポリシー
ツールはデフォルトで拒否されます。許可は明示的です。
決定するのはプロンプトではなくランタイムです。許可リストに載っていないツールは、たとえエージェントが使うべきだと考えても呼び出すことができません。
ツール スコープ リージョン 判定
read_doc allow public + signed pass
web_search allow rate-limited pass
send_email deny requires reviewer block
shell_exec deny no sandbox match block
pay_invoice deny human-only block
compile_code allow sandbox · read pass
拒否の堅牢性
良い依頼には役に立ち続ける。圧力下でも揺るがない。
基準は「悪い依頼を拒否すること」ではありません。基準は「良い依頼に役立ち続けること」であり、同じ評価において、ぎこちない言い回しや敵対的な圧力に対して測定されます。
good ask, plain 0.96
good ask, awkward 0.91
bad ask, plain 0.98
bad ask, jailbreak 0.94
bad ask, prompt inj. 0.92
bad ask, role-play 0.95
役立ち続ける 正しく拒否する
監視の引き継ぎ
五つの段階、二つの人的接点。
レビュアーは実行前に計画を確認し、実行後にスポットチェック用のトレースを確認します。エージェントは、レビュアーが計画レベルで承認していないものを決して実行しません。
01
agent
plan
structured plan emitted
02
human
reviewer
approve · revise · deny
03
agent
execute
allow-listed tools only
04
human
reviewer
spot-check trace
05
agent
report
full audit trail · signed
公開範囲
役立つ部分は公開する。差別化する部分は非公開にする。
01 capability-boundary API public with reference runtime
02 audit-stream spec public JSONL · OTel-compatible
03 refusal evaluation harness public paper + scoring code
04 adversarial prompt corpus partial subset under research use
05 internal red-team playbook private differentiating
これまでに公開したもの
ケイパビリティが境界づけられたエージェントのための手法、監査ストリームの仕様、そして拒否の評価です。差別化につながる取り組みについては、その基盤となるメカニズムを非公開に保ち、そうでないものについてはアップストリームに貢献します。