OWASP Agent Control Standard（ACS）とは？AIエージェントを安全に制御する新標準を解説

はじめに

メールを要約するAIエージェントが、本文に埋め込まれた指示をユーザーの依頼だと誤認し、外部サービスへ情報を送ろうとしたとします。 システムプロンプトに「機密情報を送信しない」と記述していても、送信処理の直前でブロックする仕組みがなければ、その指示に技術的な強制力はありません。 AIエージェントが会話の回答だけでなく、ツールを使って現実のシステムを変更するようになると、制御は実行時に働く必要があります。

NISTは2026年1月に公開したAIエージェントのセキュリティに関する情報提供依頼（RFI）において、間接プロンプトインジェクション、データ汚染などの影響を受けた安全でないモデル、敵対的入力がなくても有害な行動を取る可能性を、AIエージェント特有のリスクとして挙げました。 同資料は、エージェントが利用できる範囲を制約し、監視するための導入環境側からの介入も検討対象にしています。

2026年9月1日にOWASP GenAI Security Projectが公開したAgent Control Standard（ACS）は、この実行時制御をエージェント基盤に組み込むためのオープンな仕様です。 現行の仕様はv0.1.0であり、完成済みの認証制度ではありません。 それでも、異なるエージェント基盤へ共通の制御点、監査記録、構成情報を持たせる設計は、個別製品のガードレールだけでは埋めにくかった領域を具体化しています。

ACSはAIエージェントの実行時制御を標準化する

OWASPのACS公開ページは、ACSを、エージェント基盤がミドルウェアのフックを公開する方法と、そのフックを通じて安全ポリシーを適用する方法を定めるオープンな基盤と説明しています。 フックとは、ユーザーメッセージの受信、外部ツールの呼び出し、メモリへの保存など、エージェントの処理へ介入できる決定点です。

ACSでは、制御対象のエージェントを「Observed Agent」、判定を担う別の主体を「Guardian Agent」と呼びます。 Observed Agentはアクションの前に情報をGuardian Agentへ送り、Guardian Agentはポリシーに基づいて判定を返します。 標準化されるのはAIモデルの判断内容そのものではなく、行動の前後で検査と制御を行うための通信形式、イベント、構成情報です。

「Guardian Agent」という名称から、別のLLMがすべてを判断する仕組みだと誤解されがちですが、それは正しくありません。 ACSのコア概念では、OPA/RegoやCedarなどを使う決定論的なポリシー層を先に実行し、LLMを使う層はポリシーが委任した場合だけ呼び出す構成を示しています。 LLMを使わず、決定論的なルールだけで構成してもACSへ適合できます。

Instrument、Trace、Inspectが制御の3本柱になる

ACSは、信頼できるAIエージェントに必要な性質をInstrument、Trace、Inspectの3本柱で整理しています。 3つは代替関係ではなく、事故を防ぐ制御、発生後に追跡する記録、制御対象を知るインベントリとして役割が分かれています。

Instrumentは行動の直前でポリシーを適用する

Instrumentは、セッション開始、ユーザー入力、知識検索、メモリ操作、ツール呼び出し、サブエージェントの開始などにフックを設けます。 たとえば、AIエージェントが顧客データベースを検索しようとした時点で、ツール名、引数、セッション情報、エージェントの意図をGuardian Agentへ送り、検索を実行してよいか判定できます。

Guardian Agentが返す判定は、許可する「allow」、拒否する「deny」、内容を変更する「modify」、承認者へ確認する「ask」、別の判定系へ委ねる「defer」の5種類です。 「modify」を使えば、データベース検索を全面的に拒否せず、取得列を減らす、件数を制限する、機密値をマスキングするといった条件付きの実行も表現できます。

Traceは実行と判定を同じ流れで記録する

AIエージェントのログは、最終的な回答だけ残しても調査に足りません。 どのユーザーやイベントが処理を始め、どのエージェントがどのツールを呼び、Guardian Agentが何を根拠に許可または拒否したかを結び付ける必要があります。

ACS-Traceは、フックのイベントをOpenTelemetryのスパンとして記録し、セキュリティイベントをOCSFへ対応付けます。 既存のオブザーバビリティ基盤やSIEMへ連携しやすい形式を使うため、エージェント製品ごとに監査ログの解釈と変換を作り直す負担を減らせます。

Inspectは変化するエージェント構成を棚卸しする

従来のSBOMは、出荷時点のソフトウェア部品を把握する用途に適しています。 一方、AIエージェントは実行中にMCPサーバ、別のエージェント、ツール、知識源、メモリストアを見つけ、利用可能な能力を変える場合があります。 起動時の構成表だけでは、現在どのデータと処理へ到達できるのかを見失います。

ACS-Inspectは、こうした構成をAgent Bill of Materials（AgBOM）として公開し、変更も通知します。 AgBOMはモデル、MCPサーバ、A2Aで接続するエージェント、ツール、知識源、メモリストアなどを対象とし、CycloneDX、SPDX、SWIDへ変換できる設計です。

Observed AgentとGuardian Agentが判定を分離する

冒頭で挙げたメール送信の例をACSに当てはめると、Observed Agentは送信ツールを呼び出す直前に「toolCallRequest」を送ります。 Guardian Agentは宛先、本文、添付情報、ユーザーの権限、セッションの意図をポリシーで評価し、許可、拒否、修正、承認要求、委任のいずれかを返します。 Observed Agentはその判定に従った後、実行結果もフックへ送り返します。

この分離により、エージェント自身のプロンプトが攻撃者に影響された場合でも、同じプロンプトの判断だけに安全性を依存せずに済みます。 ただし、Guardian AgentがObserved Agentと同じ資格情報を使い、同じ実行環境で改変できるなら、分離の効果は弱まります。 制御経路の認証、ポリシー変更権限、監査ログの保護まで含めて設計する必要があります。

ACS v0.1.0は必須のCoreと任意プロファイルで構成される

ACS v0.1.0の適合プロファイルでは、すべての適合実装がACS-Coreを備え、必要に応じて追加プロファイルを宣言します。 「ACS対応」という表示だけでは、追跡、AgBOM、暗号署名まで備えているか分かりません。 製品や基盤を評価するときは、対応するプロファイルとフックを確認します。

ACS-Coreは通信を認証し、Observed Agentの動作をGuardian Agentの判定に紐付けますが、ポリシー自体の妥当性や導入環境全体の安全性までを保証するものではありません。 厳格でないポリシーを正確に実行しても、危険な操作は許可されます。 Guardian Agent自体が侵害された場合の改ざん検知には、CryptoやAuditを含む追加プロファイルと、外部のログ保護が必要です。

NISTのAIエージェント施策とACSは別の取り組みである

ACSはOWASP GenAI Security Projectのオープン仕様であり、NISTが策定した標準ではありません。 一方、NISTは2026年2月にAI Agent Standards Initiativeを開始し、業界主導の標準化、コミュニティ主導のオープンプロトコル、AIエージェントのセキュリティとアイデンティティに関する研究を3本柱に掲げています。 ACSは、このうち業界主導の標準とオープンプロトコルが必要とされる背景に沿う取り組みですが、NISTによる承認や認証を意味しません。

NISTのAIエージェントのアイデンティティと認可に関するコンセプトペーパーは、識別、認証、認可、権限委譲、監査、否認防止、プロンプトインジェクション対策を検討課題に挙げています。 とりわけ、最小権限をどう定めるか、エージェントが行動の意図と権限をどう証明するか、ユーザーとエージェントをどう結び付けるかという問いは、ACSのIdentity、Intent、Traceが扱う情報と重なります。

ただし、NISTの文書は2026年2月時点のドラフト版コンセプトペーパーであり、ACSへの適合方法を定めたものではありません。 組織はNIST資料をリスクと要求事項の整理に使い、ACSを実行時制御の実装候補として個別に評価する必要があります。

ACSを採用する前に確認したい制約

ACS v0.1.0は公開直後の仕様であり、対応するエージェント基盤、SDK、検証ツールは今後変化する可能性があります。 仕様ページのサンプルと製品の実装状況を同一視せず、利用予定のフック、プロファイル、通信経路、障害時の挙動を実機で確認します。

監査ログには、ユーザー入力、ツール引数、検索結果、ポリシーの判定理由など、機密情報が集まります。 Traceを増やすほど安全になるわけではありません。 収集する項目、マスキング、保存期間、閲覧権限、越境移転の有無を決め、調査に必要な証拠とデータ最小化を両立させます。

ACSはポリシーを運ぶ共通の仕組みであり、業務上どの操作を許可するかまでは決めません。 誤った権限設計、脆弱なツール、侵害されたGuardian Agent、承認者による誤判断は別途対策が必要です。 ACSへの適合を絶対的なセキュリティ保証として扱うのではなく、脅威分析、最小権限の原則、分離、監視、インシデント対応といった従来の対策と組み合わせることが重要です。

まとめ

OWASP Agent Control Standard（ACS）は、AIエージェントの決定点へ共通のフックを設け、別のGuardian Agentが実行時に許可、拒否、変更、承認要求、委任を返すための、オープンな技術仕様です。 Instrumentが行動へ介入し、Traceが実行と判定を記録し、Inspectがモデルやツールなどの動的な構成をAgBOMとして把握します。

NISTはAIエージェントの安全な普及に向け、業界主導の標準、オープンプロトコル、セキュリティとアイデンティティの研究を進めています。 ACSはその問題意識と重なる実装標準ですが、NISTのガイドラインでも、NISTが認証した仕組みでもありません。 NISTの資料でリスクと管理要件を整理し、ACS v0.1.0の各プロファイルが自社の実行環境でどこまで機能するかを検証する使い分けが必要です。

冒頭のメール送信を止めるのは、「機密情報を送らないでほしい」という期待ではありません。 送信直前のフック、認証された判定経路、明示的な拒否ポリシー、追跡可能な記録がそろって初めて、期待は実行時の制御になります。

AIエージェントのセキュリティ設計にお困りの場合

AIエージェントが利用するデータ、ツール、権限を整理し、実行時制御と監視を設計することが難しい場合は、弊社のセキュリティチーム代行サービスをご検討ください。 脅威分析、アクセス制御、ログ設計、運用手順の整備まで、外部のセキュリティチームとして継続的に支援します。