DatasetteはエージェントにDB全体ではなくクエリ単位の権限を渡す

Datasette Apps 0.3a0は、Datasette Agentとの連携を強化しました。新しいツールにより、エージェントは特定のHTMLアプリが使える保存済みクエリを追加、削除できます。ただし、データを書き換えるクエリを追加する場合は、利用者の事前承認が必要です。

アプリ作成時の確認も厳しくなりました。要求されたクエリが実在し、利用者に閲覧権限があるかを検証します。チャットでは#でアプリを指定でき、候補には閲覧可能なアプリだけが表示されます。

エージェントは保存済みクエリ単位で権限を扱う

Datasette Appsは、独自のHTMLとJavaScriptをDatasette内でホストします。アプリはsandboxで動き、承認されたデータベースや保存済みクエリを通じてデータへアクセスします。0.3a0では、この境界がエージェントの操作にも引き継がれました。リストは変更できても、包括的な権限までは得られません。

特に重要なのが書き込みです。エージェントはデータ変更クエリの追加を提案できますが、最終判断は人が行います。新しいアプリを作る場合も同じ確認が入ります。

企業データでは生成HTMLの見栄えより権限範囲が重要になる

LLMはdashboardや小さな社内ツールを短時間で組み立てられます。しかし、色やlayoutの失敗より重大なのは、どのtableを読み、何を書き換え、どこへ送信できるかです。

Datasetteは、この問題を既存の保存済みクエリと利用者権限に結び付けました。エージェントに注意を促すだけの曖昧な指示より、監査しやすい境界になります。

Sandboxの安全性は背後のクエリ設計に左右される

承認があっても安全とは限りません。範囲が広すぎる読み取りクエリは機密情報を漏らし、設計の悪い書き込みクエリは想定以上の行を変更できます。さらに今回はalpha releaseであり、完成したenterprise governanceではなく方向性を示す段階です。

人の注意力にも限界があります。似た承認依頼が続けば、内容を読まずに許可する習慣が生まれます。権限は狭くするだけでなく、影響を理解できる形で示す必要があります。

変更履歴と分かりやすい承認画面が境界の実効性を決める

次の焦点は運用です。どのエージェントがクエリを追加し、誰が書き込みを承認し、どのアプリが実行したかを管理者が追跡できる必要があります。

承認画面が一般の利用者にも変更の影響を説明できるかも重要です。そこで初めて、この境界が実際の安全装置なのか、単なるOKボタンなのかが分かります。

Lilithの判定

エージェントがデータベースへ手を伸ばせるのは、明示された小さな窓口だけです。書き込みのたびに人を呼ぶ仕組みが本物かどうかは、監査ログが教えてくれます。