さらに従来のキーワードベースのフィルターは、文脈を理解できないという問題があります。正当なリクエストを誤ってブロックする一方で、複数ステップにわたる攻撃を見逃すケースもあると指摘されています。
Giskard Guardsは、AIエージェントと企業システムの間に配置されるランタイムのセキュリティレイヤーとして設計されています。
単にプロンプトや出力をチェックするのではなく、次のような情報をまとめて分析します。
このようにエージェントの実行チェーン全体を監視することで、危険な挙動を本番システムに到達する前に検知することを目指しています。
Guardsの特徴のひとつは、キーワード検出ではなく意図や状況を考慮する文脈ベースの検査です。
リクエストがエージェントの目的、利用可能なツール、アクセス可能なデータとどのように関係するかを評価することで、より現実的な判断を行う仕組みになっています。
Giskard Guardsでは、複数の検知器を同時に動かす「多層防御」の考え方が採用されています。
例えば以下のような検知が組み合わされます。
異常が検出された場合、システムは 許可・監視・ブロック といったアクションを返します。
このプラットフォームのもう一つの重要な考え方が Policy‑as‑Code(ポリシーをコード化する) です。
企業には通常、次のようなガバナンスルールがあります。
Policy‑as‑Codeでは、こうしたルールを自然言語のガイドラインではなく、実行時に強制される機械可読のポリシーとして定義します。
研究でも、AIエージェントのガバナンスではポリシーを実行可能なガードレールへ変換する仕組みが重要だと指摘されています。
Giskard Guardsの設計は、EUのAI規制である EU AI Act の要件とも関係しています。
この法律では、人の安全や基本的権利に影響するAIシステムを「高リスク」と分類し、次のような義務を課しています。
こうした要件は、AIシステムの挙動を継続的に監視し、ログを残す仕組みを必要とします。
そのため、ランタイム監視やポリシー制御を提供するプラットフォームは、企業のコンプライアンス対応にも役立つ可能性があります。
AIエージェントのガバナンスが特に重要になるのは、規制の厳しい産業です。
金融や保険では、AIエージェントが以下のような業務を支援するケースが増えています。
これらの業務では機密性の高い金融データを扱うため、不正な操作や情報漏えいを防ぐ仕組みが不可欠です。
医療分野ではさらに重要度が高く、AIは次のような用途に使われ始めています。
このような場面では、患者データの保護や人間の最終判断を確保するガードレールが不可欠になります。
GiskardはGuardsを、欧州の ソブリンAI(主権型AI) の流れの中で位置付けています。
プラットフォームはオンプレミス環境などでも運用でき、企業が次のような要素を自社インフラ内で管理できるようにすることを目指しています。
これは、EUのデータ保護政策やGDPRの考え方とも整合するアプローチです。
AIエージェントの普及によって、安全対策の焦点は大きく変わりつつあります。
単純なプロンプトフィルターでは、ツール呼び出しやデータアクセスを伴う複雑なワークフローを十分に管理できません。
Giskardのアプローチは、AIの出力ではなく「AIの行動」そのものを監視するという方向性を示しています。
こうしたランタイム型のセキュリティが、大規模な企業環境でどこまで効果を発揮するかは今後の検証が必要です。しかし、AIエージェントが企業の重要業務に入り込むにつれ、こうした仕組みが不可欠なインフラになる可能性が指摘されています。