AIエージェント、自社ツール半数を把握できず

チームは野心的な課題に直面していた。本番コーチングプラットフォームのAPIのセキュリティ、コード品質、システム可視性のギャップを埋めることだ。彼らは3フェーズの並列インストールを設計した。フェーズ1では4つの外部セキュリティスキルを導入した。OWASP Top 10チェック、Trail of Bitsの6つの監査方法論（不安全なデフォルト検出、バリアント分析、差分レビュー、鋭いエッジ識別、静的分析、Semgrepルール作成）、破壊的コマンドセーフティネット、Anthropicの公式スキルライブラリだ。フェーズ2では3つのインフラツールを追加した。ライブデバッグ用の読み取り専用MongoDBコネクタ、エンドツーエンドテスト用のPlaywright ブラウザオートメーション、エージェント設定ファイル用の設定リンターだ。フェーズ3はコードベース分析から構築した7つのカスタムスキルで構成されていた。2500行ファイル分解用のコントローラー抽出ワークフロー、コードベース特有のReactコンポーネントパターン、呑み込まれたエラーを検出するサイレント失敗検出器、システム可視性標準、APIエラーハンドリング規約、エンドポイント単位のセキュリティチェックリスト、正規テストフィクスチャだ。各フェーズは並列サブエージェントとして実行され、インストール全体は1回のセッション内に完了した。すべてのツールは機能テストに合格した。

そこでチームは発見監査を実施した。質問は単純だった。将来のエージェントが関連する問題に直面するとき、自動発見を通じてこのツールを見つけることができるか？結果は明白だった。すべてのカスタム構築スキルが発見可能であり、すべての外部調達スキルが見えなかった。パターンは一貫しており、啓発的だった。7つのカスタムスキルは発見メタデータを組み込んで作成されていた。マッチングシステムがエージェントのクエリと関連スキルを結びつけるためのキーワードトリガーフレーズだ。8つの外部スキルは、尊敬されるセキュリティ研究機関およびオープンソースリポジトリから調達したもので、そのメタデータ以外のすべてを持っていた。

対策は馬鹿げるほど小さかった。スキルごとに3～5行のYAML。たとえば、OWASPセキュリティスキルの場合、triggers: "security vulnerability"、"injection prevention"、"XSS prevention"、"security review"を追加する。これらの行がなければ、OWASP Top 10全体をカバーするセキュリティスキルは使われないまま、エージェントはセキュリティ意識なしに認証コードを書く。あれば、スキルは自動的に活動する。

非表示化は静かで危険だ。あるエージェントが他のエージェントが発見できないツールを構築しても、目に見える形ではシステムが壊れない。エラーが出ない。アラートが発火しない。ツールはディレクトリに座ったままで、完全に機能するが、同じ問題に直面した将来のエージェントはゼロからソリューションを再構築するか、それなしで進むか、見えないセキュリティ監査者が検出したであろう脆弱なコードをリリースする。チームは5つの独立した発見サーフェスを識別した。プロトコル自動リスト登録、トリガーマッチング、ツーリングレジストリ、セマンティックスウォーム検索、レジストリセマンティック検索だ。見えない8つのスキルはトリガーマッチングで失敗し、ツーリングデータベース（サーフェス3と5）にも登録されていなかった。一部はセマンティック検索を通じて部分的に見えていたが、部分的可視性は可視性なしより悪い。同じクエリがときどきツールを見つけるが、他のときは見つけないという矛盾した動作を生む。トリガーアレイでツールに8個にパッチを当て、内部識別子がフォルダ名と一致しなかった7個の名前不一致を修正した後、検証では15個すべてがトリガーマッチングとセマンティック検索全体で発見可能になった。核心的な教訓は複合効果こそが発見可能性を危険にするということだ。発見可能性を検証せずにツールを構築するセッションを重ねるたびに、見えないパイルに追加される。規模が大きくなると、1000個のツール、53%の非表示率で、実在するツールとエージェントが見つけられるツールの間のギャップは単なるハウスキーピング課題ではなく戦略的問題になる。

発見問題は2つのダイナミクスの交点で生じる。ツールはそれがどのように発見されるかとは独立して機能し、エージェントには知識ギャップを露出させるはずの人間フィードバックループを欠いている。人間チームが機関知を失うと、やがて誰かが気付く。新入社員が答えられない質問をするか、プロセスが破綻するかだ。AIエージェントにはそのようなシグナルがない。見つからないが機能するツールはエラーを出さず、アラートを発火させず、痕跡を残さない。代わりに、システムディレクトリに静かに蓄積されていく。将来的に同じ問題に直面したエージェントは、ゼロからソリューションを再構築するか、そのツールなしで進むだけだ。

監査結果はギャップを具体的に明らかにした。すべてのカスタム構築スキルが発見メタデータを含んでいた。チームは作成時に問題を予見していたからだ。すべての外部スキルがそれを欠いていた。外部ソースがこの特定システムの発見要件を知る方法がなかったからだ。対策であるトリガーフレーズの追加は、作成時にはほぼ無コストだが、後付けは高コストだ。チームはこれを明示的な検証を通じて発見した。しかし、より深い洞察は、ほとんどのシステムがそのような検証ステップを全く持たないということだ。発見監査を実施しなければ、15個すべてのツールは完璧に機能しているように見え、53%の非表示化は今後のセッションを通じて無限に複合化しただろう。規模が大きくなると、1000個のツールで、問題は単なるハウスキーピング課題ではなく、戦略的なボトルネックになる。

まだコメントがありません。最初のコメントを投稿しましょう！