ArcjetのAgent Runtime Security、AIアクションループに制御を導入

Arcjetは9月17日、AIエージェントが本番環境に入った後のためのリアルタイム制御機能を追加したagent runtime securityを公開した。この製品は、エージェントを監視することと、その次のアクションを止めることの間にある隔たりを対象とする。この違いは、エージェントがメッセージ送信、データベース更新、返金処理、社内ツール呼び出しを行える場合に重要となる。

Arcjetのagent runtime securityリリースは、セキュリティベンダー各社がこの新たな実行レイヤーの制御を競う中で登場した。ゲートウェイはトラフィックを検査し、アイデンティティシステムはアクターを認証し、オブザーバビリティプラットフォームは活動を記録する。一方Arcjetは、エージェントが提案したアクションをまだブロックできる、アプリケーションパス内にポリシーチェックを置こうとしている。

このアーキテクチャにより、開発者は各判断に対してより多くのコンテキストを得られる。その一方で、重大なアクションの周囲に強制実行コードを配置する必要がある。Arcjetの中心的な賭けは、外部制御では十分なアプリケーション詳細を把握できないため、組織がこの統合作業を受け入れるという点にある。

製品は、エージェントの検出、アクションレベルの強制実行、監査記録を組み合わせる。Arcjetによれば、チームは既存のテレメトリーを通じてエージェントを観測し、その後、ソフトウェア開発キットとフレームワーク統合を通じて予防的なチェックを追加できる。

したがって今回の発表は、モデルをより安全にするという一般的な約束をまた一つ示すものではない。モデル出力が実際の操作になる時点で、責任がどこから始まるのかを定義しようとする試みだ。

Arcjet Agent Runtime Securityが追加する3層の制御

Arcjetは、可視性、予防、証跡を単一の本番ワークフローに統合している。

第1層は観測だ。Arcjetによれば、組織はトレース、メトリクス、ログを収集するオープン標準であるOpenTelemetryを通じて、エージェントの活動を送信できる。Claudeを利用するチームは、AnthropicのCompliance API経由でも接続できる。

この取り込みプロセスにより、エージェントとアプリケーションのインベントリが構築される。次にArcjetは、個々のセッションを、それを生成したエージェントと関連付ける。セキュリティ調査担当者は、分断されたプロンプトやツール呼び出しを検索する代わりに、より長いワークフローをレビューできる。

このアプローチは、標準化されたテレメトリーの利用拡大に一部依存している。OpenTelemetryプロジェクトは、エージェントのタスク、フレームワーク活動、モデルのインタラクションを報告するためのagent observability規約を開発している。

こうした標準化により、異なるフレームワークにまたがってエージェントを検出するための作業を減らせる可能性がある。ただし、観測だけでは安全でない操作を防げない。発生した事象を記録し、その後の分析に向けたコンテキストを提供するにとどまる。

第2層は強制実行だ。Arcjetは、エージェントがツール、データベース、アプリケーションプログラミングインターフェース、またはモデルを呼び出す前に、ポリシー判断を置く。アプリケーションは、許可、ブロック、伏字化、レビュー保留といった型付けされた応答を受け取る。

型付けされた応答とは、アプリケーションコードが一貫して処理できる構造化された結果のことだ。これによりワークフローは、アクションを停止し、人間の承認を求め、またはエージェントに説明を返せる。

Arcjetは呼び出し後のチェックにも対応する。こうしたチェックは、別のワークフローステップが結果を利用する前に、その結果を検査できる。これにより、提案されたアクションと、そこから返される情報の両方を制御できる。

同社によると、利用可能なポリシーは、prompt injection、機密データの露出、自動化の悪用、レート制限、リソースクォータを対象とする。prompt injectionは、信頼できないコンテンツがモデルを操作し、敵対的または意図しない指示に従わせる際に発生する。

第3層は監査だ。Arcjetは、判断、ポリシーバージョン、アクター、入力、および関連する実行コンテキストを記録する。この記録は、エージェントが何を試み、なぜシステムがそれを許可または拒否したのかを示すことを目的としている。

同社が訂正した発表資料は、製品を観測、強制実行、監査という3つの機能で説明している。発表では、モデル、ツール、データベース、APIに関わる呼び出しの前後でポリシーを実行できるとしている。

この設計は、特定の運用上の問題に対処するものだ。サポートエージェントは、メールを読み、顧客データベースを照会し、返信を作成する場合がある。各ステップを単独で検査すれば、無害に見える可能性がある。

それでも、組み合わされた一連の操作によって、攻撃者が追加したアドレスに個人情報が露出するおそれがある。Arcjetは、先行するステップを保持し、その履歴の中で送信メッセージを評価しようとしている。

創業者兼CEOのDavid Mytton氏はSiliconANGLEに対し、危険な結果は、個別には合理的に見える複数のアクションにまたがって生じうると語った。元のローンチ報道でも、複数の主要エージェントフレームワークとの統合が報じられている。

これらの統合には、Claude Agent SDK、OpenAI Agents SDK、LangChain、Mastra、MicrosoftのAgent Frameworkが含まれる。Arcjetのより広範な製品ページでは、20のSDKおよびフレームワーク統合をサポートするとしている。

この幅広さは重要だ。エージェントの導入では、単一の共通ランタイムが使われることはほとんどない。組織は、異なるインターフェースを通じて動作するWebエージェント、キューワーカー、コーディングアシスタント、スケジュールされたワークフローを抱える場合がある。

Arcjetの製品は、共有された判断モデルを通じてこうした環境を結び付けようとしている。最も重要な変化はインベントリ画面ではない。アクションが実行される前に、必須の判断を置けることだ。

セキュリティ境界はアクセスからアクションへ移行している

認証済みのエージェントでも、有効な認証情報で誤ったアクションを実行しうる。

従来のアクセス制御は、アイデンティティがシステムに入れるかを問う。これは依然として必要だが、ソフトウェアが目標を解釈し、自律的にアクションを選択できるようになると、それだけでは不十分になる。

従業員は、エージェントに顧客サービスプラットフォームの利用を許可するかもしれない。しかし、その許可は、エージェントが遭遇するすべての取引を返金すべきことを自動的に意味しない。許可される金額、アカウント、支払い方法、周囲のリクエストは、依然として重要だ。

同じ問題はコーディングワークフローにも現れる。コーディングエージェントは正当なリポジトリアクセスを持っていても、シークレットを公開したり、デプロイ設定を変更したり、破壊的なコマンドを実行したりする権限を持たない場合がある。

常設のアクセス権は外側の境界を定める。しかし、その境界内のすべてのアクションが、ユーザーの現在の意図を反映することを保証するものではない。

Googleは2026年のBeyond Zero frameworkで、同様の転換を説明した。この提案は、広範なアプリケーションアクセスを付与するのではなく、特定のリソースに対する個々のアクションのレベルで認可を評価する。

Arcjetは、この方向性をより限定的で導入可能な形で追求している。アプリケーション内部で利用できるコンテキストを使い、アクションをチェックする。このコンテキストには、アイデンティティ、ルート、ツール名、型付けされた引数、先行ステップ、累積利用量が含まれうる。

エンタープライズリソースプランニングシステムにアクセスできる買掛金エージェントを考えてみよう。請求書を読むことと支払いを実行することは、どちらも同じアプリケーション内で起こる。しかし、その結果は大きく異なる。

ネットワークゲートウェイは、そのアプリケーションに向かうトラフィックを認識できるかもしれない。一方で、基盤となる機能が仕入先レコードを読むのか、銀行口座情報を変更するのかは理解できない可能性がある。

コード内のチェックであれば、関数とその引数を検査できる。請求書の読み取りにはあるポリシーを適用し、資金の送金には別のポリシーを適用できる。

この違いは、外部コントロールプレーンに対するArcjetの位置付けを説明している。ゲートウェイは、モデルルーティング、認証、ロギング、コンテンツチェックを集中管理できる。Arcjetは、アクションを実行するコードの外部へ強制実行を移すと、アプリケーションコンテキストの一部が失われると主張する。

両アプローチは相互排他的ではない。企業はモデルトラフィックにゲートウェイを使い、特定のツール呼び出しにはArcjetを使える。重要なのは、最終判断をどの制御が担うかだ。

Arcjetによれば、ローカルでの判断によるオーバーヘッドは1ミリ秒未満だという。判断にクラウドサービスが必要な場合は、20〜30ミリ秒と報告している。

これらの数値は同社の主張であり、独立したベンチマーク結果ではない。また、より重いチェックは含まれていない。Arcjetによると、専門的なprompt injection検出では、プロバイダー呼び出しの前に約100ミリ秒が追加される可能性がある。

1回のエージェント実行に数十のアクションが含まれる場合、レイテンシーは重要になる。特にリモートポリシー評価やモデルベースの検出が繰り返し行われると、小さな遅延でも積み重なる可能性がある。

したがって、このアーキテクチャはポリシー配置の問題を生む。チームは、どのアクションにローカルルール、リモートチェック、コンテンツ分析、または人間によるレビューが必要かを判断しなければならない。

読み取り専用の照会であれば、認可とロギングだけで済むかもしれない。高額な返金では、複数の制御と手動承認が正当化される可能性がある。すべてのアクションに最も厳格なプロセスを適用すれば、ワークフローは遅くなり、運用上の摩擦が増す。

Arcjetの回答は、きめ細かな強制実行だ。エンジニアリングチームは保護対象のハンドラーの近くにルールを維持でき、セキュリティチームは別のアプリケーションデプロイを求めることなく、リモートポリシーを管理できる。

コードベースのルールは、テスト、レビュー、バージョン管理を支援する。リモートルールにより、セキュリティ担当者はサービス全体の閾値を調整できる。両者を組み合わせることで、セキュリティチームによる迅速な介入を可能にしつつ、エンジニアリングのオーナーシップを維持できる。

同時に、ガバナンス上の問題も生じうる。アプリケーションには1つのポリシーが含まれる一方、リモートサービスが別のポリシーを適用する場合がある。チームには、明確な優先順位、変更履歴、障害時の動作が必要になる。

クラウドポリシーサービスが利用できなくなった場合、アプリケーションはブロックするか継続するかを決めなければならない。その判断は、アクションの影響と組織が許容できる中断の程度に依存する。

この製品はアクション境界を可視化するが、こうした設計上の選択をなくすものではない。チームがそれらをコード化する場所を提供する。

コード内の強制実行がゲートウェイとセキュリティダッシュボードに挑む

主な競争は、アクションを中断できる制御と、その周囲のトラフィックを主に観測するシステムとの間にある。

セキュリティダッシュボードは、テレメトリーが届いた後に異常な振る舞いを特定できる。これは調査、インシデント対応、コンプライアンスに引き続き有用だ。ただし、すでに完了した返金やデータベース更新を必ずしも止められるわけではない。

AIゲートウェイは、モデルリクエストまたは応答が通過する前に介入できる。敵対的なコンテンツを検出し、プロバイダーを制限し、集中管理された地点で支出上限を適用できる。

ただし、エージェントの重大な操作は、モデルとのやり取りの後に起こる可能性がある。モデルはツール呼び出しを提案し、アプリケーションコードが別のシステムに対してそれを実行する。モデルのトラフィックしか見ないゲートウェイでは、最終的な操作を見逃す可能性がある。

Arcjetは、その実行パス内にガードを置く。アプリケーションは、関連する関数を呼び出す直前にポリシー判断を要求する。これにより、ポリシーは自然言語から意図を推測するのではなく、型付けされた引数を検査できる。

少額の返金と大幅に高額な返金は、ネットワークレイヤーでは似て見える場合がある。アプリケーションハンドラーは、正確な金額、アカウント、通貨、ユーザーコンテキストを把握している。

トレードオフは導入範囲だ。集中型ゲートウェイは、トラフィックを経由させれば、多くのアプリケーションをカバーできる。コード内の制御は、開発者が特定した境界に挿入する必要がある。

Arcjetは、SDK、フック、フレームワーク統合を通じて、この負担を減らそうとしている。同社によれば、アプリケーションの変更を必要とせず、OpenTelemetryを通じた観測にも対応している。

それでも、検知と強制は別のものです。テレメトリーによって未知のエージェントを明らかにできても、そのエージェントが実行するすべての操作の前に自動的にブロック制御が置かれるわけではありません。

この違いが、導入の順序を生み出します。プラットフォームチームはまずエージェント活動の棚卸しを行えます。その後、開発者は重大な影響を伴う操作を選び、それらの周囲にガードを追加します。

この順序は実践的ですが、カバレッジにはばらつきが残る可能性があります。あるサービスは返金を保護していても、別のサービスではアカウント変更が無防備なままかもしれません。セキュリティチームには、どの操作に強制が欠けているかを示す証拠が必要です。

大手ベンダーは重なり合う領域を追求しています。Ciscoは2026年2月、エージェントのツール利用に対するランタイム保護とインタラクションガバナンスを備えてAI Defenseを拡張しました。同社のAI Defense expansionでは、ネットワーク、クラウド、オンプレミス環境にまたがる保護を強調しています。

Ciscoのアプローチは、確立されたエンタープライズセキュリティ基盤の恩恵を受けます。Arcjetの訴求は、アプリケーションネイティブな統合と開発者による導入にあります。

他の製品は、モデルファイアウォール、AIレッドチーミング、アイデンティティ、ゲートウェイルーティング、あるいは可観測性に焦点を当てています。ベンダーがプロンプトからツール実行までエージェントの活動を追跡するにつれ、これらのカテゴリーはますます重なり合っています。

したがってArcjetは、操作レベルのコンテキストが単にログを増やすだけでなく、より良い判断を生むことを示さなければなりません。購入者は、正当な業務を妨げずに意味のある攻撃をポリシーが阻止できるという証拠を求めるでしょう。

同社が現在示している例は直感的です。返金上限、未承認のツール呼び出し、機微データのマスキング、暴走ループ、危険な操作シーケンスなどが含まれます。

より難しいのは、意図が曖昧なケースです。ポリシーは、あるロールで利用できないツールを拒否することは容易です。しかし、許可されたツール呼び出しが、十分に具体化されていないユーザーの目的に合致するかを判断するのは難しくなります。

決定論的ポリシーは、組織が明確なルールを表現できる場合に役立ちます。決定論的ポリシーは、自由度の高いモデルの判断に依存せず、既知の同一入力に対して同一の結果を返します。

ルールは支出に上限を設け、リソースを制限し、承認を要求し、特定のデータカテゴリーをブロックできます。コンテキストが微妙なビジネス上の意味に依存する場合、その判断力は低下します。

この制約は、ランタイム強制が不要であることを意味しません。決定論的制御の終点と、推論ベースのガバナンスの始点を定義するものです。

Arcjetの製品は現在、信頼できる強制の基盤を重視しています。より高度なシーケンス分析はその基盤の上に構築できますが、その結果として得られる操作を停止できる仕組みは依然として必要です。

ここが同社の主張で最も強い部分です。アプリケーションが実行前に判断を強制できなければ、検知を改善しても保護は限定的です。

弱い部分は運用上の実証です。Arcjetは、このリリースに関する誤検知率、顧客導入、インシデント削減を示す幅広い第三者データを公表していません。

そうした結果が現れるまでは、購入者はパフォーマンスと有効性の数値をベンダーの主張として扱う必要があります。パイロット導入では、ブロック動作を有効化する前にポリシーを観測モードで実行すべきです。

プロンプトインジェクションはランタイム上の問題の一部にすぎない

プロンプトフィルターは、認可、最小権限、予算、承認制御の代替にはなりません。

攻撃者はメール、文書、ウェブサイト、ツール出力の中に指示を隠せるため、プロンプトインジェクションは注目を集めています。エージェントは、その信頼できないコンテンツを指針として扱い、振る舞いを変える可能性があります。

フィルタリングは、コンテンツがモデルに届く前に一部の敵対的パターンを識別できます。しかし、結果として生じるすべてのビジネス操作が認可されているかどうかを、確実に判定することはできません。

形式的に正しいリクエストであっても、ユーザーの権限を超えることがあります。侵害されたアカウントが、無害に見える指示を送ることもあります。攻撃に遭遇しなくても、エージェントが誤りを犯す場合もあります。

したがって、ランタイムセキュリティではコンテンツ評価と操作認可を分ける必要があります。一方の検査は入力が敵対的に見えるかを問います。もう一方は、この主体がこのリソースに対してこの操作を実行できるかを問います。

excessive agencyに関するOWASPのガイダンスは、拡張機能、権限、自律性を最小化することを推奨しています。また、影響の大きい操作の前に人間による承認を行うことも推奨しています。

Arcjetは、これらの制御の一部に対する強制ポイントを提供できます。ただし、組織のリスク許容度を決定したり、過度に広い認証情報を持つエージェントを再設計したりすることはできません。

不要なデータベース権限を持つエージェントは、依然として危険です。ブロックポリシーは露出を減らしますが、最小権限によって、そもそもエージェントが多くの機微な操作に到達できないようにすべきです。

人間による承認にも慎重な実装が必要です。確認画面には、実際のツール、宛先、引数、結果を表示すべきです。エージェントが作成した要約の承認をユーザーに求めると、危険な詳細を隠してしまう可能性があります。

Arcjetの製品資料によると、同社はレビュー待ちの判断を返します。とはいえ、そのレビューをどのように表示し、誰が承認できるかは、周辺アプリケーションが引き続き制御します。

監査記録は別の懸念も生みます。プロンプトやツールパラメーターには、個人情報、認証情報、社内文書、顧客データが含まれる可能性があります。

Arcjetによると、機微な検査はローカルで実行でき、判断の証跡は別途保存されます。保存先として、同社クラウド、シングルテナント環境、プライベート仮想クラウド、顧客管理インフラを提供しています。

組織は、どのフィールドが自社環境の外へ出るかを確認すべきです。また、保持期間、地域ごとの保存、アクセス制御、削除手順、インシデント対応の責任範囲も定義する必要があります。

この製品は、セキュリティ、可用性、機密性を対象とするSOC 2 Type IIレポートを掲げています。その保証は組織的な統制を対象にしますが、すべてのエージェントポリシーや統合を検証するものではありません。

シーケンスベースの検知は、さらなる不確実性をもたらします。セッションをまたいで操作を関連付けることで、単発の検査では見逃す段階的なリスクを明らかにできます。一方で、識別子が一貫していない場合、不完全または誤った履歴を生むこともあります。

OpenTelemetryの規約は、記録の正規化に役立ちます。しかし、すべてのフレームワークが同等のコンテキストを出力したり、同じアイデンティティ情報を保持したりすることを保証するものではありません。

開発者は、キュー、バックグラウンドジョブ、サービス境界をまたいで相関識別子を伝播させる必要があります。コンテキストが欠けると、単一のワークフローが複数の無関係な実行に見える可能性があります。

過剰な収集は逆の問題を生みます。すべてのプロンプト、ツール引数、出力を記録すると、監視プラットフォームが利用できる機微データが増大します。

セキュリティチームは、調査に必要な詳細とデータ最小化のバランスを取らなければなりません。有用な監査証跡は、すべての機微なペイロードを自動的に複製せずに判断を証明できるべきです。

誤検知も別の課題です。プロンプトインジェクション検出器は、正当なセキュリティ議論、引用されたマルウェアの指示、顧客コンテンツにフラグを立てる可能性があります。

Arcjetは、強制せずに判断を記録するドライラン導入を推奨しています。これにより、チームはルールを有効化する前に、提案されたブロックを実際のアプリケーション動作と比較できます。

ドライランは価値がありますが、構造化されたレビューが必要です。チームは誤検知にラベルを付け、見逃しケースを測定し、ダッシュボードを受動的に眺めるのではなく障害経路をテストすべきです。

ポリシーは陳腐化することもあります。新しいツール、引数、データクラス、ビジネスプロセスは、操作の意味を変えます。バージョン管理されたポリシー記録は、ある時点でどのルールが適用されたかを調査担当者が理解する助けになります。

ただし、それによってルールが適切なままであったことは保証されません。セキュリティとアプリケーションの所有者は、ワークフローの変化に応じてポリシーを見直す必要があります。

これらの制約は、主要なトレードオフを改めて示しています。強制をコードへ移すことは有用なコンテキストを提供しますが、責任もサービスとチームに分散させます。

Arcjetは、この分散モデルがカスタム認可チェックの寄せ集めよりも統治しやすいことを示す必要があります。そうでなければ、購入者は一貫した制御を実現しないまま、別のポリシーレイヤーを得ることになります。

次の試金石は機能の幅ではなく、本番環境での証拠

顧客が実際のエージェントワークフロー全体でカバレッジ、低い中断率、介入の成功を証明できるなら、Arcjetのローンチは重要なものになります。

最初に注目すべき指標は、デモ環境を超えた導入です。Arcjetは、チームがどのようにエージェントを棚卸しし、重大な操作を特定し、選択したポリシーをドライランから強制へ移すのかを示すべきです。

実名の本番導入事例があれば、購入者がどのワークフローを優先するかが明確になります。サポート業務、ソフトウェア開発、財務、社内データアクセスでは、リスクとレイテンシーの要件が異なります。

最も強力な証拠には、導入時間、保護された操作のカバレッジ、誤検知率、実行前に停止された操作数が含まれます。こうした指標はArcjetの中心的な主張を検証するでしょう。

2つ目の指標は相互運用性です。Arcjetは現在、主要なエージェントフレームワークやコーディングアシスタントにまたがる統合を掲げています。市場は、これらの統合が混在環境全体で有用なコンテキストを保持できるかを判断するでしょう。

組織がすべてのエージェントを単一フレームワークに標準化することはめったにありません。ワークフローはチャットインターフェースで始まり、キューを経由して、カスタムサービス内で完了することがあります。

Arcjetは、すべてのチームに単一のオーケストレーションシステムを強いることなく、これらのステップを接続しなければなりません。OpenTelemetry対応はもっともらしい検知レイヤーを提供し、SDKガードは強制を提供します。

これらのレイヤー間の隔たりには注意が必要です。購入者には、検知されたエージェントのうち、重大な操作が保護されていないものを明確に把握する手段が必要です。

カバレッジレポーティングは、この製品の最も価値ある機能の一つになり得ます。これによりセキュリティチームは、可視性と実際の予防的制御を区別できるようになります。

3つ目の指標は競合の反応です。Ciscoをはじめとするエンタープライズベンダーはすでに、エージェントのインタラクションガバナンスとランタイム保護を追加しています。

これらの企業がアプリケーションハンドラーのより深い部分へ進出すれば、Arcjetのアーキテクチャ上の差別化は狭まります。集中型の検査に焦点を置き続けるなら、Arcjetはコードレベルのコンテキストが永続的なギャップを埋めると主張できます。

エージェントフレームワークの提供者も、ネイティブのポリシーフックを追加する可能性があります。この動きは、共通の強制ポイントを作ることでArcjetを後押しすることもあれば、独立したプラットフォームへの需要を減らすこともあります。

市場は、レイヤー化された制御を支持する可能性が高いでしょう。アイデンティティ、ゲートウェイ検査、操作認可、テレメトリー、人間によるレビューは、それぞれ異なる障害モードに対応します。

購入者の課題は、重複が複雑性に変わるのを防ぐことです。判断サービスが増えるたびに、設定、レイテンシー、ログ、可用性の要件が生じます。

Arcjetにとって当面の機会は、重大な結果を伴う関数が実行される直前の最終ポリシーチェックポイントになることです。リスクは、チームが広く導入しても強制は限定的にしか行わない、別のダッシュボードになることです。

Arcjetのエージェントランタイムセキュリティを評価する開発者は、範囲を限定した一つのワークフローから始めるべきです。入力、アイデンティティ、ツール、データアクセス、承認ステップ、不可逆な操作を整理する必要があります。

次に、最も重大な呼び出しを保護し、そのルールをドライランモードで運用できます。ブロックを有効にする前に、レビュー担当者は正当なケースと敵対的なケースの両方を確認すべきです。

セキュリティチームは、サービスが利用できない場合の動作もテストすべきです。返金サービス、本番データベースへの書き込み、文書検索ツールが、同じデフォルトの障害ポリシーを共有すべきではありません。

最後に、チームは結果として得られる監査証跡を検証すべきです。調査担当者は、不必要な機微データを公開することなく、判断を再構成できなければなりません。

このローンチは、AIセキュリティにおける実際の変化を示しています。エージェントがリスクを生むのは、モデル出力だけでなく操作を通じてです。したがって制御は、ソフトウェアが別のシステムを変更する地点までワークフローを追随しなければなりません。

Arcjetは、この考え方の具体的な実装を提示しました。今後数か月で、同社のコード内アプローチが実際の組織全体で一貫した制御を実現できるかが示されるはずです。

開発者にとって、実務上の問いは今や明確です。今日、誤って実行された場合に最も大きな被害をもたらすエージェントのアクションは何か。そこから始め、周囲のアイデンティティとコンテキストを確認したうえで、呼び出しの前に強制可能な判断を置いてください。