DevOps Agentのリソース変更操作（エージェントアクション）で緩和計画を実行してみた
こんにちは。たかやまです。
これまでDevOps AgentのIAM権限まわりのアップデートを追ってきましたが、いずれも読み取り権限の強化でした
- DevOps Agentの権限ガードレールがReadOnlyAccessポリシーに対応しました | DevelopersIO
- 2026年07時点のDevOps AgentのIAM権限アップデートを調べてみた | DevelopersIO
- 2026年06時点のDevOps AgentのIAM権限アップデートを調べてみた | DevelopersIO
そんなDevOps Agentが、2026年8月25日付のアップデートでついに変更権限を持つようになりました
ドキュメントはこちらです。
社内でもエージェントアクションの有効化とエージェントアクションを試したブログが上がっています。
こちらのブログではインシデントレスポンスで生成された緩和計画をエージェントアクションで実行するところを試して見たいと思います。
さきにまとめ
- 有効化はアクションロールの登録とエージェントアクション有効化の2ステップ
- ロールの権限は天井（ceiling）であり、実行時は承認された操作だけに絞ったセッションポリシーで動作する
- すべての変更操作は実行のたびにオペレーターの承認が必要
- サポート対象アクションのリスト外の操作は実行されない（検証では
authorize_security_group_ingressが未サポートでブロックされた） - NAT Gatewayのルート修正シナリオでは、承認フロー（use_awsツールでの承認要求→Approve→実行）を経て緩和計画の実行完了まで確認できた
やってみる
アクションロール の付与
DevOps Agent コンソールを開くと新たに「アクションロールのステータス」という項目が追加されています。
デフォルトでは未設定の状態です。
Editボタンで更新画面を開くと、新たに「DevOps エージェントアクションロール」という設定項目が追加されています。
今回はDevOps Agent側で作成されるDevOps Agentアクションロールを指定してみます。
作成が完了するとステータスが「有効」になります。
作成されたロールを確認すると AIDevOpsAgentActionsPolicy というポリシーが付与されています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AIDevOpsElevatedAccess",
"Effect": "Allow",
"NotAction": [
"account:*",
"cognito-identity:*",
"iam:*",
"identitystore:*",
"organizations:*",
"ram:*",
"rolesanywhere:*",
"sso:*",
"sts:*"
],
"Resource": "*"
},
{
"Sid": "AIDevOpsElevatedCarveBacks",
"Effect": "Allow",
"Action": [
"account:GetAccountInformation",
"account:GetGovCloudAccountInformation",
"account:GetPrimaryEmail",
"account:ListRegions",
"iam:ListRoles",
"organizations:DescribeEffectivePolicy",
"organizations:DescribeOrganization",
"sts:DecodeAuthorizationMessage"
],
"Resource": "*"
}
]
}
NotAction でIDや認証情報の管理系サービスを除外しているだけで、それ以外は全アクション全リソースが許可されています。
read権限をガードレールで細かく制御してきたこれまでの流れからすると、だいぶ幅広に許可されている印象です。
ただ、これはエージェントが常時この権限で動くという意味ではありません。ドキュメントではこのロールの権限を「天井（ceiling）」と表現しています。
The role's permission policy is customer-managed. Scope it to the actions you want the agent to be able to take. The role defines the ceiling of what the agent can ever do in your account. It is not a standing grant. Every directed action additionally requires operator approval at execution time, and the agent's session is further scoped to the specific approved operation.
日本語翻訳 :
ロールの権限ポリシーはお客様側で管理します。エージェントに実行させたいアクションにスコープを絞ってください。このロールは、エージェントがそのアカウントで実行しうる操作の天井を定義します。常時付与される権限ではありません。すべてのDirected Actionは実行時にオペレーターの承認を必要とし、エージェントのセッションはさらに承認された特定の操作にスコープが絞られます。
実際の実行時には、承認された操作とリソースだけに絞ったセッションポリシーが付与された一時クレデンシャルが発行されます。
セッションポリシーはAssumeRole時に渡す一時的なポリシーで、ロール自体の権限ポリシーとAND評価されます。
両方が許可した範囲だけが有効な権限になるため、ロールの権限がどれだけ広くても、セッションポリシー側で許可していない操作は実行できません。
セキュリティグループのルール変更を承認したなら、そのセッションで実行できるのはその操作だけということになります。
さらにエージェントは、セッションポリシーを何からでも組み立てられるわけではありません。
AWS側が管理するサポート対象アクションのリストがあり、そこに含まれないアクションはセッションポリシーに入りません。
The elevated role's permission policy defines the ceiling of what AWS DevOps Agent can ever do in your account through directed actions. The agent never operates at this ceiling. Every directed action requires operator approval. The credentials issued for an approved action carry a session policy. The session policy scopes them down to the specific operation and resources that the operator approved. The agent composes the session policy only from a curated list of supported AWS IAM actions that AWS DevOps Agent maintains. An action outside that list can never be part of a session policy.
日本語翻訳 :
アクションロールの権限ポリシーは、AWS DevOps AgentがDirected Actionを通じてアカウント内で実行しうる操作の天井を定義します。エージェントがこの天井のまま動作することはありません。すべてのDirected Actionはオペレーターの承認を必要とします。承認されたアクションに対して発行されるクレデンシャルにはセッションポリシーが付与されます。セッションポリシーは、オペレーターが承認した特定の操作とリソースまでスコープを絞り込みます。エージェントは、AWS DevOps Agentが管理するサポート対象のAWS IAMアクションのリストからのみセッションポリシーを構成します。そのリストに含まれないアクションがセッションポリシーに含まれることはありません。
セッションポリシーはAWSコンソールから確認することができます。
権限を絞る場合は、マネージドポリシーを使わずにカスタマー管理ポリシーを自分で書く形になります。
その場合、ロールが許可していない操作は承認しても実行時に失敗します。
なお、AIDevOpsAgentActionsPolicy の天井にはdelete系のアクションも含まれていますが、エージェント側のガードレールにより以下の操作は拒否されます。
ロールのポリシーが許可していても、オペレーターが承認しても実行されません。
| 拒否される操作 | 例 | 理由 |
|---|---|---|
| リソースの削除 | インスタンス、バケット、テーブル、関数、スタックの削除 | 削除はオペレーター自身が自分の認証情報で実施する |
| permissions boundaryの変更 | iam:PutRolePermissionsBoundary、iam:DeleteRolePermissionsBoundary 等の4アクション |
boundaryはエージェントを制約するための統制であり、エージェント自身には変更させない |
iam:PassRole を伴う操作 |
インスタンスプロファイル付きのEC2起動、実行ロール付きのLambda作成 | ロールを渡すことでサービス経由で間接的に実行範囲が広がるおそれがある |
Independent of the permissions you grant, the agent enforces its own guardrails on the AWS SDK operations it invokes as directed actions. These guardrails apply even when the elevated role's policy allows the operation. Operator approval does not override them.
日本語翻訳 :
付与した権限とは独立に、エージェントはDirected Actionとして呼び出すAWS SDKの操作に対して独自のガードレールを適用します。これらのガードレールは、アクションロールのポリシーがその操作を許可している場合でも適用されます。オペレーターの承認によって上書きすることはできません。
これらの操作を指示した場合、エージェントは実行を断ったうえで理由を説明し、可能な場合は手動での対応手順を案内する仕様のようです。
エージェントアクションの有効化
次に「設定」タブからエージェントアクションを有効化します。
以下の内容を確認されて問題なければ「エージェントアクションを有効にする」を選択します。
The agent can make changes in the connected accounts using the per-account roles you configure, and can run only the actions we support. Every change needs your approval.This setting takes effect only for accounts where you configure an Agent Actions role on the Capabilities tab.
日本語訳 :
エージェントは、設定したアカウントごとのロールを使用して接続したアカウント内で変更を行うことができ、サポートしているアクションのみを実行できます。すべての変更にはあなたの承認が必要です。この設定は、Capabilitiesタブでエージェントアクションロールを設定したアカウントにのみ適用されます。
エージェントアクションのトグルがオンになれば有効化完了です。
それで次の章からエージェントアクションを使って緩和計画を実行してみます。
エージェントアクションで緩和計画を実行する
以下のデモシナリオを使って検証します。
デモシナリオに従ってRDSのセキュリティグループのインバウンドを削除して接続を失敗させてみます。
調査が完了すると以下のような結果が生成されます。
内容に緩和計画が記載されています。
では、チャットでこの緩和計画を実行するように依頼してみます。
が、今回の緩和計画に載っている authorize_security_group_ingress アクションはエージェントアクションではサポートされていないとのことでブロックされました。
上述している「AIDevOpsAgentActionsPolicy」では authorize_security_group_ingress アクションは許可されていますが、実際にはエージェントセッションポリシーでサポートされていないようです。
実際セッションポリシーの対象を確認すると入っていなさそうですね。
では、もう一つのNAT Gateway疎通エラーのシナリオを実行します。
こちらも調査が完了すると以下のような結果が生成されます。
今回は CreateRoute のアクションが実行内容に含まれていますが、エージェントセッションポリシーに含まれていることが確認できます。
では、こちらの内容をもとに緩和計画を実行を指示してみます。
指示すると use_aws toolを使ってユーザーに承認を求めるフローが始まります。
Approveボタンを押下すると緩和計画が実行され、無事実行完了しました。
実際にコンソール上でもルートが追加されていることが確認できます。
Application Statusも無事復旧されていることが確認できますね
最後に
今回はDevOps AgentのDirected Actions（エージェントアクション）を有効化し、デモシナリオの緩和計画をエージェントに実行させるところまで試してみました。
セキュリティグループのシナリオではauthorize_security_group_ingressがサポート対象アクション外でブロックされましたが、NAT Gatewayのルート修正シナリオではuse_aws toolでの承認要求からApprove、実行完了までの一連の流れを実際に確認できました。
ロールの権限がどれだけ広くても、それはあくまで天井であり、実行はセッションポリシーとオペレーターの承認によって絞られる設計になっています。読み取り権限に続いて変更操作にも対応したことで、DevOps Agentが調査から対応まで一気通貫でこなせる場面が増えてきそうです。
以上、たかやま(@nyan_kotaroo)でした。
