大規模言語モデルを稼働中のクラウドアカウントに対して実行し、セキュリティホールを探させることには、明白な危険が伴います。実際の認証情報と、あちこちを調べ回る権限を持ったエージェントは、調査の過程でバケットを削除したり、権限設定を変更したり、秘密情報を漏らしたりしかねません。オープンソースのセキュリティリサーチエージェントであるCynativeは、デフォルトで一切の書き込みを拒否し、しかもその拒否をあらゆる呼び出しのたびにチェックすることで、この危険に対応しています。
このツールは、企業自身のコード、クラウド、ランタイムに対してフロンティアモデルを動かし、生成されたコードを内蔵のサンドボックス上で実行し、認証情報を付与する前に各アクションを分類します。AWS、GCP、Azure、主要なマネージド型Kubernetesサービス3種、セルフマネージド型クラスター、GitHub、GitLabに対しては、オペレーターのシェルにすでに存在する認証情報を使ってアクセスします。書き込みは明示的なオプトインが必要です。それ以外はすべて読み取り専用ポリシーの範囲内にとどまります――AWSではSecurityAudit、GCPではroles/viewer、Azureではreaderです。
この約束事において難しいのは、クラウドプロバイダーが週単位で新しいアクションを追加する中で、どのアクションが読み取りでどのアクションが書き込みかというマップを最新の状態に保ち続けることです。Cynativeの共同創業者であるShaked Zin氏によれば、この分類はプロバイダー自身のライブなソースから導き出されているといいます。同氏はHelp Net Securityに対し、「このマッピングは手作業で維持している表ではなく、プロバイダー自身のライブなソースから解決されるものです」と語りました。AWSについては、エージェントはService Reference APIを読み取り、コミュニティによるiam-datasetをフォールバックとして使い、操作の分類にはAWS SDKのサービスモデルを用います。これらのソースは実行時に取得され、設定可能な期間(デフォルトでは24時間)キャッシュされるため、プロバイダーが新たに公開したアクションは、その期間を過ぎた次回の実行で反映されます。
まだマッピングされていない新規のアクションであっても、必ず判定が下されます。読み取り専用ポリシーが許可するアクションに解決できないものは、すべて即座に拒否されます。新規アクションについても、AWSのiam:SimulateCustomPolicyチェックによって、そのポリシーに照らして同様に扱われます。Zin氏は「新しい書き込みは読み取り専用ポリシーに含まれていないため拒否されます。最悪のケースでも、新しい読み取りが一時的に過剰に拒否されることはあっても、書き込みが通過してしまうことは決してありません」と述べています。
この読み取り専用の境界線はアクションを制御しますが、モデルの推論そのものには何の効果もありません。この点が問題になるのは、Cynativeがソースコード、クラウド構成、ランタイムデータをそのままモデルに渡しているためで、そのいずれにも、エージェントを誤った結論へと誘導するために書き込まれたテキストが紛れ込んでいる可能性があるからです。「読み取り専用のゲートはアクションを制約するものであり、汚染された推論の連鎖を防ぐものではありません。私たちはインジェクションに対する免疫性を主張しているわけではありません。私たちが主張しているのは封じ込めです」とZin氏は語ります。
同氏の説明によれば、封じ込めとは、インジェクションが成功した場合の被害が一定の範囲にとどまることを意味します。読み取り専用のルールはモデルの外側に存在するため、汚染された入力は結論を歪めることはあっても、それ以上先には進めません。「それが書き込みや横移動、その他何らかのアクションに転化することはあり得ません。その分離こそが保証なのです」とZin氏は言います。エージェントはまた、すべてのツール出力とスキャン対象のコンテンツを信頼できないデータとして隔離し、終端のデリミタをエスケープすることでコンテンツが境界を突破できないようにし、すべてのツール呼び出しがオペレーターのタスクにまで遡って追跡できることを要求しています。
検出結果は、エージェントが「確認済み」と判定する前に、さらに第2の関門を通過します。検証者は生の証拠を読み取り、それを信頼できないものとして扱い、独立した2回の反証パスを実行し、何らかの異常があれば安全側に倒れて処理を失敗させます。これにより、汚染された1つのステップが検証済みの結果を生み出すことはできません。
この検証はすべて読み取り専用のサンドボックス内で完結しますが、これは証明という点で一つの疑問を生みます。過剰な権限を持つロールがアカウント乗っ取りにまでエスカレーションし得ることを確認するには、通常であれば書き込みや侵入的なステップが必要になるはずです。Cynativeのデモでは、まさにそうした問題――OIDCの権限昇格経路――が「検証済み(VERIFIED)」としてマークされています。Zin氏によれば、この判定は読み取りから得られたものであり、実際に悪用した結果ではないといいます。「検証は読み取り可能な証拠に基づいて確認するものであり、悪用によって行うものではありません」と同氏は述べています。デモでは、エージェントがそのロールの信頼ポリシーと付与されている権限を読み取り、ワイルドカードのOIDCサブジェクトとIAMFullAccessが組み合わさっていることを発見しており、このエスカレーションに必要な前提条件はすべて直接読み取り可能なものでした。
証明のために書き込みが必要になる検出結果は、「未検証(UNVERIFIED)」のままとされ、信頼度は低く扱われます。「検証は各検出結果を反証しようと試みる敵対的なパスです。確認できなかったものは未検証・低信頼度のままとなります。判定を下すために書き込みを行うことは決してありません」とZin氏は語ります。
その他の設計上の選択も、随所で読み取り専用という姿勢を裏付けています。すべてのツール呼び出しは永続的なJSONL形式の監査ログに記録され、記録できない呼び出しがあれば実行そのものを中止します。AssumeロールによるAWSのIDについては、範囲を限定したマネージドポリシーを付与した上でSTS経由で認証情報を再発行するため、エージェントが課している境界と同じ境界をIAM自体も強制することになります。このプロジェクトはApache-2.0ライセンスの下、静的にビルドされたGoバイナリとして提供されており、組み込みのBifrost SDKを通じて23以上のモデルプロバイダーと通信できるため、オペレーターはデータとモデルの選択の両方を自分自身の環境内にとどめておくことができます。
その結果生まれたのは、自らの抑制そのものを特徴とするエージェントです。攻撃者さながらのやり方でスタック全体を推論しつつ、自分が読み取れる範囲を明確にし、それ以外には一切手を出さないことによって信頼を勝ち取っています。
CynativeはGitHub上で無償公開されています。
翻訳元: https://www.helpnetsecurity.com/2026/07/13/cynative-open-source-deep-research-agent/
