権限モデルとは｜毎回確認は20回全部で止まり、ルールで判定すると12回に減った

毎回確認は20回全部で止まり、ルールで判定すると12回に減った

コマンド20個に3通りの出し方を当てました。全部許可では危険操作が6個通り、ルール判定では確認12回で危険操作は0個です。

権限モデルの出し方で何が変わるのかを、実際のコマンドで数えました。用意したのは実作業で出てくる20個で、うち6個は取り消せない操作です。

判定は実際に正規表現を当てて数えています。コマンドの一覧と許可のルールはコードに書いてあり、そこを変えれば結果も変わります。

// 事前に決めたルール。読み取りと検査は許可、それ以外は確認
const ALLOW = [/^ls/, /^cat /, /^grep /, /^git (status|diff)/,
               /^npm (test|run lint)/, /^node /];

const modes = {
  '全部許可':   (c) => ({ ask: false, run: true }),
  '毎回確認':   (c) => ({ ask: true,  run: true }),
  'ルールで判定': (c) => {
    const allowed = ALLOW.some((r) => r.test(c.cmd));
    return { ask: !allowed, run: true };
  },
};

実作業で出てくるコマンド 20個（うち取り消せない操作 6個）

出し方        確認を求める回数  無確認で通る危険操作
全部許可                   0回             6個
毎回確認                  20回             0個
ルールで判定                12回             0個

ルールで判定した場合に確認が必要なコマンド（12個）
        git add .
        git commit -m fix
        mkdir tmp
        cp a.txt b.txt
        sed -i s/a/b/ x.ts
        curl example.com
  危険  git push --force
  危険  rm -rf build
  危険  DROP TABLE users
  危険  aws s3 rm --recursive
  危険  kubectl delete ns
  危険  curl -X POST /pay

3通りの性格がはっきり分かれました。全部許可は止まらないが危険操作が6個通り、毎回確認は安全だが20回すべてで止まります。

確認が多いと読まなくなる

毎回確認の弱点は数字に出ません。20回のうち14回は読み取りや検査で、危険でも何でもない操作です。安全な確認が続くと、内容を見ずに押すようになります。

そうなると、危険な7回目が来ても同じ調子で通してしまいます。回数を減らすこと自体が、安全側に働くという理屈です。

残った12回の中身

ルールで判定した場合に残った12回のうち、6個は危険な操作です。残り6個は書き込みや通信で、危険とまでは言えないが自動で通したくないものになります。

この6個をさらに許可に回すかどうかが、次の調整点です。mkdir tmp のような作業用の操作は許可してよいかもしれません。

権限モデルとはどういう仕組みなのか

実行してよい操作と、してはいけない操作を先に書いておく仕組みです。書いたものが実行のたびに照合されます。

権限モデルは、AIが実行してよい操作を先に決めておき、実行のたびにそこへ照合する仕組みです。判断をその場のやりとりに委ねません。

粒度を細かくできる

Anthropicの説明では、やってよいこととやってはいけないことを正確に指定できる細かい粒度の権限が用意されているとされています。ツールの種類だけでなく、コマンドの中身まで指定できます。

たとえば git をまとめて許可するのではなく、git status と git diff だけを許可するといった書き方になります。

段階のある仕組み

同じ文書には、力と安全のつり合いを取るために段階のある権限の仕組みが使われていると書かれています。読み取りは確認なし、シェルの実行は確認あり、といった具合に扱いが分かれます。

つまり最初から適当な既定値が置かれています。ゼロから設計しなくても、危険な側だけ調整すれば動きます。

サンドボックスとの違い

似た仕組みに、実行環境の側で触れる範囲を制限するものがあります。権限モデルが「実行してよいか」を判定するのに対し、そちらは「触れられるか」を物理的に決めます。詳しくはサンドボックス実行の記事で扱っています。

許可のルールはどう書けばよいのか

狭く始めて足していきます。評価の順序を踏まえないと、広い禁止が後の許可を打ち消します。

権限モデルのルールは、狭く書いて必要な分だけ足す順で組みます。広く開けてから塞ぐ方向は、塞ぎ漏れが表に出ません。

評価の順序を押さえる

先に仕組みを理解してください。Anthropicの説明では、ルールは禁止、確認、許可の順に評価されます。

この順序には効き目があります。広い禁止を書くと、後から狭い許可を足しても打ち消されます。禁止の中に例外を作ることはできません。

組み立てる順番

1. 読み取りと検査だけを許可する。ここから始める
2. 実際に確認を求められた操作を記録する。何が足りないかが分かる
3. 頻度が高く安全なものを許可に足す。1つずつ足す
4. 取り消せない操作を禁止に置く。許可の書き間違いに巻き込まれない

4番目が保険になります。評価の順序で禁止が先に効くので、許可を広く書きすぎても危険な操作は止まります。

広い許可の落とし穴

前の節のルールでも、/^node / という許可を置いています。これは node で始まるあらゆるコマンドを通すので、任意のスクリプトを実行できてしまいます。

許可を書くときは、その表現に何が当てはまるかを一度書き出してください。通したい1つだけでなく、通ってしまう全部を見ます。