AI エージェントのためのセキュリティコーチ

新人エンジニアをセキュアにする方法は、ポリシー文書を渡すことではありません。超えられないスコープを 与え、取り消しにコストがかかる作業にはレビューを挟み、境界の形が体感できる程度に短いフィードバックを 返すことです。

エージェントも同じです。ただし「学習する」部分を除いて。セッションをまたいで私たちの意図を内在化して くれることはありません。

つまり、会議室で本当に議論すべきなのは「モデルを信頼できるか」ではありません。その問いが出る時点で、 重要な決定はすでに下されています。ツールを配線した人によって、静かに。

誰も自覚していない決定

いま私が最初に持ち出す区別はこれです。この一つで会話の構造が変わります。

プロンプトは約束です。ツールインターフェースは制約です。

約束は有用です。認識を揃え、意図を文書化し、望ましい挙動の確率を上げます。同時に、言葉を使える者 なら誰でも交渉できます — そこには入力も含まれます。制約は議論では動きません。動かせるのは変更管理 だけです。

どのチームも「安全性の主張のうち、どこまでを約束に、どこまでを制約に載せるか」をすでに決めています。 自覚して決めたチームは、ほとんどありません。

これを見分けるテストがあり、1 分で終わります。規制当局に説明したくないアクションを一つ挙げてください。 次に、それを止める成果物を挙げてください。成果物が英語（あるいは日本語）の段落なら、それは約束です。 ポリシー、スコープ、あるいはバージョン番号の付いたチェックなら、それは制約です。

何が変わり、何が変わっていないのか

本当に新しいのは、非決定性が制御フローの内側に入ってきたことです。

信頼できないコンポーネントは何十年も扱ってきました — 不安定なネットワーク、サードパーティ API、 ユーザー。いずれも境界でのバリデーションで扱えました。新しいのは、どのアクションを取るかを自分で 決め、引数も自分で選び、同じ入力でも毎回違う判断をするコンポーネントです。

一方で、規律は変わっていません。「信頼できないコンポーネントを、その権限を継承せずにどう合成するか」 は、誰も「エージェント」と言っていなかった時代にモバイルマッシュアップについて論文で書いた問いその ものです。答えは当時も境界でのケーパビリティ媒介であり、今も境界でのケーパビリティ媒介です。

これは懐古趣味ではありません。予算の置き場所を教えてくれる指摘です。

直感的にはモデル側に投資したくなります。より良いプロンプト、より良いシステムメッセージ、出力を監視 する分類器。どれもより良い約束を買う投資です。制約は一つも買えていません。予算のすべてを約束側に 使うのは私が最もよく見る失敗で、しかも魅力的です。約束は書くのが安く、デモがきれいに決まるからです。

実際に機能する 4 つのパターン

この領域で私が構築してきたものは、結局 4 つに集約されます。

1 — 意図ではなくアクションをスコープする

セキュリティ境界は指示文ではなく、ツールのインターフェースに置きます。

エージェントがデータベース認証情報を持っているなら、その認証情報が到達できる範囲すべてに到達できます。 システムプロンプトの「顧客レコードの読み取りのみ」は、発行されなかった制約を代理する約束にすぎません。

だから制約を発行します。ツールごとに最小のケーパビリティ。タスクごとに発行され数分で失効する認証情報。 そして本当に重要な成果物 — エージェントが完全に侵害された場合の影響範囲を、1 ページに書き出すこと。

この 1 ページは、経営層との会話でも私が持つ最も有用な資料です。経営層は「ツールをスコープしました」 を買いません。買うのは、境界が定まり定量化された最悪ケースです。定量化された最悪ケースは、値段を 付けて承認できるからです。

2 — 取り消せない判断は決定論的に下す

モデルの判断は入力としては優れていますが、権限としては不適切です。

取り消せないもの — データ削除、送金、アクセスポリシー変更、本番へのデプロイ — の判断は、人間が 読める決定論的なチェックから来なければなりません。エージェントが提案し、コードが決める。

この分離は実装コストを上回る価値があり、その理由は技術的ではなく組織的です。会議室の誰も答えられない 「モデルを信頼できるか」を、「このルールを信頼できるか」に変換します。後者は、セキュリティチームが 30 年にわたって的確に答えてきた問いです。

私はもうレビューで信頼の問いを立てません。どのルールが決めるのか、そして誰がそれを所有するのかを 訊きます。

3 — 人間の承認は影響範囲で配置する

human-in-the-loop は最大化すべき美徳ではありません。これは私が失敗して学んだパターンです。

初期の設計で、私は気前よくゲートを置きました。レビューは多いほど安全なはずだ、という理屈です。数週間で 承認者は全件を機械的に通すようになりました。結果を伴わない承認に彼らの注意力を使わせたからです。私が 足したのは判断ではありません。レイテンシを足し、判断を抜いたのです。

注意力は上限が固く、当座借越のない予算です。アクションを取り消しコストで並べ、その上位にゲートを置き、 残りは決定論的チェックとアクションログに任せます。

4 — 脅威モデルは、エージェントを所有する人たちと一緒に書く

私はこれを、お客様自身の技術リードとの質問票形式で、汎用チェックリストではなくその業界とプロジェクトに 即したシナリオに対して実施します。

分かりやすい効果は、脅威モデルの質が上がることです。システムを知っている人が列挙するのだから当然です。 実際に効く効果は別にあります。要件が外部から届かなくなることです。自分が特定した脅威への緩和策を 議論する人はいません。

4 つの中で最も地味で、最も結果を変えます。そして 1〜3 を成立させる前提でもあります。誰も列挙して いないツールをスコープすることはできません。

誰も認めたがらない失敗パターン

監査についてもっとも多く聞く話は「トランスクリプトを保存しています」です。

トランスクリプトが魅力的なのは、無料で、しかも網羅的に見えるからです。何が言われたかは分かります。 何が行われたかは分かりません。そして量が増えたときに扱う形状として間違っています。誰も読まないうえに、 本当に必要になったその一回は、時間に追われながら散文から意図を再構成することになります。

必要なのは、試行されたすべてのアクション、それを認可したケーパビリティ、許可または拒否したチェック、 そして結果 — この 4 列です。クエリでき、アラートでき、そのまま渡せる大きさに収まります。

どこにコストが出るか

正直なトレードオフを書きます。コストの書かれていないパターンは宣伝です。

決定論的なゲートは、正当な作業の一部を遅くします。ルールが妥当な処理をブロックして、チームが半日 失う週が必ず来ます。タスクスコープの認証情報は ID レイヤーの部品を増やし、そのレイヤーはデリバリーの クリティカルパスに載ります。脅威モデリングのワークショップは、最も邪魔したくない人たちのシニア工数を 前払いで消費します。

どれも実際の請求書です。私が払うのは、代替案 — インシデントの最中に境界を知ること — の利率がはるかに 悪く、その時点で交渉の主導権がこちらにないからです。

払わない場合もあります。読み取り専用で、機密でないデータを扱い、影響範囲が 1 行で書ける小さな社内 ツール。そこに 4 パターン全部を適用するのは演劇です。そして演劇は「セキュリティの助言はケースを 区別しない」とエンジニアに教えてしまいます。

これはリスクの議論ではなく、デリバリーの議論である

経営層に対しては、意図的にリスクから入りません。

エージェント活用にモラトリアムを敷いても、活用は止まりません。止まるのは可視化された活用だけで、 代わりに引き継ぐのは、出荷を最適化する人たちが組み立てたシャドー環境です。4 つのパターンは一つもなく、 影響範囲を書いた 1 ページも存在しません。

うまくやっている組織は、サポートされた経路を「一番楽な経路」にした組織です。プラットフォームに 組み込まれたデフォルトのセキュリティ、プラットフォームより速く動きたいチームのためのセルフサービス セキュリティ、そして「誰もテストしないこと」に暗黙に依存していない、経営層が実際に承認できる ガバナンスモデル。

機能しているかは 2 つの兆候で分かります。設計レビューで「モデルを信頼できるか」が消え、「どのルールが 決めるのか」の議論が始まること。そして、こちらが知らないまま本番に出ているエージェントの数がゼロに なること — 禁止したからではなく、迂回する理由がなくなったからです。

それが仕事の全体であり、私が「門番」より「コーチ」と呼ばれたい理由です。

この分野の仕事は進捗に応じて書いていきます。同じ問題に取り組んでいる方は LinkedIn までどうぞ。ツールは shenril と BlueSquadron にあります。