本文へ移動
Telemetry
ドキュメントを見る
ガイド更新日: 2026年7月30日Telemetry 編集チームと製品チームによるレビュー4 最小読み取り時間

コーディング エージェントでこのドキュメントを使用してください

Claude Code、Codex、Cursor、または別のコーディング エージェント用の集中プロンプト パックを開き、それをここで説明するワークフローに適応させます。

このページの内容
  1. ツールとリスクの棚卸しから始める
  2. 実行前にポリシーの決定を記録する
  3. 意思決定と実行結果を分離する
  4. リソースサーバーで認可を適用する
  5. SQL で拒否、承認、ポリシー変更を確認する
  6. 調査スケジュールを作成する
  7. アラートを出す前に障害パスを検証する

構造化イベントによる AI エージェントのセキュリティ監視

AI エージェントのセキュリティ監視は、アプリケーションが強制可能な決定を下した時点、つまりツールが保護されたデータを読み取る前、状態を変更する、コードを実行する、または外部システムを呼び出す前に開始する必要があります。有用なテレメトリは、プロンプトやツールのペイロードのコピーではありません。これは、どのアクション クラスがリクエストされたか、どのポリシー バージョンがそれを評価したか、許可されたか、拒否されたか、承認に送られたか、およびその後の最終結果についての限定されたレコードです。

Telemetry は、構造化された意思決定のための分析面です。承認の強制、サンドボックス ツール、テナントの分離、秘密の管理、セキュリティ証拠を保存するシステムの置き換えは行いません。アプリケーション層とポリシー層で適用を維持し、時間の経過とともに動作を確認するために必要な承認済みのディメンションのみを送信します。

ツールとリスクの棚卸しから始める

エージェントが検出または起動できる各ツールのインベントリを作成します。わかりやすい表示名ではなく、その効果によって分類します。

アクションクラス 典型的なレビューの質問
read_only 承認された公開インデックスを検索する その結果、制限されたデータが公開されたり、テナントの境界を越えたりする可能性がありますか?
local_state_change 生成されたファイルを分離されたワークスペースに書き込む 宛先はスコープ指定されており、回復可能ですか?
external_state_change チケット、データベース行、またはクラウド リソースを更新する 攻撃者は正確なターゲットと操作に対する権限を持っていますか?
code_execution コマンドまたはジョブを実行する どのような分離、許可リスト、時間制限、リソース制限が適用されますか?
credential_use 委任された資格情報を使用してサービスを呼び出す 資格情報の範囲はユーザー、リソース、および要求されたアクションに限定されていますか?

リスク分類は、製品とセキュリティに関する決定です。この例をポリシーとして運用環境にコピーしないでください。承認、インシデント対応、プライバシー、および影響を受けるシステムを所有する人々とともに、管理される値を定義します。

OWASP 大規模言語モデル アプリケーションのトップ 10 は、迅速な注入、安全でない出力処理、過度の代理店、機密情報の開示などのリスクを別個の問題として扱います。承認の決定を監視することは、それらの境界を調査するのに役立ちますが、ダッシュボード自体は緩和策ではありません。の OWASP 即時注入ガイダンス また、アプリケーションが命令として機能することを意図していない場合でも、信頼できないコンテンツがモデルの動作に影響を与える可能性がある理由も説明します。

実行前にポリシーの決定を記録する

1 つ使用してください agent_tool_authorization_decided 最終的な政策決定ごとにイベントが発生します。その粒度は、1 回の論理ツール呼び出し試行であり、1 回のモデル応答や 1 回の完全なエージェント実行ではありません。推奨されるフィールドは次のとおりです。

  • event_id, timestamp_utc, run_id、そして tool_call_id 同一性と相関性のため。
  • workflow, tool_name、そして action_class 制限された運用上の次元として。
  • risk_level, decision, reason_code、そして policy_version 制御されたポリシーフィールドとして。
  • release, environment、プライバシー保護 account_id 変化分析用。

エージェントツール認可イベントスキーマ 完全なスターター契約を文書化します。キープする decision 次のような値に限定されます allowed, denied、そして approval_required。などの理由 scope_denied または human_approval_required 自由形式モデルの説明よりも安全で比較可能です。

生のプロンプト、補完、ツール引数、ツール結果、取得したドキュメント、認証ヘッダー、Cookie、トークン、接続文字列、または顧客コンテンツは含めないでください。 ツール名には、次のような安定した識別子を使用します: database_write、シリアル化された関数呼び出しではありません。

意思決定と実行結果を分離する

承認は、アクションを続行してもよいかどうかを答えます。実行が成功したこと、またはビジネスの結果が安全であったことを証明するものではありません。次のような別の端末イベントを発行します。 agent_tool_completed 同じように run_id そして tool_call_id.

イベント 穀物 有用な結果
agent_tool_authorization_decided 最後の政策決定 許可、拒否、または承認が必要
agent_approval_resolved 人間によるレビューが 1 件完了しました 承認、拒否、期限切れ、またはキャンセル
agent_tool_completed 1 回の端末実行試行 成功、失敗、タイムアウト、またはキャンセル
agent_run_completed 1 つのターミナル エージェントが実行される タスクの成功、失敗、または人間による引き継ぎ
agent_policy_changed 公開された 1 つのポリシー変更 以前のバージョン、新しいバージョン、所有者、およびロールアウト

これらの粒度を分けておくと、重要なケースが可視化されます。つまり、許可された呼び出しが失敗する可能性があり、承認が実行されずに期限切れになる可能性があり、技術的に成功したツール呼び出しでもエージェントの結果が拒否される可能性があります。

リソースサーバーで認可を適用する

モデル コンテキスト プロトコルの展開の場合は、実装境界におけるプロトコルの認可とセキュリティ ガイダンスに従ってください。の MCP認可仕様 は認可の責任を説明しますが、 MCP セキュリティのベスト プラクティス ガイド 導入されたシステムの脅威と軽減策について説明します。の MCPツールの仕様 は、ツールの注釈を信頼できるセキュリティ境界ではなくヒントとして扱います。

実際には:

  1. 保護されたリソースを所有するコードでポリシーを決定します。
  2. そこでアクター、テナント、ターゲット リソース、操作、および委任されたスコープを検証します。
  3. ポリシーで重大なものとしてマークされているアクション クラスについては、人間の承認を必要とします。
  4. 評価が最終的に完了した後にのみ、制限付きの決定を発行します。
  5. 施行層が許可する場合にのみツールを実行します。
  6. 実行後に別のターミナル結果を出力します。

アクションが許可されているかどうかの自己報告をモデルに依存しないでください。同様に、ツールの説明や注釈を、操作が読み取り専用であることや安全であることの証拠として扱わないでください。

SQL で拒否、承認、ポリシー変更を確認する

AIエージェントツール認可 SQLレシピ ツールとリスク クラスごとに意思決定をグループ化します。拒否率のほかに絶対数も維持されるため、サンプルが少ないと誤った緊急性が生じることはありません。

便利なダッシュボードには次のものが含まれます。

  • ツール、ワークフロー、リスクレベル、リリースごとの総合的な意思決定。
  • 許可された数、拒否された数、および承認が必要な数。
  • 目に見える意思決定分母を持つ拒否率。
  • 承認キューの経過時間と解決結果。
  • 許可されたアクションが後で失敗した。
  • ポリシーバージョンの変更前後の意思決定の組み合わせ。

これらの信号は注意して解釈してください。予想される拒否は、ポリシーが機能していることを示す可能性があります。拒否率の低下は、より安全なエージェントのリリース、弱いポリシー、またはトラフィックの変化を反映している可能性があります。拡大する承認キューは、攻撃ではなく所有権の問題になる可能性があります。

調査スケジュールを作成する

意思決定、承認、ツール結果、実行結果を次の識別子で関連付けます: run_id そして tool_call_id。レビューされたインシデント ウィンドウの場合、次のように再構築します。

  1. どのワークフローとリリースがアクションを要求したか。
  2. どのポリシー バージョンがそれを評価したか。
  3. 制限付きの決定と理由コード。
  4. 人間がそれを承認したか拒否したか。
  5. 実行が開始されたかどうか、および実行がどのように終了したか。
  6. エージェントの実行が完了したか、失敗したか、ハンドオフされたか。

完全性、アクセス、保持、削除の要件に合わせて設計されたシステムに詳細な証拠を保管します。一般的な分析ではパターンを特定し、再現可能なタイムラインを提供できますが、検証済みのコントロールなしでコンプライアンス アーカイブとして提示すべきではありません。

アラートを出す前に障害パスを検証する

許可、拒否、承認が必要、承認期限切れ、実行失敗、およびポリシー バージョン変更パスの合成ケースを実行します。次のことを確認します。

  • 結果として生じるすべてのツール呼び出しは、最終決定を 1 つだけ受け取ります。
  • 拒否された呼び出しは実行されません。
  • 承認が必要な呼び出しはレビューを回避できません。
  • 相関識別子は、目的のグレインのみを結合します。
  • 禁止されたコンテンツがイベント ペイロードに到達することはありません。
  • テレメトリが欠落していても執行が弱まるわけではありません。
  • アラートには、レビュー済みのしきい値、十分な量、および明示的な所有者が使用されます。

から始めてください AI エージェントのセキュリティの使用例 実装プロンプトを表示するか、 AI エージェントのセキュリティ監査テンプレート。コスト、レイテンシ、再試行、ツールの信頼性については、次を使用します。 AIエージェントの監視。エージェント境界外での認証および管理アクションの場合は、より広範な セキュリティ監査分析ガイド.

関連製品の機能

エージェントの実行、ツールの使用、トークンのコスト、品質、製品の成果を結び付けます。

所有権と技術リファレンス

Telemetry 編集チームがこの説明を所有しています。製品チームは動作、例、境界をレビューします。

編集基準を見直す