翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

有向アクションの使用

AWS DevOps Agent は、オペレーターが明示的に要求したときに、接続されたサービスと AWS アカウントに対して動作できます。例えば、インシデントを調査するオペレーターは、リソースの状態を記述するようにエージェントに要求できます。適切なアクセス許可と承認があれば、オペレーターはエージェントに問題を直接修正するよう依頼することもできます。

エージェントは 2 種類のオペレーションを区別します。

有向アクションの安全モデルは、多層防御です。この機能はデフォルトで無効になっています。独立したレイヤーを通じてオプトインします。エージェントスペースでの有向アクションの有効化、アカウントごとの IAM ロールの登録、各ツールの分類です。すべての指示されたアクションには、実行時にオペレーターの承認が必要です。すべての承認と結果のアクションは、 AWS CloudTrail の承認演算子に起因します。

AWS リソースに対するアクションの場合、エージェントは、付与するアクセス許可に関係なく、呼び出す AWS SDK オペレーションに独自のガードレールを適用します。これらのガードレールの詳細については、「エージェントが実行しないオペレーション」を参照してください。

例: 調査から緩和計画を実行する

この例では、一般的なシナリオのend-to-endエクスペリエンスを示します。オペレーターは、調査の緩和計画、または改善の推奨事項を確認します。オペレーターは、会話を離れずにエージェントに実行するよう求めます。

サイト信頼性エンジニア (SRE) は、チャット内のエージェントに、 からの SSH アクセスを許可するアカウントを探すよう求めます0.0.0.0/0。エージェントは、オープンイングレスルールを持つセキュリティグループを見つけます。緩和策を推奨します。ルールを内部ネットワーク範囲に制限します。演算子はエージェントに適用するよう指示します。

調査緩和計画または改善推奨事項を検査し、エージェントにステップの実行を求める場合も、同じフローが適用されます。エージェントはステップを特定の提案されたオペレーションに変換し、行動する前に承認をリクエストします。

サードパーティー製ツールにも同じフローが適用されます。オペレーターのトリアージアラートノイズは、Grafana アラートルールのしきい値を引き上げるようエージェントに求めます。 AWS DevOps Agent はこのツールをミューテーションとして分類し、チームは統合に対する昇格アクセスを有効にしました。エージェントは、ツールとパラメータを示す承認リクエストを提示します。承認後、エージェントは統合を通じてツールを呼び出します。 AWS DevOps Agent はアクションを承認演算子に属性付けします。

ダイレクトアクションが有効になる前、または昇格されたロールが登録されていない場合でも、エージェントは読み取り専用アクションで調査します。実行可能な変更の代わりに手動修復手順を提供します。

前提条件

有向アクションを使用する前に、以下が必要です。

エージェントスペースでダイレクトアクションを有効にする

他の昇格された設定を有効にするには、エージェントスペースで指示されたアクションを有効にする必要があります。これは、指示されたアクションの主なコントロールです。無効にした場合、昇格されたロール登録と昇格されたツールオプトインは効果がありません。昇格された設定を登録しようとすると、拒否される可能性があります。

コンソールでの の有効化

API による の有効化

エージェントスペースの を通じてダイレクトアクションを有効にしますpreferences。このフィールドは、ブール値への設定キーのタイプマップです。これを CreateAgentSpaceと に設定しますUpdateAgentSpace。

次の例では、 CLI AWS でダイレクトアクションを有効にします。

aws devops-agent update-agent-space \
    --agent-space-id <your-agent-space-id> \
    --preferences elevatedActionsEnabled=true

preferences フィールドの動作は次のとおりです。

AWS アカウントの昇格されたロールの登録

関連付けられたアカウントごとに AWS 、オプションで昇格されたロールを登録できます。モニターアカウントとソースアカウントはそれぞれ、昇格されたロール登録をサポートしています。昇格されたロールは、 AWS DevOps Agent がユーザーに代わって指示されたアクションを実行するために引き受けるアカウントの IAM ロールです。ロールを登録するには、関連付け AWS の設定agentElevatedRoleArnで を設定します。

昇格されたロールを登録するときは、次の点に注意してください。

信頼ポリシーの記述

昇格されたロールは、 AWS DevOps エージェントサービスプリンシパルを信頼する必要があります。検証では、継承ロールパスを実行します。 AWS DevOps Agent は、ロールを引き受けるときに 3 つの STS アクションを使用します。信頼ポリシーでは、sts:AssumeRole、、sts:SetSourceIdentityおよび の 3 つすべてを許可する必要がありますsts:TagSession。sts:SetSourceIdentity または を省略するとsts:TagSession、検証ステータスが であっても、指示されたアクションは認証情報の時間に失敗しますvalid。

次の例は、昇格されたロールの信頼ポリシーを示しています。を AWS アカウント ID 111122223333に、 をエージェントスペースの AWS リージョンus-east-1に置き換えます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "aidevops.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "111122223333"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:aidevops:us-east-1:111122223333:agentspace/*"
        }
      }
    }
  ]
}

aws:SourceAccount および aws:SourceArn条件は、混乱した代理問題から保護します。これにより、ロールはユーザー自身のエージェントスペースに代わってのみ引き受けることができます。aws:SourceArn 条件のリージョンは、エージェントスペースのリージョンと一致する必要があります。複数のリージョンでエージェントスペースを操作する場合は、リージョンのワイルドカード (arn:aws:aidevops:*:111122223333:agentspace/*) または特定のエージェントスペース ARN を使用します。

昇格されたロールへのアクセス許可の付与

昇格されたロールのアクセス許可ポリシーは、 AWS DevOps Agent が指示されたアクションを通じてアカウントで実行できる上限を定義します。エージェントはこの上限では動作しません。すべての指示されたアクションには、オペレーターの承認が必要です。承認されたアクションに対して発行された認証情報には、セッションポリシーが適用されます。セッションポリシーは、オペレーターが承認した特定のオペレーションとリソースに絞り込みます。エージェントは、 AWS DevOps Agent が維持するサポートされている IAM AWS アクションの厳選されたリストからのみセッションポリシーを構成します。そのリスト外のアクションをセッションポリシーの一部にすることはできません。リストを参照するには、 AWS DevOps エージェントコンソールで設定ページを開きます。エージェントアクションセクションでサポートされているアクションの表示を選択します。 アクセス許可ポリシーには 2 つのオプションがあります。

オプション 1: AWS 管理ポリシーをアタッチします。 AWS DevOps エージェントは AIDevOpsAgentActionsPolicy 管理ポリシーを提供します。その ARN は arn:aws:iam::aws:policy/AIDevOpsAgentActionsPolicy です。コード形式のポリシードキュメントについては、 AWS 「 マネージドポリシーリファレンスガイド」を参照してください。

管理ポリシーには次の特性があります。

オプション 2: カスタマー管理ポリシーを記述する。管理ポリシーよりも厳しい上限が必要な場合は、独自のポリシーを作成します。エージェントがタッチするアクションとリソースを正確にスコープし、ロールにアタッチします。最小特権の原則に従います。オペレーターが承認することを期待するオペレーションから開始し、必要に応じてのみ展開します。ロールが許可しない指示されたアクションは、承認されても実行時に失敗します。

どちらのオプションでも、サービスコントロールポリシー (SCPs) とアクセス許可の境界を使用して、エージェントが実行できる操作をさらに制限できます。これらのコントロールは、アカウントの他のロールと同様に、昇格されたロールに適用されます。エージェントのアクセス範囲の詳細については、「」を参照してくださいAWS アカウントでのエージェントアクセスの制限。

検証ライフサイクル

信頼ポリシーの検証の実行方法は、アカウントタイプによって異なります。

ロールは、ステータスが の後にのみ、指示されたアクションに使用されますvalid。

ソースアカウントの場合は、 GetAssociationまたは との関連付けをポーリングListAssociationsし、 agentElevatedRoleArnStatusフィールドを確認します。通常、検証は数分以内に完了します。

エージェントが実行しないオペレーション

付与するアクセス許可に関係なく、エージェントは指示されたアクションとして呼び出す AWS SDK オペレーションに独自のガードレールを適用します。これらのガードレールは、 AWS リソースに対するアクションにのみ適用されます。ツール分類は、代わりにサードパーティーのツールを管理します。ツール分類の詳細については、「サードパーティー統合用のツールの分類」を参照してください。これらのガードレールは、昇格されたロールのポリシーで オペレーションが許可されている場合でも適用されます。オペレーターの承認はそれらを上書きしません。

これらのオペレーションのいずれかを実行するように指示された場合、エージェントは拒否し、その理由を説明します。可能な場合は、代わりに手動ステップについて説明します。

これらのガードレールは、昇格されたロールのアクセス許可ポリシー、SCPs、昇格されたロールのアクセス許可の境界など、所有するコントロールを補完します。

サードパーティー統合用のツールの分類

サードパーティーと MCP の統合では、エージェントがツールを呼び出すことができるかどうかと、必要な承認をゲートする 3 つのカテゴリのツールが公開されます。 AWS DevOps エージェントは、ネイティブ統合に固定分類を割り当てます。お客様が設定した MCP サーバーに割り当てます。

お客様が設定した MCP サーバー

MCP サーバーの関連付け (SigV4 バリアントを含む) ではtoolDetails、エントリのツールごとのリストである を使用してツールを自分で分類します。各エントリには nameと がありますtoolClassification。

MCP ツールの接続と許可リストの詳細については、「」を参照してくださいMCP サーバーの接続。

ネイティブ統合 (Datadog、Grafana)

Datadog や Grafana などのネイティブ統合の場合、分類は AWS DevOps エージェントによって修正されます。分類を指定しません。これらの分類を上書きすることはできません。代わりに、ツールエントリのリストenabledElevatedToolsである を通じて で特定のミューテーションツールを選択します。

指示されたアクションの承認

指示されたアクションはヒューhuman-in-the-loop。エージェントが、リソースをミューテーションするように指示されたオペレーションを決定した場合、そのオペレーションは直接実行されません。代わりに、次のことが発生します。

AWS DevOps Agent は、オペレーターの承認リクエストをチャットでのみ表示します。エージェントが自動調査中などにチャット外で変更ツールを呼び出すと、承認リクエストを提示する代わりに呼び出しは失敗します。 AWS DevOps Agent は承認なしで変更ツールを実行することはありません。

承認とその結果のアクションは、 AWS CloudTrail の承認演算子に起因します。

API の承認フロー

Claude、Slack ボット、カスタムオペレーションクライアントなどの AI アシスタントが を呼び出し、オペレーターに承認リクエストを表示しSendMessage、 との決定を記録しUpdateApprovalAction、 との会話を再開するかどうかにかかわらず、エージェントコンシューマーは同じ方法でこのフローを駆動できますSendMessage。

モニタリングと監査

トラブルシューティング

登録されたロールは に残りますpending-confirmation。これは、検証が非同期であるソース (セカンダリ) アカウントに適用されます。通常、検証は数分以内に完了します。ステータスが移行しない場合は、ロールが存在することを確認し、ロール ARN を再登録して検証を再度トリガーします。

ロールのステータスは ですinvalid。信頼ポリシーの検証に失敗しました。以下を確認します。

信頼ポリシーを修正し、ロールを再登録します。

ロールのステータスが であっても、指示されたアクションは失敗しますvalid。valid ステータスには、登録時の検証チェックが反映されます。検証後に信頼ポリシーが変更された場合、またはそのaws:SourceArn条件がエージェントスペースとは異なるリージョンに固定されている場合、ライブの assume-role 呼び出しは失敗する可能性があります。上記のチェックリストに照らして信頼ポリシーを確認します。

ValidationException 昇格されたロールを登録する場合。昇格された設定を登録する前に、エージェントスペースで指示されたアクションを有効にする必要があります。エージェントスペースで有向アクションを有効にしてから、ロールを登録します。

の指定時のツール名の不一致エラーtoolDetails。の各名前は、大文字と小文字を含む、関連付けで有効なツールリストのツール名と完全に一致toolDetailsする必要があります。2 つのリストを比較し、不一致があれば修正してから再試行します。