← 一覧へ
連載 Agentic OS:技術スタックを下から読む の一部です ―― 目次を見る →

Agentic OS 技術スタックを下から読む 第26回:権限を「道具」ではなく「能力」に貼る ―― 安全を下から支える許可の設計

この記事の読み方
前回は、よく働くエージェントほど、言葉でだまされる危険も大きくなるという話で終わりました。社会的にだまされるエージェントを前提にして、権限、確認、経路、監査、停止条件を組み直す、と…

Agentic OS 技術スタックを下から読む 第26回:権限を「道具」ではなく「能力」に貼る ―― 安全を下から支える許可の設計

だまされうる前提の下へ戻る

前回は、よく働くエージェントほど、言葉でだまされる危険も大きくなるという話で終わりました。社会的にだまされるエージェントを前提にして、権限、確認、経路、監査、停止条件を組み直す、という結びでした。

今回は、そのうちの権限を一段下から見ます。権限を悪用されると言うとき、その権限はどこで、どの粒度で、どのように与えられているのでしょうか。

素朴には、道具ごとに信頼を決めたくなります。この道具は許す。この道具は毎回確認する。この道具は拒否する、という形です。しかし、これでは似た道具が増えるたびに設定が増えます。中身を読む道具、名前で探す道具、条件で絞る道具は別物ですが、どれも結局は読みに行きます。ひとつ設定を忘れるだけで、同じ穴が別の入口から開きます。

毎回人が確認する方式も長続きしません。十回に一回なら見ます。百回に一回でも、危ない操作なら見ます。しかし一日に三百回の確認が出れば、人は内容ではなく位置を見て押すようになります。一括で全部信頼する方式は、さらに悪いです。最初の一回で守りを捨てているからです。

許可は能力に貼る

そこで、許可を道具ではなく能力に貼ります。能力とは、何ができるかという操作の種類です。たとえば、ファイルを読む、ファイルを書く、ファイルを消す、コマンドを実行する、外部からデータを取る、外部の道具を呼ぶ、下位のエージェントへ仕事を渡す、といった単位です。

ここで大事なのは、道具の名前ではなく、下で起きる作用を見ることです。ある道具が一行を読む。別の道具が名前を探す。さらに別の道具が条件に合う行だけを抜き出す。見た目は違いますが、どれも作業場の中身を読む能力を使っています。

だから、鍵を収めた設定ファイルを読ませたくないなら、読む系の道具を一つずつ禁止する必要はありません。ファイルを読む能力について、その場所だけ拒否すると一本書きます。すると、読む能力を使う道具はすべて同じ規則に従います。

この設計では、新しい読む道具が増えても、穴は増えにくくなります。新しい道具を見つけるたびに人が設定を足すのではなく、その道具がどの能力を使うかで下側の規則に乗るからです。安全は注意深さではなく、分類の位置で効きます。

一本の規則は四つでできる

一本の許可規則は、四つの部品で考えると扱いやすくなります。第一に、どの能力を制御するかです。読むのか、書くのか、消すのか、実行するのかを決めます。第二に、対象が当てはまるかを見るパターンです。場所、名前、始まり方、向き先などをここで見ます。第三に、そのパターンから外す例外です。広く許すが、この一部だけは別、という形にします。第四に、効果です。拒否するか、人に確認するか、そのまま許すかの三つです。

規則が何も当たらない場合は、黙って通しません。実行の前に人へ確認を求めます。これは小さく見えますが、守りの向きとしては大きいです。書いていないものは許可ではない、という前提になるからです。

たとえば、コマンドを実行する能力について、版の状態を見る操作、外から取得する操作、試験を走らせる操作だけを許すとします。その場合は、行の始まり方を三種類に限ります。作業場に書く能力については、作業用の木と試験用の木の下だけを許します。読み取りは広く許しても、鍵を収めた場所は別の拒否規則で塞ぎます。

このように、広い規則と狭い規則を重ねます。広く読めるが秘密は読めない。作業場には書けるが許可証には書けない。試験は実行できるが任意の実行はできない。権限は一枚の札ではなく、四つの部品を持つ小さな判定の積み重ねになります。

厳しい効果が必ず勝つ

規則は一か所だけから来るとは限りません。利用者全体にかかる規則があります。作業場ごとの規則もあります。さらに、一時的に確認を省くための規則を足したくなることもあります。すると、同じ操作に複数の規則が当たる場面が出ます。

このときは、効果の厳しさで決めます。拒否が最も強い。次が確認です。許可が最も弱い。より緩い規則は、どこから来ても、より厳しい規則を上書きできません。

理由は単純です。一か所でも広い許可が勝てるなら、守り全体はその一か所に引っ張られます。たとえば、利用者全体では鍵を収めた場所への読み取りを拒否しているのに、作業場側で全読み取りを許可できるなら、拒否は意味を失います。逆も同じです。作業場で危ない場所を拒否しているのに、全体側の広い許可で開くなら、作業場の境界は守れません。

だから順番を固定します。拒否、確認、許可です。この三段階を数直線のように置き、左ほど厳しいと決めておきます。複数当たったら、いちばん左を採ります。これにより、迷ったときに安全側へ倒れるだけでなく、後から足された緩い規則が芯の拒否を壊せなくなります。

コマンドはつなぎ目で割って見る

コマンド実行の許可では、さらに細かい落とし穴があります。コマンドを一つの文字列として見てはいけません。文字列の先頭が許可された形に見えるからといって、全体が安全とは限らないからです。

コマンドは一行の中で複数の操作をつなげられます。順に実行するつなぎ目があります。前が成功したときだけ次へ進むつなぎ目があります。前が失敗したときだけ次へ進むつなぎ目もあります。前の出力を次へ流すつなぎ目もあります。

もし、試験を走らせる操作を許す規則が、文字列全体の見かけだけを見ていたら危険です。前半に試験を走らせる形を書き、その後ろに外部へデータを送る操作をつなげることができます。先頭が許可された形に一致しただけで一行全体を通すなら、後半の危ない操作まで一緒に通ります。

そのため、まず行を構造として読みます。構造として読むとは、文字の並びを左から眺めるだけでなく、どこが一つの操作で、どこがつなぎ目で、どこから次の操作が始まるかを分けることです。そのうえで、分割された部分コマンドを一つずつ評価します。

前半の試験は許可に当たるかもしれません。しかし後半の外部送信は、別の部分コマンドです。許可規則に当たらなければ確認へ落ちます。拒否規則に当たれば止まります。これで、許可された見かけの後ろに別の実行をぶら下げる抜け道を塞げます。

規則は作業対象の外に置く

許可規則は、置き場所も重要です。作業対象の中に規則を置くと、その作業対象が自分に都合のよい規則を持ち込めます。外から受け取った作業場の中に、すべて許可すると書かれた規則が入っていたら、開いた瞬間に守りが緩みます。

信頼は、持ち込まれた中身が宣言するものではありません。利用者の機械の側で、利用者が与えるものです。だから規則は作業対象の外に置きます。作業場の位置から作った識別子を使い、その識別子ごとに外側へ保存します。

この形にすると、作業対象の中身を書き換えられても、許可規則は同時には書き換わりません。作業対象が移動すれば、別の識別子になります。似た名前の場所を作っても、外側の対応がなければ同じ信頼は得られません。

ここで守っているのは、内容ではなく支配関係です。作業対象は、作業される側です。許可規則は、作業を許す側です。許す側を、許される側の中に置かない。これだけで、持ち込みによる権限注入をかなり減らせます。

許可証だけは書き換えさせない

最後に、上書きできない芯を置きます。エージェントがファイルを書けるなら、放っておけば自分の許可規則そのものを書き換えられます。許可を司る場所を書けるなら、どんな拒否もあとから消せます。どんな確認も許可に変えられます。

だから、許可規則を収めた場所への書き込みは、常に拒否します。これは利用者が後から書く普通の規則ではなく、下に埋め込まれた芯です。エージェント自身が緩めることはできません。

同じ理由で、取り返しのつきにくい場所への書き込みは常に確認にします。版の履歴を支える内部の場所、エージェントの動き方を定義する場所、自動処理の入口になる場所などです。ここは一度壊すと、あとから原因を追いにくくなります。だから完全な拒否ではなくても、人を一度通します。

要点は、許可の仕組み自体が、許可の仕組みによって守られていることです。ただし、その一番下の芯だけは通常の規則より下にあります。守りを変える力を、守られる側に渡さないためです。

賢さではなく範囲で守る

前回見た社会的な攻撃は、有能なエージェントを言葉で誘導し、与えられた権限を別の目的に使わせるものでした。その守りは、注意書きだけでは足りません。もっと下の層で、できることの範囲を狭める必要があります。

能力に貼るから、似た道具が増えても同じ規則が効きます。厳しい効果が勝つから、広い許可が後から拒否を壊せません。コマンドをつなぎ目で割るから、許可された前半に危ない後半をつなげられません。規則を外に置くから、持ち込まれた作業対象が信頼を注入できません。許可証を守るから、エージェント自身が守りを緩められません。

どれも派手な仕組みではありません。しかし、だまされうるエージェントを前提に置くなら、最後に効くのはこの種の地味な絞り込みです。賢さで守るのではありません。できる操作、届く場所、通る経路を構造で狭めて守ります。

ここまでは、権限をどう絞るかを見てきました。次回は少し上の層へ戻ります。こうして組んだ規則や、やりたいことを書き下した仕様そのものを、どう書けばエージェントが取り違えず、どう検証すれば正しく働いていると言えるのか。許可の設計から、仕様と検証の設計へ進みます。

← 一覧へ