設計によるエンタープライズセキュリティ
EDDIは設計上、セキュリティ脆弱性のクラス全体を排除します。eval()なし、コード実行ブロックなし、動的コードインジェクションなし、エージェントの動作は宣言的JSON設定のみで定義。
なぜ今これが重要なのか
AIエージェントのエコシステムは前例のないセキュリティ圧力にさらされています。2026年初頭には、主要なオープンソースエージェントフレームワークにおいて、CVSS 10.0のリモートコード実行の欠陥、サンドボックスエスケープ、認可バイパスを含む数百件もの重大な脆弱性が公に文書化されました。その根本原因の多くは、ユーザー提供コードや動的生成コードをランタイムで実行するプラットフォームにあります。
Cloud Security Allianceは体系的な「AIエージェントの開示の空白」を特定しました。
EDDIのアーキテクチャ防御
コード実行をサンドボックス化しようとするのではなく、EDDIは攻撃面を完全に排除します。
セキュリティ機能
- eval()ゼロ、いかなる動的コード実行もなし。エージェントロジックは宣言的JSONのみ
- OIDC/Keycloak、RBACロール(admin、editor、viewer)と専用の承認者ロールを備えたエンタープライズ認証・認可
- ユーザーごとのワークスペース、すべての設定リソースに所有者と個人またはチームのスペースがあり、利用・閲覧・編集・所有の各レベルで明示的に共有
- Connections、外部呼び出しのための単一の認証情報モデル。組織全体のキーやOAuth2サービスアカウントから、各ユーザー自身のOAuthアカウント、呼び出し元システムがリクエストごとに渡す認証情報まで対応。シークレットは常にVault参照です
- ツール結果ガードレール、すべてのツール結果が出所情報を持ち、その中の指示の形をとったテキストは、モデルがそれに基づいて動作する前にマーク、墨消し、警告、またはブロックされます
- Secrets Vault、APIキーのAES-256-GCMエンベロープ暗号化、エクスポート時の自動シークレット除去付き
- パストラバーサル保護、すべての境界での入力検証によりディレクトリエスケープ攻撃を防止
- SSRF保護、URL検証とドメイン許可リストによりサーバーサイドリクエストフォージェリを防止。HTTP呼び出し、MCP、A2Aの宛先では、DNS解決やリダイレクトを経由する場合も含めてクラウドメタデータエンドポイントを拒否
- 暗号化監査証跡、HMAC-SHA256署名付きの改ざん検知可能な操作ログ、エージェントごとの暗号署名付き
- EU AI法対応、規制コンプライアンスのための組み込みガバナンス機能
- シークレット墨消し、APIキー、Vault参照、機密データをすべての監査エントリから自動フィルタリング
- PII安全ロギング、GDPR操作はSHA-256仮名を記録し、生のユーザー識別子は記録しない
- Sigstore Cosign、キーレスOIDCコンテナイメージ署名、公式CIでビルドされたDockerイメージを暗号的に検証
- 強化されたベースイメージ、ダイジェスト固定のRed Hat UBI 10ランタイム、Red Hat認定カタログで公開
- シークレットコンテキスト値、呼び出し元は1ターンだけ使える認証情報をエージェントに渡せます。この値は保存も返却もされません
- 制限付きランタイムテンプレート、ランタイムデータから構築されたテンプレートは、設定やBeanにアクセスできずレンダリングごとの上限がある制限付きエンジンで描画され、ユーザー入力は常にデータとして代入され、テンプレートとして解析されることはありません
自動セキュリティパイプライン
すべての変更は自動セキュリティツールを通過し、すべてのGitHub Actionはサプライチェーン攻撃を防ぐためSHAでピン留めされています:
- CodeQL、
security-extendedクエリによるセマンティックSAST分析 - Trivy、ファイルシステム依存関係とDockerイメージのCVEスキャン(CRITICAL/HIGHでブロック)
- Gitleaks、シークレットと認証情報の漏洩を防ぐGit履歴スキャン
- Dependency Review、既知の脆弱性を持つ新しい依存関係を、それを追加するpull request上でフラグ付け
- CycloneDX、サプライチェーン透明性のためのSBOM生成
- ClusterFuzzLiteとJazzer、セキュリティクリティカルなパーサー向けカバレッジガイド付きファズテスト
- OpenSSF Scorecard、リポジトリのサプライチェーンセキュリティ対策を継続的にスコアリング
ルールをモデルの外に置く理由
ツールを持つエージェントにとって重要な攻撃はプロンプトインジェクションです。ツールを使うエージェントを対象としたあるベンチマークでは、防御がない場合、チケットやログに隠された指示によって、エージェントは82.5%の確率で安全でない操作を実行しました。プロンプトレベルの防御では10〜26%が安全でないまま残り、ツール呼び出しで強制されるポリシーゲートだけが、承認済みの変更は通しつつゼロを達成しました。だからEDDIは、注入されたテキストが言いくるめて突破できないエンジン内部のツール境界でルールを強制します。研究の一覧はエビデンスページにあります。
ハードニングログ
セキュリティ対策は継続的な取り組みであり、見つかった内容は公開しています。最近の実施内容:
- 2026年10月(6.6.0)、シークレットの扱い、認可の抜け、外部リクエスト、デプロイのデフォルトにわたるハードニング。6.5.0以前で出荷されたコードの修正も含むため、新機能にかかわらずアップグレードを推奨します
- 2026年9月(6.5.0)、テンプレートインジェクション、外部呼び出しのSSRF、Vaultキーの扱い、シークレットのスコープ、ワークスペースの認可、チャネルのID管理、EDDIマネージャーのセキュリティUIにわたる約30件の修正を含むレビュー。各修正には回帰テスト付き
- 2026年8月(6.3.0, 6.4.0)、外部向けの認証情報をConnectionsに統合し、ツール結果に出所情報を付与して指示のような形式のテキストを墨消しし、エージェントへのVault権限付与を強制
- 2026年7月(6.2.0)、ツール結果キャッシュをIDごとにスコープ化し、ライブのツールトレースからシークレットを墨消しし、監査HMACの比較を定数時間化
ガバナンスとコンプライアンスの統合
セキュリティ機能はEDDIのコンプライアンスフレームワークに直接つながっています。不変の監査証跡はEU AI法の記録保持要件(第12条)を支え、パイプライントレースはAIの意思決定の透明性(第13条)を提供し、管理UIは緊急停止機能による人間の監督(第14条)を可能にします。同じインフラストラクチャが、GDPR、HIPAA、SOC 2、さらに15+の規制フレームワークを、1つの統一APIでサポートします。
