長年SaaSのGTM/プロダクト領域の人間でしたが、非常に新米のソロ起業家です。後ろめたいくらいですが、学びながら進めています。ただ、エージェンティックな未来における「道具とシャベル（pickers and shovels）」の一部になる必要があることは分かっています。AIエージェント向けのスコープ検証サービスを構築していて、検証（verify）呼び出しをすべて管理ダッシュボード経由でログに残し始めました。以下が生データです。
検証呼び出しは合計5回：
- 3回許可: send_email, file.write, deploy.vercel
- 2回拒否: delete_files（action_not_in_scope）、send_email（grant_revoked）
拒否ケースが面白いところです。最初のエージェントは delete_files を呼び出しました。アクティブな付与（grant）はありましたが、allowed_actions リストに delete_files が含まれていませんでした。ブロックされました。2つ目は、私がその付与を明示的に取り消したあとで send_email を試みました。これもブロックされましたが、理由コードが action_not_in_scope ではなく grant_revoked でした。
2つの異なる失敗モード、2つの異なる拒否理由。これが重要なのは、生産環境でエージェントの振る舞いをデバッグしているときです。
まだ見えていないもの: 偽陽性です。許可された各呼び出しは、どれも確実に正当化されていました。ただ、現時点では件数が少ないです。検証呼び出しは5回、始まったばかりです。
メタ（Meta）での並行例: 彼らのエージェント（2026年3月）は、機密の社内データを2時間にわたって公開してしまいました。事前の実行スコープ強制がありませんでした。エージェントには資格情報（credentials）がありましたが、文脈の中でそれを使って何ができるかを制限するものが何もありませんでした。資格情報は「エージェントが何をできるか」を教えます。スコープは「エージェントが何をすべきか」を教えます。IAMは最初の質問にしか答えません。これは、解決する価値のある問題のはずだという、ずっと引っかかる感覚があります。センスを添えて。
明示しておくべきトレードオフ: 各 verify 呼び出しで約12msの遅延が追加されます。5回以上の逐次ツール呼び出しを含む LangGraph のワークフローでは、それが積み上がります。頻度の高いアクションについては、バッチ化またはキャッシュ化したいところです。アーキテクトする前に知っておく価値があります。
エージェントを本番環境に投入しているなら、実際の認可レイヤーはどう見えていますか？ IAMではありません――この特定のタスクで、この特定のユーザーに対して、今この瞬間にエージェントに何を許可するかを、何がエージェントに伝えていますか？「これは解決に値する問題だ」と考えるのは、私が外部者としてはナイーブすぎますか？ ほかに何を見落としているのでしょうか？ そして、あなたの世界をより深く潜るにあたって、私の命名（nomenclature）にはどうか親切で辛抱強くあってください…… ¯\_(ツ)_/¯
[link] [comments]
