コードは止まり、エージェントが動く - AgentSecOpsの時代へ

Posted at 2025-06-03

1. 序論: DevSecOpsを超えるAgentSecOpsの必要性

AIエージェントベースの自動化システムが拡大し、組織内資産やAPIへのアクセス方法が根本的に変化しています。LangChain、CrewAI、AutoGPTなどのフレームワークは、単なる自動化レベルを超えて、実行主体（エージェント）が独立して意思決定し外部システムを呼び出す構造を現実化しています。これらのシステムを包括的に運用する概念がAgentOpsです。AgentOpsはLLMベースのワークフロー最適化、ツール呼び出しスケジューリング、結果解釈およびレポート自動化など多様な機能を含みます[1]。

AgentOpsは単一の概念ではなく、エージェント実行構造に応じて明確に区分される実行タイプを基盤に構成されます。実際の組織環境でAIエージェントが業務を自動化する方式は大きく2つに分かれ、この実行構造によってセキュリティ介入ポイント、監査フロー、ポリシー評価方式も異なります。

第一は順次実行型AgentOpsです。これは1つのエージェントがユーザーリクエストを受けて複数のツールやAPIを段階的に直列実行する構造です。例えば、ユーザーが「来週の東京出張を準備して」と指示すると、エージェントは次の順序で実行します：

航空券予約API呼び出し
ホテル予約プラットフォーム連携
カレンダーAPIでスケジュール作成
メールAPIでユーザーに結果通知

このフローは1つのコンテキスト内で処理され、単一実行フローに対してリトライ、ポリシーチェック、ロギング、承認挿入などの制御が必要です[1]。

第二はエージェント間呼び出し型AgentOps、すなわちAgent-to-Agent構造です。この構造は1つのエージェントが直接すべての作業を行わず、役割を分散して他のエージェントを呼び出す多段階実行フローを構成します。例えば、「マーケティングレポートを作成して」というリクエストが来た場合：

Agent A1は全体フローを企画し、
Agent A2はデータ収集を担当し、
Agent A3は要約と可視化を担当します。
最終的にAgent A1が結果を統合してレポートを完成させます。

各呼び出し間にはコンテキスト伝達、役割委任検証、ポリシー衝突検出、実行権限チェックが必要で、各エージェントは独立してポリシー評価（PDP）、実行制御（PEP）、監査ロギングが行われる必要があります[3]。

この2つの構造はAgentOpsを理解しセキュリティ制御を設計する上で非常に重要な基準となります。セキュリティポリシー挿入位置、制御主体、実行フローの予測可能性が構造ごとに異なるため、これを明確に区分しないとポリシーが無力化されたりロギングが抜け落ちるなどの問題が発生します[4][5]。



[図1] AgentOps 実行構造タイプ比較

区分項目	順次実行型AgentOps	Agent-to-Agent構造 (A2A)
実行方式	単一エージェントが直列API呼び出し	複数のエージェントが役割ベースで分散実行
実行フロー	固定された順序、予測可能	動的な呼び出し経路、フロー分岐可能
ポリシー挿入位置	単一フロー内に順次挿入	各呼び出し間にインターフェースごとに個別挿入必要
PDF評価範囲	全体フローに対して1回ポリシー評価	各呼び出しに対して別途PDP評価必要
委任検証必要性	不要 (単一主体)	必要 (主体間委任関係検証必要)
監査ロギング構造	単一セッションベースのログ	多段階セッションおよび呼び出し連携ロギング必要
例	出張予約、メール送信、会議作成等	レポート作成、ワークフロー自動化、マルチSaaS統合

これらのAgentOps実行構造は、従来のDevSecOps体制で定義されたリリース中心のセキュリティモデルでは制御できません。コードコミットやデプロイなしで実行が可能で、実行主体が人間かエージェントか明確でなく、実行目的さえ明示されない可能性があるためです。AgentSecOpsはこれらの実行フローにポリシーベースの制御を挿入し、各実行単位に対して承認、権限評価、ログ記録をリアルタイムで実施する構造に設計されている必要があり、この役割はAgentOpsアーキテクチャ上でのみ可能になります[16][17]。

従来のDevSecOpsは、静的解析(SAST)、動的解析(DAST)、IaCセキュリティ検査、イメージスキャン、SCA(Software Composition Analysis)、秘密鍵露出検出など多様なセキュリティモジュールをCI/CDパイプラインに統合することにより、コードレベルのリスクを事前に特定し除去する体制を持っています。SCAはオープンソースライブラリおよび依存関係内のセキュリティ脆弱性、ライセンス違反、保守状態などを分析し、最近のGitHub Advanced Security、Snyk、WhiteSourceなどのツールがこれを自動化しています[2]。

次のダイアグラムはGitHub中心のコード作成後、JenkinsやGitHub Actionsでイメージビルドが行われ、Harborでイメージ脆弱性を検査し、問題がない場合AWS ECRにデプロイされるフローを示しています。これ以降ArgoCDを通じてKubernetesクラスタにデプロイされ、このプロセスでVaultを通じてシークレット管理、ZAPを通じてDASTセキュリティテスト、HelmとTerraformを通じてインフラ構成検証まで含まれています。



[図2] DevSecOps パイプライン

このような現代的なDevSecOpsパイプラインは、様々なセキュリティ機能を統合することにより、デプロイ前後の静的および動的リスクを包括的に管理できます。コード解析、イメージ整合性検証、オープンソース依存関係脆弱性検出(SCA)、IaCポリシー違反検出、ランタイムワークロード保護、クラウド構成解析(CSPM)、権限解析(CIEM)、統合CNAPPベースの制御まで含まれています。しかし、この全体構造は人間主体がコードを作成し、明示的なリリースフローに従わない限り、制御は不可能です。

AIベースAgentOpsはこれとは異なる方式で動作します。エージェントはGitHubリポジトリに直接APIを呼び出すか、Slackにメッセージを送信するか、AWS Lambdaをトリガーするか、など、事前に定義されていない実行フローを生成できます。これらの実行フローはCI/CDに統合されず、GitコミットやJenkinsログなしでも発生します。結果的に、従来のDevSecOps体制で定義されたセキュリティ制御パスを踏襲しない実行が頻繁に発生することになります[3]。

このような実行フローに対しては、DevSecOpsのすべてのセキュリティ制御が適用されないか、または全く後続の対応が不可能になる可能性があります。例えば、この実行はイメージスキャンやIaC検査、承認などの事前のセキュリティ検査を回避することになります。このような構造的な空白に対応するために、AgentSecOpsが登場しました。

AgentSecOpsはAIエージェントの実行リクエストを収集し、ポリシーベースでそのリクエストを評価し、承認の有無をリアルタイムで判断するセキュリティレイヤーです。この構造は、DevSecOpsと並行して存在するものではなく、実行時点で介入可能な別のポリシー制御領域に該当します。

2. DevSecOpsとAgentSecOpsの構造比較

DevSecOpsはソフトウェア開発パイプラインにおいてセキュリティを自動化する体制であり、コード作成段階から運用環境まで連続的にセキュリティ活動を段階的に実現することが核心です。初期段階では静的解析(SAST)と脆弱性スキャン程度に留まりましたが、最近ではオープンソースライブラリの構成および脆弱性評価(SCA)、インフラ構成コード(IaC)のポリシー違反検出、イメージ脆弱性検査、シークレット露出防止など多様な機能が統合されています。



[図3] クラウド環境におけるDevSecOps Pipelineの脆弱性管理

クラウド環境では、CSPM(Cloud Security Posture Management)、CIEM(Cloud Infrastructure Entitlement Management)、CWPP(Cloud Workload Protection Platform)などのプラットフォームも含まれているため、DevSecOpsは1つのセキュリティ生態系と進化しています[4]。



[図4] クラウド環境に適した脆弱性管理方法

DevSecOpsはコードベースで定義された資産を基準にセキュリティを実施します。GitHub、GitLabなどのソースリポジトリでコードがコミットされると、CI/CDツール(Jenkins、GitHub Actionsなど)がこれをビルドし、テストします。このプロセスでSCAツールはオープンソース脆弱性を特定し、イメージ解析ツールはコンテナセキュリティ脅威を評価し、IaCテンプレートは規定遵守の有無を検査します。配備段階ではCSPMやCWPPが構成エラーとランタイムパフォーマンスを監視します[5]。

しかし、この全体構造はコードが明示的に存在し、人間が定義したパイプライン内でのみ有効です。LLMベースのエージェントは開発者が作成しないコードを実行し、スクリプトなしでAPI呼び出しを行うか、内部システムに直接アクセスします。GitコミットなしでSlackにメッセージを送信し、JenkinsログなしでAWS Lambdaをトリガーし、事前に定義されていない目的に従って実行します。このような実行はDevSecOpsで定義されたセキュリティ制御ポイントを回避することになります[6]。

AgentSecOpsはこのような動的実行リクエストに介入する構造であり、実行時点でのポリシー(PDP: Policy Decision Point)を評価し、実行目的(PBAC: Purpose-Based Access Control)を基準に権限を検証し、承認フローと監査ロギングを統合します。この構造は、単一実行単位に対するリアルタイム制御を目的としており、DevSecOpsの静的解析や事前防御モデルとは全く異なる制御位置を持っています。

次のダイアグラムは、時間軸を基準にしてDevSecOpsとAgentSecOpsの介入ポイントを比較したものです。



[図5] DevSecOps vs AgentSecOps 制御フロー

DevSecOpsは実行前のコードと資産の状態を評価し、AgentSecOpsは実行時点の行為とポリシーの衝突の有無を判断します。AgentSecOpsは次のようなセキュリティ要件を満たすために設計されています。

実行リクエストの主体識別
実行目的とリソース間のポリシーの衝突の有無確認
承認リクエストフローを基準とした事前制御挿入
実行ログおよび監査記録のセッション単位追跡

AgentSecOpsは、DevSecOpsを単なる補完概念ではなく、実行フローのリアルタイム制御という独立したセキュリティレイヤーとして理解する必要があります。特にAIエージェントが意思決定と実行を同時に行う環境では、ポリシーベースの動的承認システムなしではセキュリティ責任追跡が不可能になる可能性があります[7]。

3. 構造分析: AgentSecOpsを構成する実行制御アーキテクチャ

AgentSecOpsは単なる実行モニタリング体制ではなく、実行リクエストを中心にポリシーを適用し、そのフローを動的に評価するリアルタイム制御アーキテクチャです。DevSecOpsがコード、イメージ、構成ファイルを基準に静的または事前定義された検査を実施するのとは異なり、AgentSecOpsは実行主体と実行コンテキストを中心にポリシーを動的に評価します[8]。

このアーキテクチャは次のような重要な構成要素で構成されます。

3.1 ポリシー決定ポイント(PDP: Policy Decision Point)

PDPは実行リクエストを受け取った後、そのリクエストが許可可能かどうかを判断する中央ポリシーエンジンです。このエンジンはYAMLまたはRego(Cedar等)形式のポリシー定義ファイルを基盤にして、実行主体、リソース、目的、時点などの条件を評価します。例えば、次のようなポリシーが適用される可能性があります。

リクエスタの役割が'AI Agent'であり、
実行対象が'GitHub Repository'であり、
目的が'PR 統合'の場合、
ワークスペース外部ソースへのアクセスが制限される時間帯には拒否処理

ポリシーは通常Open Policy Agent(OPA)、Cedar、Kyvernoなどのツールで実現されます[9]。

3.2 目的ベースの権限検証 (PBAC: Purpose-Based Access Control)

PBAC(Purpose-Based Access Control)は、実行の'目的'を基準にアクセスを判断する権限制御モデルです。RBAC(役割ベースアクセス制御)は、ユーザーまたはエージェントの役割(role)を、ABAC(属性ベースアクセス制御)はユーザーとリソースの属性(attribute)を基準にポリシーを適用します。一方、PBACは、実行リクエスト時に一緒に明示される意図(purpose)を中心にポリシー判断を行います。

このアクセスは、次のような実行時点のセキュリティシナリオで特に効果的です：

実行主体が人間ではなくAIエージェントまたは自動化されたシステムの場合
1つのAPIリクエストが様々な目的に分岐する必要がある場合
実行の正当性を事前に定義された'目的'に基づいて分類する必要がある多階層セキュリティ環境

例: Google Driveファイル共有

AIエージェントが会社の文書を自動的にGoogle Driveで共有すると仮定します。この場合、目的が"内部チーム間の共同作業"の場合にはSlack、Notionなどの組織内共有プラットフォームを通じて許可される可能性があります。一方、目的が"外部パートナー検討用"の場合には、セキュリティポリシー上で追加の検討や承認手続きが必要です。PBACを利用することで、同一の共有APIリクエストに対しても、実行目的に応じてポリシー結果を異なるものとすることができます。

ポリシーの例

allow {
    input.purpose == "internal_collab"
    input.user.role == "ai_assistant"
    input.resource.type == "gdrive.document"
    input.resource.sharing == "organization"
}

このポリシーは、次の条件を満たす場合に文書共有を許可します：

実行目的が"internal_collab" (内部共同作業用共有)
リクエスタの役割が"ai_assistant"
リソースがGoogle Driveの文書であり、共有範囲が組織内部(organization)に限定されている

同じAPI呼び出しでも、目的が"external_partner_review"の場合 input.context.approval == trueという追加条件がない場合、共有が拒否されます。

活用シナリオ比較

実行目的	許可の有無	必要なポリシー条件
`internal_collab` (内部共同作業)	許可	組織内部共有、エージェントの役割確認
`external_partner_review`(外部共有)	条件付き許可	NDA確認、承認フラグ存在 (`approval == true`)
`public_share` (公開リンク共有)	拒否	会社のセキュリティポリシー上で全体公開は許可しません

PBAC vs RBAC vs ABAC 比較表

項目	RBAC	ABAC	PBAC (Purpose-Based)
基準要素	役割(Role)	属性(Attribute)	目的(Purpose)
実行意図反映	不可能	制限的 (属性による回避可能)	可能 (明示的な目的に基づく判断)
複合条件表現力	低い	高い	中間 (属性と組み合わせ可能)
ポリシー設計難易度	低い	高い	中間
主使用シナリオ	内部利用者の権限区分	精密なリソースアクセス制御	AI、RPA、エージェントベースの自動化
例	"adminのみアクセス可能"	"部署=財務 AND 等級=5以上"	"目的=通知広報の場合のみ許可"
実行時点の制御適合性	低い	条件付き可能	高い (実行直前の目的評価可能)

PBACは、実行目的とコンテキスト的合理性を目的単位で分岐評価できるため、AgentSecOps構造内で実行時点のポリシーの重要な評価基準となります。これは、特にエージェントが自立的にSaaS APIを呼び出し、内部/外部境界を越えて自動化を実行する場合、従来の権限モデルだけでは制御不可能な実行意図ベースのセキュリティ判断の解決策となります[10]。

3.3 ポリシー実行ポイント(PEP: Policy Enforcement Point)

PEPはPDPの評価結果を受けて、実際の実行を許可または拒否するモジュールです。エージェントが外部API呼び出しを試みるとき、そのリクエストはまずPEPを通過します。PEPは内部プロキシ、ミドルウェアAPI、エージェントランタイムスクリプトなど、様々な場所に挿入できます。

例えば、Slack APIミドルウェアに挿入されたPEPは、メッセージ送信前にPDPにポリシー評価リクエストを送信し、結果に応じてメッセージを拒否または承認します。これにより、エージェントの無断実行を事前に防ぐことができます。

3.4 ポリシー情報提供者(PIP: Policy Information Point)

PIPはPDPがポリシー評価時に参照する外部データを提供します。ユーザーの役割、認証状態、現在時刻、エージェントコンテキスト、作業経路、最近の実行履歴などはPIPから収集されます。この情報は、実行リクエストのコンテキストを構成し、ポリシー判断の精密さを高めます。

3.5 監査記録およびセッションベースのロギング

実行リクエストが許可されたり拒否されたり、どちらの場合でも、すべてのポリシー評価および実行履歴はセッションベースで保存されます。これにより、管理者は個別の実行フローを復元し、特定のAIエージェントがどのようなリクエストを実行したかを視覚的に分析できます。この構造は、後のフォレンジック、セキュリティ監査、規制対応に非常に重要な役割を果たします。

次はAgentSecOps構造の重要なコンポーネント関係を示すダイアグラムです。



[図6] AgentSecOps コンポーネントアーキテクチャ

この構造を通じて、AgentSecOpsは実行主体のコンテキストを理解し、リアルタイムでポリシーを適用し、実行経路を追跡可能にします。これは単なるモニタリングではなく、実行制御を行う統合セキュリティアーキテクチャとして定義できます[11]。

4. 脅威シナリオ分析: AgentSecOpsによる実行可能な脅威タイプ

AIベースのエージェントは、人間の介入なしにAPI呼び出し、文書作成、メッセージ送信、クラウド資産変更などを実行できます。このような自律的実行環境では、認証、承認、記録、責任追跡が不明確な実行が繰り返し発生することになり、これにより従来のセキュリティモデルが制御できない新しい脅威タイプが登場します。AgentSecOpsは、このような実行時点の脅威を事前に検出し、防止するための構造に設計されています[12]。

次はAIエージェント環境で発生する可能性のある主要なシナリオ5つと、それに対するAgentSecOpsアーキテクチャの対応構造です。

4.1 役割外実行発生 (Privilege Escalation via Agent Context)

AIエージェントが特定のユーザーの資格情報を基準に実行されるが、実際にはそのユーザーが許可を受けていないリソースにアクセスしたり、実行コマンドを伝達する状況が発生する可能性があります。例えば、組織内の'一般社員'であるユーザーAが特定のGoogle Drive文書に対する要約をリクエストしたとき、エージェントがAPIを通じて文書にアクセスするプロセスで、内部人事情報が含まれた機密文書(tag: confidential)にアクセスした後、それを外部チャンネルや他のユーザーに伝達する方法です。これは、ユーザーAの役割に対して明確にアクセスが制限されたリソースに対して、エージェントが実行目的を逸脱したり、コンテキストを回避して権限上昇(Privilege Escalation)を引き起こしたシナリオです。

AgentSecOpsは、このような実行リクエストに対して、実行主体(user.role)、実行目的(purpose)、リソース属性(resource.tag)を総合的に評価し、実行時点で動的にアクセスを制御します。特に、役割ベースのアクセス制御(RBAC)だけでは、実行意図の分離が難しい環境では、目的ベースのアクセス制御(PBAC)を通じて精密な制御が可能です。

次は、そのシナリオに対応するポリシー定義の例です。

default allow = false

allow {
    input.user.role == "employee"
    input.resource.type == "gdrive.document"
    input.resource.tag != "confidential"
    input.purpose == "summary"
}

このポリシーは、次の条件をすべて満たす場合にのみ実行を許可します。

リクエスタの役割がemployeeです。
リクエスト対象のリソースはGoogle Drive文書(gdrive.document)です。
文書のセキュリティタグがconfidentialではありません。
実行目的が"summary"と明示されています。

ポリシー評価に応じた実行結果は次のように分岐します。

実行条件	実行の有無	判断根拠
一般社員が一般文書を要約目的でリクエスト	許可	すべての条件を満たします
一般社員が機密文書を要約目的でリクエスト	拒否	文書のセキュリティタグ条件を満たしていません
一般社員が要約以外の目的(例: translate)でリクエスト	拒否	実行目的が一致していません
管理者が機密文書にアクセスリクエスト	外部	別途管理者の権限ポリシー定義が必要

PBACは、実行目的をポリシー評価基準に明示することにより、実行時点で発生する可能性のあるさまざまなコンテキスト分岐を制御できます。特にAIベースの自動化構造では、ユーザーと実行主体が分離されるため、実行目的を中心にしたポリシーモデルがAgentSecOps内で重要な役割を果たします。

4.2 委任範囲外使用 (Delegation Misuse and Overscope Execution)

AIエージェントが他のユーザーを代わりに権限を委任して実行する構造は、組織内の自動化システムでよく見られるパターンです。しかし、この場合、エージェントが委任された範囲を逸脱したり、意図しないAPI呼び出しを実行すると、実行主体と権限責任の間に不一致が生じ、セキュリティ事故につながる可能性があります。

例えば、プロジェクト管理者がJiraプロジェクトの特定のイシュー登録権限をエージェントに委任したが、そのエージェントが承認を受けていない外部プロジェクトボードにイシューを生成したり、Epic単位の高リスク項目まで自動的に登録する場合があります。これは、ユーザーが承認した範囲を超えた実行になるため、委任範囲外使用に該当します。

AgentSecOpsは、委任実行構造に対してdelegated_by、resource.id、purposeなどの実行コンテキスト情報を総合的に評価し、委任範囲の適切性を動的に判断できるようにします。次は、そのシナリオに対応するポリシーの例です。

default allow = false

allow {
    input.delegated_by == "user_123"
    input.user.role == "ai_issue_creator"
    input.resource.id == "jira-project-X"
    input.purpose == "task_registration"
}

このポリシーは、次の条件をすべて満たす場合にのみ実行を許可します。

実行がuser_123から委任されたことを明示する必要があります。
実行主体の役割がai_issue_creatorでなければなりません。
Jiraプロジェクトボードは"jira-project-X"に限定されている必要があります。
実行目的が"task_registration"として定義されている必要があります。

ポリシーに応じた実行分岐は次のようになります。

実行条件	実行の有無	判断根拠
委任者が`user_123`で、`jira-project-X`にイシュー登録	許可	委任条件とリソース範囲の両方を満たします
委任者は同じであるが、異なるプロジェクト(`jira-project-Y`)に登録	拒否	リソース範囲超過
実行主体の役割が`ai_issue_creator`ではない場合	拒否	委任実行主体の条件を満たしていません
実行目的が`"task_registration"`ではない場合	拒否	承認された実行目的の条件を満たしていません

委任ベースの自動化環境では、委任者の承認と実行主体の権限が分離されて発生するセキュリティの脆弱性が存在します。AgentSecOpsは、実行時点でこのような委任関係をコンテキストベースのポリシーで検証できるようにし、委任範囲に対するポリシーの明細を通じて実行フローを安全に制限できるようにします。

4.3 トリガー使用による外部API拡張 (Trigger Abuse and External API Expansion)

AIエージェントは、外部システムから発生したイベントを基準に実行する構造をよく使用します。代表的な例としてGitHubのwebhookイベントがあります。しかし、このように外部イベントに基づいて動作するエージェントは、事前に定義されていない外部システムや内部の高リスクリソースまで拡張実行を試みる可能性があります。この場合、実行の発信元と目的が一致しなくなり、トリガー使用に該当します。

例えば、GitHubリポジトリにコードがプッシュされたときにエージェントがビルド自動化を実行することは、許可された目的である可能性があります。しかし、そのトリガーを利用してAWS環境に新しいEC2インスタンスを作成したり、GitLabに並列作業を作成したり、など、事前に明示されていない実行拡張まで行われる場合、これはセキュリティ違反と見なされます。

AgentSecOpsは、トリガーの発信元(trigger.source)と呼び出し対象リソース(resource.domain)が、事前に定義された条件と一致するかどうかを確認し、実行目的(purpose)とも比較して動作を制限します。次は、このシナリオに対するポリシー定義の例です。

default allow = false

allow {
    input.trigger.source == "github"
    input.resource.domain == "github.com"
    input.purpose == "ci_pipeline"
}

このポリシーは、次の条件をすべて満たす場合にのみ実行を許可します。

トリガーはGitHub webhookから発生する必要があります。
リソースのドメインはgithub.comに属している必要があります。
実行目的は"ci_pipeline"として明示されている必要があります。

ポリシー評価に応じた実行分岐は次のようになります。

実行条件	実行の有無	判断根拠
GitHubイベントベース、GitHub内のビルド自動化実行リクエスト	許可	発信元とリソースのドメインが一致します
GitHubイベントベース、AWS EC2実行リクエスト	拒否	トリガーの発信元とリソースのドメインが一致しません
GitLabイベントベース、GitHub作業リクエスト	拒否	トリガーの発信元が一致しません
GitHubイベントベース、目的が`"deployment"`として明示された実行リクエスト	拒否	承認された実行目的の条件を満たしていません

AgentSecOpsは、外部イベントベースのトリガーの発信元と実行目的の間のポリシー的整合性を評価することにより、事前に定義されていない実行拡張を事前に防止できます。この構造は、特に複数のSaaS環境で発生する可能性のある、無差別的なAPI接続試行を制御するのに効果的です。

4.4 実行経路不透明性 (Execution Path Obfuscation)

AIエージェントが様々なシステムと連携して、自律的に実行リクエストを実行する環境では、実行結果だけが記録され、そのリクエストが誰によって、いつ、どのような条件で実行されたかを追跡するのが難しい場合が発生する可能性があります。これは、セキュリティ事故発生時に行為主体を特定するのが困難になり、フォレンジックとコンプライアンス対応に深刻な問題を引き起こす可能性があります。例えば、エージェントがGoogle Calendar APIを呼び出して、組織全体の会議を自動的に生成したが、そのリクエストが誰のユーザーまたはエージェントIDによって実行されたか、実行目的が何であったか、どのような条件の下で呼び出されたかが、実行ログに残されていない場合があります。このような状況は、実行結果は存在するが経路が特定できない可視性の特定が困難な実行フローであり、攻撃者がログ操作や意図的回避を試みた場合、セキュリティの盲点になる可能性があります。

AgentSecOpsは、すべての実行リクエストに対して、事前に定義されたコンテキスト必須項目を要求します。PDPは、ポリシー評価時にこのような項目が存在しない場合、または欠落している場合、そのリクエストを拒否できます。すべての実行フローは、セッション単位で監査ログに保存される必要があります。

次は、そのシナリオに対するポリシー定義の例です。

default allow = false

allow {
    input.user.id
    input.session.id
    input.resource.id
    input.purpose
}

このポリシーは、次の必須項目がすべて存在する場合にのみ実行を許可します：

ユーザーID(user.id)
セッションID(session.id)
リソースID(resource.id)
実行目的(purpose)

このようなポリシーは、実際の評価ロジックではなく、実行リクエストフォーマットの整合性を検証する役割を果たします。必須項目が欠落したリクエストは、実行前の段階で拒否され、正常な実行の場合でも、すべてのコンテキストはセッションログに記録されます。

ポリシーに応じた実行分岐は次のようになります。

実行条件	実行の有無	判断根拠
すべての必須項目(user, session, resource, purpose)が含まれたリクエスト	許可	リクエスト構造が完全です
session.idが欠落したリクエスト	拒否	実行経路の追跡が不可能です
purposeフィールドがない自動化リクエスト	拒否	実行目的が不明確、ポリシー評価不可能
エージェントが非特定状態でリクエストした場合	拒否	user.idが未確定、責任追跡不可能

AgentSecOpsは、実行リクエストが単なる成功だけではなく、そのリクエストがどのようなコンテキストと条件の下で実行されたかを含めて判断します。このような実行コンテキストの整合性は、単なるセキュリティ評価だけではなく、セキュリティ事故対応、行為監査、ポリシー改善のための重要な基盤情報となります。

4.5 AI出力ベースの自動実行誘導 (Prompt-to-Execution Abuse via LLM Output)

AIエージェントが大規模言語モデル(LLM)の応答を基準に外部システムを呼び出す構造では、プロンプト入力結果から生成された応答が意図しない実行を引き起こす可能性が存在します。特にLLMの応答がAPI呼び出しに直接関連する構造の場合、悪意のあるか、不明確な入力により、高リスクのコマンドが自動的に実行される可能性があります。

例えば、ユーザーが「テストサーバー整理して」と自然言語でリクエストした場合、LLMがこれをaws ec2 terminate-instances --allとして解釈し、エージェントがこれを実際に実行した場合、これは明白なPrompt Injectionベースの実行事故に該当します。

このような状況では、実行リクエストが意図された目的とポリシー条件を満たしているかどうかを明確に判断する必要があり、特に高リスクキーワードが含まれた応答に対しては、追加の承認を要求するか、自動的に実行を拒否する必要があります。

次は、そのシナリオに対応するポリシー定義の例です。

default allow = false

allow {
    not contains(input.llm_response, "terminate")
    not contains(input.llm_response, "delete")
    not contains(input.llm_response, "format")
    input.purpose == "maintenance"
    input.context.approved == true
}

このポリシーは、次の条件を満たす場合にのみ実行を許可します。

LLM応答内にterminate、delete、formatなどの高リスクキーワードがないこと
実行目的は"maintenance"として明示されていること
実行リクエストは、事前に管理者またはポリシー管理システムによってapproved == trueとして承認されている必要があります

ポリシー評価に応じた実行分岐は次のようになります。

実行条件	実行の有無	判断根拠
LLM応答に高リスクコマンドがなく、承認されたメンテナンスリクエスト	許可	目的と承認が両方満たされます
応答に`"terminate"`が含まれている場合	拒否	高リスクキーワードが含まれています
承認されていないリクエスト(`approved == false`)	拒否	二重承認条件を満たしていません
実行目的が`"cleanup"`などの不明確なテキストとして伝達される場合	拒否	ポリシー内で明示された目的と一致しません

AgentSecOpsは、実行リクエストのコンテキストだけでなく、実際の実行文の内部内容までも評価条件に含めることができます。これは、LLMと自動化された実行階層が連携する際に必然的に必要となるセキュリティ構造であり、Prompt-to-Execution経路の安全性を確保するために二重承認フローとキーワードベースのフィルタリングを並行して適用する必要があります。

次は、脅威シナリオとAgentSecOpsの対応コンポーネント間の関係を整理したマッピングダイアグラムです。

脅威シナリオとAgentSecOps対応コンポーネントマッピング表

脅威シナリオ	対応コンポーネントおよびメカニズム
エージェント・コンテキストによる特権のエスカレーション	PDP + PBAC 目的ベースのポリシー評価
委任の悪用とオーバースコープ実行	委任メタデータ確認(PIP) + ポリシー内の委任範囲制限(PDP)
トリガーの悪用と外部APIの拡張	PDP + PBAC 目的ベースのポリシー評価
実行パスの難読化	ユーザーID、セッションID、実行目的フィールド存在確認(PDP) + 監査ログ記録
LLM出力によるプロンプトから実行への悪用	LLM応答キーワードフィルタリング(PDP) + 承認フラグ存在確認 + 目的検証(PDP)

AgentSecOpsは、DevSecOpsと補完的関係にあり、DevSecOpsが実行前・中・後にわたって多様なセキュリティ自動化を含む構造に拡張されていますが、実行リクエスト単位のポリシー判断と目的ベースの制御面では、依然として補完が必要な点が存在します。特に、エージェントベースの自律的実行環境では、DevSecOpsが捉えられない実行目的、委任範囲、トリガー発信元などのコンテキストをAgentSecOpsがポリシー的に制御することにより、実行時点のセキュリティの空白を埋めることができます[13]。

5. 戦略提案: AgentSecOps設計および導入のための技術戦略

AgentSecOpsは、従来のセキュリティ体制とは全く異なる介入ポイントとポリシー評価基準を要求します。そのため、このアーキテクチャを組織に実質的に適用するためには、設計方法だけでなく、ポリシー構成、実行フロー統合、監査体制設計まで含む構造的戦略が必要です[14]。

5.1 実行フロー統合のためのアーキテクチャ戦略

AgentSecOpsは、エージェント実行リクエストが発生する時点で介入し、そのリクエストの実行を拒否または許可する構造です。そのため、エージェントが呼び出す外部システム(API、SaaSなど)に対して、中間でポリシー評価リクエストを挿入できる構造が必要です。

ミドルウェアベースの構造: API呼び出し前にポリシー検証レイヤーを挿入してリクエストを評価します。
プロキシベースの構造: すべてのエージェント呼び出しをMCP(Model Context Protocol) ProxyまたはAPI Gatewayを通じて中継します。
Webhook Wrapper構造: GitHub、Slack、Jiraなどのイベントベース呼び出し前後にポリシー確認段階を挿入します。



[図7] MCP PAM アーキテクチャ

このようなアーキテクチャは、従来のシステムを変更することなく挿入可能であり、APIプロキシベースのポリシー挿入方式は、特にSaaSベースの呼び出しで有用です。

現在、ほとんどの組織はTerraform、CloudFormation、PulumiなどのIaCツールを通じてAWSベースのインフラリソースを非常に精密に宣言的に制御しています。このような環境では、実行主体が人間の場合でも承認を伴うリリース手続きを要求し、自動化だけでなく、制御された形式で制限されます。そのため、AI Agentが直接的にAWSリソースを生成したり、操作したりする形式は現実的に不可能です。



[図8] IaC セキュリティフロー

しかし、最近のLLMベースのエージェントがIaCテンプレートを生成したり、GitOpsベースのワークフローを自動的にトリガーする形式になり、IaC前段の設計フローに介入する可能性が高まっています。実際に一部の開発型エージェントは、このようなフローを実験的に実装しています。このような転換が可視化される状況で、セキュリティポリシーがない状態でエージェントがIaCと連携すると、リソース生成と権限分配の責任追跡が不可能になる可能性があります。実行フロー内の制御階層が必ず先行される理由です。

5.2 ポリシー構成および監査戦略

実行リクエストは、単なる呼び出しではなく、主体、目的、時点、コンテキストをすべて含む複合条件として判断される必要があり、これに応じてポリシー構成も3段階に分ける必要があります。

主体特定 (Who): 実行リクエスタが誰か (user_id, agent_id, groupなど)
目的明示 (Why): そのリクエストの明示的な目的は何か (例: aws.ec2.start)
コンテキスト判断 (When/Where): リクエスト時刻、位置、承認履歴、セッション接続など

次は、AWS EC2インスタンス起動リクエストに対してポリシーを適用した例です。

# 実行リクエストを許可するための基本条件はfalseに設定
default allow = false

# ポリシー許可条件の定義
allow {
    
    # 実行目的がEC2インスタンス起動の場合
    input.purpose == "aws.ec2.start"
    
    # リクエスタの役割が'ai_provisioner'である場合 (AIベースのリソース割り当て専用の役割)
    input.user.role == "ai_provisioner"
    
    # リソースのタイプがEC2インスタンスである場合
    input.resource.type == "aws.ec2.instance"
    
    # 実行リクエストが午前9時から午後6時の間にのみ許可
    input.context.time_hour >= 9
    input.context.time_hour < 18
}

このポリシーは、実行目的、ユーザーの役割、リソースの種類、実行時点を考慮して、セキュリティポリシーの精密さと実行制御の可能性を高めます[15]。

5.3 実行記録および監査体制設計

AgentSecOpsは、ポリシー判断を通じて実行を許可または拒否するだけでなく、その実行がどのようなコンテキストで発生したかを正確に記録する機能が不可欠です。特にAIエージェントが様々な権限を委任されて、自律的に行動する構造では、単なる承認/拒否の結果だけでは責任追跡が困難です。そのため、実行に使用されたすべてのコンテキスト情報とポリシー評価結果をセッション単位で監査ログに記録する体制が不可欠です。

このような記録の核心は、ポリシー判断ポイント(PDP)ではなく、ポリシー評価時に参照されるコンテキスト情報(PIP)から始まります。PIPは、実行リクエストに含まれるか、外部から収集されたユーザー情報、セッション情報、リソース特性、実行目的、トリガー情報、時刻・位置などのコンテキストデータをPDPに提供し、このデータはポリシー評価とともに最終的に監査ログに記録されます。

PIPが提供する実行コンテキストの例(JSON形式)

{
    "user": {
        "id": "user_1024",               // 実行リクエスタの固有ID
        "role": "ai_assistant"           // 役割情報: AIベースのエージェント
    },
    "session": {
        "id": "sess-abc-789",            // セッションID (実行単位ID)
        "start_time": "2024-06-01T14:12:30Z", // セッション開始時刻
        "ip": "192.168.10.14"            // 呼び出し発生IPアドレス
    },
    "resource": {
        "id": "doc-456",                 // アクセス対象リソースID
        "type": "gdrive.document",       // リソースのタイプ (Google Driveの文書)
        "tag": "confidential"            // センシティブタグ
    },
    "purpose": "summary",              // 実行目的 (要約リクエスト)
    "trigger": {
        "source": "google_workspace",    // 実行トリガーの発信元
        "method": "voice_command"        // 実行方法 (例: 音声コマンド)
    },
    "context": {
        "location": "KR",                // 実行位置
        "weekday": "Monday",             // 実行曜日
        "time_hour": 14                  // 実行時間帯 (24時間基準)
    }
}

この情報は、ポリシー評価条件を構成するだけでなく、実行セッション単位の監査ログにも一緒に保存する必要があります。

Regoベースのポリシー内PIP活用例および説明

default allow = false

→ すべてのリクエストは基本拒否です。明示された条件を満たす必要があります。

allow {
    input.user.role == "ai_assistant"
}

→ 実行リクエスタの役割がai_assistantの場合にのみレビューを続行します。

allow {
    input.resource.type == "gdrive.document"
}

→ リクエスト対象のリソースはGoogle Driveの文書タイプでなければなりません。

allow {
    input.resource.tag != "confidential"
}

→ センシティブタグ(confidential)が付いている文書はアクセスを拒否します。

allow {
    input.purpose == "summary"
}

→ 実行目的が文書要約(summary)の場合にのみ許可します。

allow {
    input.session.id
    input.trigger.source == "google_workspace"
}

→ セッションIDが存在し、実行トリガーの発信元がGoogle Workspaceでなければなりません。

allow {
    input.context.time_hour >= 9
    input.context.time_hour < 18
}

→ 実行時間は午前9時から午後6時の間でなければなりません (業務時間帯)。

セッションベースの監査ログスキーマの例(JSONテンプレート + 説明)

{
    "session_id": "sess-abc-789",           // 実行単位のセッションID
    "timestamp": "2024-06-01T14:12:32Z",    // 実行が行われた正確な時点
    "user": {
        "id": "user_1024",                    // リクエスタID
        "role": "ai_assistant"               // 役割情報
    },
    "resource": {
        "id": "doc-456",                      // 対象リソースID
        "type": "gdrive.document"             // リソースのタイプ
    },
    "purpose": "summary",                   // 実行目的
    "trigger": {
        "source": "google_workspace",         // トリガーが発生したシステムの発信元
        "method": "voice_command"             // 実行方法
    },
    "policy_evaluation": {
        "policy_id": "gdrive-doc-summary-policy-v2", // ポリシーID
        "result": "deny",                    // 評価結果 (許可/拒否)
        "reason": "resource.tag == confidential" // 拒否理由
    },
    "execution": {
        "status": "blocked",                 // 実行結果
        "executor": "MCP(Model Context Protocol)-agent-pam-01"       // MCP(Model Context Protocol) PAMインスタンスによる実行の制御
    }
}

このようなログ構成は、ポリシー評価条件と実行結果の一致を検証できるようにし、ポリシー回避試み、承認フローの欠落、実行過剰リクエストに対する事後分析を可能にします。AgentSecOpsは、実行フローのセキュリティと監査可能性を保証するために、ポリシー評価段階と実行ロギング段階を一貫して繋げる必要があり、PIPはその繋がりを可能にする情報提供者(Policy Context Broker)として機能します。

5.4 現実的な運用限界と商用化戦略

AgentSecOpsアーキテクチャは、技術的に完全な実行制御モデルを提示します。しかし、ほとんどの組織は、この構造を独自に設計し、運用するのに現実的な制約を持っています。そのため、AgentSecOpsは、設計原則だけでは効果的な制御体制になりにくく、ポリシー実行階層を商用化して実現することが不可欠です。

まず、ポリシー決定ポイント(PDP)は、実行主体とリソース、目的、時点、承認の有無などをリアルタイムで評価する必要があり、これを実現するために、複雑なポリシーテンプレート設計、バージョン管理、ポリシー衝突検証、高可用性処理構造が必要です。

ポリシー実行ポイント(PEP)は、API呼び出しフローの前段階または中間段階で動作する必要があり、数十のSaaSツールやクラウドAPIとの統合が前提となっています。これを各システムに直接挿入することは、認証処理、インターフェース競合、ネットワーク構成変更などの問題を伴います。

ポリシー情報提供ポイント(PIP)は、ユーザーの役割、認証状態、セッション情報、リクエストトリガーなど、さまざまな非定型情報を収集・正規化し、ポリシー評価に提供する必要があり、これは、ログ統合システムや専用ブローカーなしでは実現が困難です。

このような制約の中で、AgentSecOpsは、専用の制御プラットフォームを通じて商用化構造を実現可能な可能性を高めます。代表的な例として、QueryPie MCP(Model Context Protocol) Agent PAMは、実行時点のポリシー評価(PDP)、APIプロキシ実行(PEP)、コンテキスト収集(PIP)機能を統合した構造で、クラウドおよびSaaSベースのエージェント呼び出しフローに対応可能な制御階層を提供します [16]。

MCP(Model Context Protocol)ベースのPAM構造は、従来のIAMやDevSecOpsの認証基盤を補完し、実行行為自体に対するポリシー挿入が可能になるように設計されています。また、実行目的のタグ付け、管理者承認フローの挿入、ポリシー衝突検出、監査ログの公開など、実務に必要な機能を単一プラットフォームで提供します。

結論として、AgentSecOpsは、理論的モデルとしての完全性だけでなく、MCP(Model Context Protocol) PAMと同様の商用プラットフォームのサポートなしでは、企業内での実際の導入と運用が不可能に近い構造です。そのため、セキュリティ設計者は、技術的原則とともに商用実行制御構造との統合戦略を策定することが不可欠です [17]。

6. 結論および推奨事項

本稿は、AIベースのエージェント実行フローが従来のセキュリティ体制に与える構造的影響を分析し、これを制御するための実行主体中心のセキュリティモデルであるAgentSecOpsアーキテクチャを提案しました。特に、AgentOpsとDevSecOpsの限界、実行主体の非人間化、エージェント中心のフローにおけるポリシー評価の必要性を体系的に強調しました。

AgentSecOpsは、単なる自動化保護機構ではなく、実行フローの目的、時点、資源、権限をリアルタイムで評価し、記録することができる実行主体中心のセキュリティ制御レイヤーです。これは、従来のコード中心、リリース前中心のDevSecOpsフレームワークでは対応できない領域であり、ポリシーベースの実行停止、承認フロー挿入、監査追跡という全く異なる制御メカニズムを要求します [18]。

特に、AIエージェントが独立して実行する環境ではなく、Agent-to-Agent実行フローが連続して続く構造では、状況はさらに複雑になります。各AgentOpsごとに別のポリシー評価(PDP)、実行制御(PEP)、情報参照(PIP)が必要になり、この過程で発生するすべての実行評価結果は、中央実行分析システムで統合的に集計する必要があります。

次は、この構造を視覚的に示したダイアグラムです。



[図9] 分散型エージェント実行と集中型ポリシー分析

このような構造は、各AgentOpsごとに個別に適用可能ですが、運用上は非常に複雑であり、構築および維持に費用が指数関数的に増加します。企業内で数十のエージェントフローを監視し、各フローに対してPDPポリシーを設計し、結果を統合的に分析する構造を直接運用するのは、実現不可能に近いです。

そのため、AgentSecOpsは、実務上はMCP(Model Context Protocol)ベースの実行セキュリティソリューション(MCP(Model Context Protocol) Agent PAM)の形式で実現する必要があり、これは、単なる機能ではなく、運用戦略的に必要なインフラです。QueryPie MCP(Model Context Protocol) Agent PAMは、実行フローにポリシー評価を挿入し、個別の実行を拒否または承認フローに連動させ、結果を統合的に分析できる構造を提供します[19]。

次のような環境では、MCP(Model Context Protocol)ベースのAgentSecOps導入が特に必要とされます：

LLMベースのエージェントがSlack、GitHub、Notion、AWS、GCP、HRシステムなど外部SaaSと連携する環境
GitOps、IaCベースの配備フローにAIエージェントが直接テンプレートを生成する自動化構造
実行フローに対する監査・承認の有無が規制対象となる産業分野 (金融、医療、公共)
エージェントが複数段階で呼び出しを行うマルチワークフロー組織構造

AgentSecOpsは、実行フローそのものに対するポリシー制御構造を提示し、これは、後のAIベースの運用体制におけるセキュリティ制御の転換点となるでしょう。組織は、このモデルを単なる技術的なトレンドとして受け入れるのではなく、セキュリティ運用モデルの構造的な革新として認識する必要があり、これを実現するために、実行ポリシー設計の文化と統合プラットフォーム導入戦略を同時に策定する必要があります。

References

I. Belcic, “What is AutoGPT?,” IBM, 2023. [Online]. Available: https://www.ibm.com/think/topics/autogpt
GitHub Docs, "Webhooks," GitHub Developer Guide, 2023. [Online]. Available: https://docs.github.com/en/webhooks
I. Belcic, “What is AutoGPT?,” IBM, 2023. [Online]. Available:
https://www.ibm.com/think/topics/autogpt
GitHub Docs, “Webhooks,” GitHub Developer Guide, 2023. [Online]. Available:
https://docs.github.com/en/webhooks
Anthropic, “Responsible AI Agents and Oversight,” Anthropic Research, 2024. [Online]. Available:
https://www.anthropic.com/research/building-effective-agents
Google Cloud, “Introducing the DevSecOps Toolkit,” Google Cloud Blog, 2023. [Online]. Available:
https://cloud.google.com/blog/products/networking/introducing-the-devsecops-toolkit?hl=en
HashiCorp Docs, “Govern: Enforce policy controls before provisioning,” Terraform by HashiCorp, 2024. [Online]. Available:
https://developer.hashicorp.com/terraform/intro/phases/govern
Amazon Web Services, “Cedar – An Open Source Language for Access Control,” AWS News Blog, May 2023. [Online]. Available:
https://aws.amazon.com/about-aws/whats-new/2023/05/cedar-open-source-language-access-control/?nc1=h_ls
T. Priebe et al., “Supporting Attribute-based Access Control in Authorization and Authentication Infrastructures with SAML,” in Proc. IFIP TC11 WG11.5, 2004.
T. Moses, “XACML 3.0 Core Specification,” OASIS Standard, 2017. [Online]. Available:
http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
Open Policy Agent, “Rego Language Guide,” OPA Official Documentation, 2023. [Online]. Available:
https://www.openpolicyagent.org/docs/latest/policy-language/
S. Rizvi and A. Ghafoor, “A Purpose-Based Access Control Model for Privacy Protection,” Computer Networks, vol. 43, no. 1, pp. 593–611, 2005.
Kyverno Project, “Policy Engine for Kubernetes,” Kyverno Documentation, 2023. [Online]. Available:
https://kyverno.io/docs/
OWASP, “Top 10 for LLM Applications,” OWASP Foundation, 2023. [Online]. Available:
https://owasp.org/www-project-top-10-for-large-language-model-applications/
GitLab Docs, “CI/CD Security Patterns,” GitLab Documentation, 2023. [Online]. Available:
https://docs.gitlab.com/ee/topics/autodevops/
Microsoft, “AI Trust and Risk Framework,” Microsoft Responsible AI Practices, 2024. [Online]. Available:
https://www.microsoft.com/en-us/ai/responsible-ai
AWS, “Using IAM Policies to Control Access,” AWS Identity and Access Management User Guide, 2023. [Online]. Available:
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
QueryPie, “Uncovering MCP Security,” QueryPie White Paper, 2025. [Online]. Available:
https://www.querypie.com/resources/discover/white-paper/18/uncovering-mcp-security
QueryPie, “Redefining PAM for the MCP Era,” QueryPie White Paper, 2025. [Online]. Available:
https://www.querypie.com/resources/discover/white-paper/15/redefining-pam-for-the-mcp-era
D. Kozen and J. Millen, “Policy Composition in Access Control,” IEEE Security & Privacy, vol. 14, no. 3, pp. 36–43, 2016.
QueryPie, “Next-Step MCP PAM Architecture,” QueryPie Resource Center, 2025. [Online]. Available:
https://www.querypie.com/resources/discover/white-paper/16/next-step-mcp-pam

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up