Anaconda、AIエージェントスウォームと自律的セキュリティテストを組み合わせる

AIエージェントにより多くのツールを提供すれば、より有用になります。複数のエージェントに同時にそれらのツールを提供すると、より難しい課題が生まれます。企業は各エージェントの動きをどのように追跡し、実システムに到達する前に悪質な行動を阻止できるのでしょうか？

Anacondaの10月6日プラットフォーム拡張は、協調的なAI開発と自律的セキュリティテストを組み合わせることでこの問題に対処します。Kilo Code、Enkrypt AI、Outerboundsの技術を開発ワークスペース、セキュリティ制御、プロダクションオーケストレーションにわたって統合しています。

戦略的な考え方は、エージェントがソフトウェアを構築する場所、行動が検証される場所、そして生成されたワークフローが実行される場所を結びつけることです。Anacondaはこれを「AI Dev Factory」と呼んでいます。企業にとって実務的な問いは、これらの接続がエージェントの自律性の拡大を検査・管理しやすくするかどうか、ということです。

Kiloのエージェントが作業を調整する方法

エージェントスウォームは、関連するタスクを複数のAIエージェントに分配します。あるエージェントが認証設計を調査している間に、別のエージェントがテストを書いたり別コンポーネントを実装したりすることができます。潜在的な利点は、エージェントが発見を共有し、目的が衝突しない限り、並行して進められることです。

KiloのSwarmに関する技術的説明は、調整メカニズムを説明しています。メインセッションとその派生エージェントがメッセージボードを共有します。エージェントは結果を交換するためにすべてのサブタスクが完了するのを待つのではなく、作業を続けながらボードに所見を投稿し、読み取ることができます。

この区別は重要です。テストエージェントは、異なる前提でテストスイートを書く前に認証の決定について学ぶことができます。Kiloによると、初期の社内評価では重複作業が減少するとトークン消費が削減できる可能性が示唆されていますが、具体的な数値は公表されていません。

同じドキュメントでは、理解すべき境界も定義されています。ボードメッセージはエージェントを起動、再開、承認することはなく、助言的な保留や拒否メッセージは自動的にエージェントを停止させません。参加者全員がボードの全履歴を読むことができます。したがって、調整は実行可能な権限や実行制御とは区別する必要があります。

Anacondaのローンチページは、これらのワークフローをVS Codeに配置し、ワークツリー間の並列作業を説明しています。また、ベータ版のKilo Desktopを紹介しており、エンジニアリング、データサイエンス、Python環境管理を統合し、500以上のモデルとローカル推論へのアクセスを提供します。

戦術を変えるセキュリティテスト

Enkrypt AIはプラットフォームの対抗的テスト側面を提供します。Anacondaによると、拡張されたセキュリティ機能は、300以上の攻撃カテゴリにわたってモデル、エージェント、MCP統合をテストし、ランタイム保護も行います。

その自律的レッドチーミングの技術的説明において、Anacondaは既知の攻撃パターンから開始し、エージェントが対象の応答に合わせてアプローチを適応させると述べています。エージェントは弱点に関する仮説を立て、テストし、結果を検証し、次に何を試すかを決定します。

例えば、拒否は同じ要求の別の言い換えではなく、戦略の変更を促すことがあります。システムはセッションメモリを利用して失敗したアプローチの繰り返しを防ぎ、並行探索で異なるリスクを同時に調査します。Anacondaは、このテストが顧客の環境内で実行され、導入先の脅威モデルに合わせて調整されていると述べています。

このアプローチは、ツールや外部ソースから情報を取得するエージェントに関係します。リスクは安全でない回答に限らず、取得した資料に隠された指示が後続のツール呼び出しを誘導する可能性があります。テストは、エージェントが信頼する情報やその後の行動を含む、行動の連鎖を検証する必要があります。

ランタイムガードレールは別の課題に対処する

テスト中に弱点を発見し、運用中に安全でない行動を防止することは別々のタスクです。Enkrypt AIのGuardrails製品は、エージェント、ツール、取得強化生成、Model Context Protocol接続全体でリスクのある行動を承認、修正、またはブロックするよう設計されています。

同社は、プロンプトインジェクション、不安全なツール操作、特権境界違反、機密データの流出を対象リスクとして特定しています。監査可能な決定に重点を置くことで、制御層は予防だけでなくインシデント調査にも関連します。

Anacondaのローンチには、Kilo内のモデルリスクスコアと、ソースに基づく公開インシデントレポートを含むエージェントインシデントレジストリも含まれます。これらはモデル選択やテスト優先度の判断材料となりますが、特定の導入が安全であることの証明ではなく、セキュリティプロセスへの入力として扱うべきです。

規模に関する数値も同様の注意が必要です。Anacondaは、AIネイティブ開発者を対象とした調査で回答者の63％が何らかの形でスウォームへ移行していると報告しています。また、同社の発表では、Enkryptの調査により、4か月間に走査された25,264台のMCPサーバのうち73％に脆弱性が見つかったことが引用されています。これらはベンダーが報告した、調査対象の回答者とシステムに関する結果であり、すべての企業エージェント導入を測定したものではありません。

なぜ本番環境がストーリーに含まれるべきか

Anaconda’s AI Orchestration プラットフォーム（旧称 Outerbounds）、開発後に何が起こるかに対処します。同社のウェブサイトでは、再現可能なワークフロー実行、アーティファクトの追跡と系統、複数のクラウドにまたがるコンピュートの利用、そしてパッケージやモデルへのガバナンスが説明されています。

これにより、出力をそれを生成した環境や依存関係に接続する方法が提供されます。ワークフローが変更された場合、チームはどのモデル、パッケージ、またはポリシーがそれに伴って変更されたかを把握する必要があります。再現性により、調査や比較がより実用的になります。

10月のリリースにより、オーケストレーションワークフロー内でガバナンスされたアーティファクトへのネイティブアクセスが追加されました。リリースページの詳細には、Fast Bakery も記載されており、conda および PyPI の依存関係（ネイティブライブラリを含む）からコンテナイメージを構築し、19,000 を超えるキュレーション済みパッケージと 77 の審査済みオープンソースモデルを含む拡張カタログが提供されます。

この拡張により、Anaconda は Python コンポーネントの提供にとどまらない、より広範な役割を担うことになります。その提案は、エージェント支援開発、敵対的評価、ランタイム制御、そして再現可能なデリバリーにまで及びます。重要な検証は、これらの要素がチームに対して、エージェントが構築したもの、テストされたもの、そしてソフトウェアが稼働し始めた際に許可された操作の信頼できる記録を提供できるかどうかです。