公式ドキュメント化されたDevOps AgentガードレールとSecurityHub / GuardDuty / S3の調査能力を確認してみた
こんにちは。たかやまです。
過去のAWS DevOps Agentを触ってみたブログでは、Security HubやGuardDutyの調査で権限エラーが出るケースがありました
ただ、最近ではGuardDutyの調査でこちらのようなブログも出ています。
そこで今回は、2026年5月時点でのDevOps Agentの調査能力を改めて調べてみます。
また、検証の中で新たに開示されたエージェントアクセスの制限についても触れているので、気になる方はぜひご覧ください。
さきにまとめ
-
アクセス制御の仕様がドキュメントに明記され、追加で有効化できる権限・ブロックされる権限・両者の関係が公式に整理された
- Limiting Agent Access in an AWS Account - AWS DevOps Agent
- DevOps Agentの実効権限は「IAMロールで許可した権限 x DevOps Agent側の権限ガードレールとしてセッションポリシー（執筆時点非公開）」の両方で許可されている権限のみが有効になる
- 明示されている追加できる権限は以下の通り
Service Actions Amazon S3 s3:GetObject,s3:ListBucketAWS Direct Connect directconnect:DescribeConnections,directconnect:DescribeDirectConnectGatewayAssociations,directconnect:DescribeDirectConnectGateways,directconnect:DescribeLags,directconnect:DescribeVirtualInterfaces -
デフォルトアクセス対象は AIDevOpsAgentAccessPolicy で確認可能
- Security Hub・GuardDutyとも
GetFindingsはデフォルト権限に含まれないが、Security Hubは検証時点で権限の追加可能（非公式） - Security HubにGuardDutyのFindingsを渡すことで間接的にGuardDutyのFindingsをDevOps Agentが参照することができる
- Security Hub・GuardDutyとも
-
削除や変更系（OS関与コマンド含む）のアクションは特権ロールを付与してもガードレールで遮断される
- DevOps Agentは「運用のチームメイト」として責任分担が明確に設計されており、アクセスできたとしても今後修正される可能性あり
確認してみる
前提として特にカスタマイズしていないAgent Spaceを作成して調査をしてみます。
Security Hubの調査 および ドキュメント確認
まずはサクッとチャットからSecurity Hubの調査を依頼してみます。
当時は権限エラーで拒まれていましたが、現在は情報取得できるようになっています！
（後述で補足しますが、当時もFindingsを直接取得できなかっただけでSecurity Hubのリスト周りは確認できた可能性があります。）
呼び出されたツールはアコーディオンメニューから確認することができます。
ツールとして use_aws が呼び出されていることがわかりますね
この辺りはkiroで搭載されている仕組みを利用していそうな雰囲気があります
また、Investigationから問い合わせて確認してみます。
こちらも use_aws を呼び出して調査しています。
調査がシンプルすぎたのか、「根本原因」までいかずにネクストアクションの提示でとまってしまいました。
チャットから調査内容を参照のうえネクストアクションを依頼してみました。
以前はなかったと思いますがチャット機能がClaudeの AskUserQuestion のように選択肢を提示してくれるようになっていますね
また、推奨アクションにはフラグを立ててくれるのは良いですね
推奨事項のセキュリティグループの使用状況の確認を選択して、その後のやり取りを続けたところ最終的にセキュリティグループの削除を提示（画像は選択後のもの）されたので依頼してみます
DevOps Agentのコンセプトとしては調査の運用支援で削除実行は実施しない設計ですが、まさか...？
まさかと思いましたが、さすがにブロックされましたね
そのかわりに「緩和計画」のように手動での削除方法を提示してくれました
ツールのレスポンスを見る感じだと権限エラーの雰囲気もあるので、DevOps Agent自体の権限を追加してみたいと思います
一時的に特権権限を付与して実行してみます。
が、権限を付与した状態でもちゃんとブロックされましたね
もう少し深掘りしてみたところ、以下のようなレスポンスが返ってきました。
内容としてはDevOps Agent側で権限のガードレールとしてセッションポリシーを使って制限をかけているということです。
なお、ソースドキュメントを求めたらプロンプトインジェクション防止のためにブロックされました。
なので私の方でドキュメントをあさってみると、以下のドキュメントがありました。
こんな内容あったかなとDocument Historyをみてみましたが更新対象としては記録されておらず、Wayback Machineを見る限り2026/5/16ごろに反映されていたようです。
ポイントとなる内容を引用すると以下の通りです。（日本語訳）
#### 追加で有効化できる権限
| Service | Actions | Use case |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Amazon S3 | `s3:GetObject`, `s3:ListBucket` | S3に保存されたアプリケーションデータ、ログ、設定の読み取り |
| AWS Direct Connect | `directconnect:DescribeConnections`, `directconnect:DescribeDirectConnectGatewayAssociations`, `directconnect:DescribeDirectConnectGateways`, `directconnect:DescribeLags`, `directconnect:DescribeVirtualInterfaces` | ネットワーク接続性の問題調査 |
#### ガードレールでブロックされる権限
ガードレールに含まれていない権限をロールに追加しても、エージェントは利用できません。これは設計上の挙動で、ロールが許可していてもエージェントは意図された範囲外のアクションを実行できないようになっています。
たとえば `s3:PutObject`、`ec2:TerminateInstances`、`dynamodb:DeleteItem` のような書き込み系操作はガードレールに含まれていないため、ロールでこれらを許可していてもエージェントは実行できません。
#### サマリ
| Layer | Who controls it | Purpose |
| --------------------- | ---------------- | ------------------------------------------ |
| IAM role policies | ユーザー | エージェントに何を許可したいかを定義する |
| Permission guardrail | AWS DevOps Agent | エージェントが実行できる最大範囲を定義する |
| Effective permissions | 両者の積集合 | エージェントが実際に実行できる範囲 |
参照 : Understanding permission guardrails - AWS DevOps Agent
つまり、IAMロールで許可した権限とDevOps Agent側のガードレール、両方で許可されている範囲だけが実際にエージェントが使える権限になるという仕組みです。
DevOps Agentのガードレール内容は執筆時点では公開されていないようです。
DevOps Agentのアクセス制御に明言されるようになったのはありがたいですね。
また、権限によってはユーザー側で追加で付与することでアクセスできるものがあることがわかりました。
ちなみにDevOps Agentがデフォルトでアクセス対象となっているリソースは AIDevOpsAgentAccessPolicy から確認することができます。
（ドキュメントからも確認可能）
こちらのポリシーを見る限りSecurity HubのGetFindingsは許可されていないので、直接コンプライアンスは見れずList権限で調査をしていたようですね
再度確認のため改めて、デフォルトの権限でGetFindingsでの調査を依頼するとエラーが出ました。
こちらに権限を付与した状態で実行すると、Security Hubのコンプライアンスの内容を取得することができました。
GuardDutyの調査
次にGuardDutyへの調査を確認してみます
事前に amazon-guardduty-tester を実行してGuardDutyの communicating with a domain name related to a known malicious domain name. イベントが発生している環境で調査をします。
GuardDutyもSecurity Hub同様にGetFindingsの権限は付与されていません。
今回は初めから特権を付与して実行してみます。
GuardDutyについてはSecurityHubと違い明確に GetFindings がDevOps Agent側のガードレールによって権限が制限されているようです。
そのため、冒頭のGuardDutyの調査ブログなどは直接Findingsを取得しているのではなくGuardDutyの検出をトリガーに関係するリソースを調査しているような流れになりそうですね
ワークアラウンド的にはなりますが、上述のSecurityHubで検証したようにGetFindingsの権限を付与することでSecurity Hub経由からのGuardDutyのFindingsは確認できるのでそちらからの調査をトリガーにすることでより間接的にGuardDutyのFindingsを渡すことはできそうですね。
SecurityHubを起点にしたGuardDutyの調査はこちらのブログを参考にしてください。
S3ファイルの調査
次にS3への調査を確認してみます
こちらはドキュメントに記載されている追加で有効化できる権限になります。
| Service | Actions | Use case |
|---|---|---|
| Amazon S3 | s3:GetObject, s3:ListBucket |
S3に保存されたアプリケーションデータ、ログ、設定の読み取り |
参照 : Understanding permission guardrails - AWS DevOps Agent
事前に GuardDutyの S3 Malware Protection を有効化した環境で、S3バケットに eicar.txt ファイルをアップロードして検知した状態で調査します
まずはデフォルトの権限で調査します。
結果として根本原因に辿り着いていますが、「調査ギャップ」としてS3バケット内のオブジェクトにアクセスできないことが記録されています。
次は検証用に特権を付与して再度調査リクエストを投げてみた結果がこちらです。
先ほどギャップとしてあった、S3バケットの調査権限に関する問題はなくなっていますね
ツール上でも正常に呼び出せていることがわかります
Security HubのGetFindingsは公式アプローチではないですが、こちらのS3バケットへの権限付与は公式なアプローチなので必要な方は権限を付与いただくとより調査権限を強化できますね
OS調査
こちらは結論から言うと現時点でOS調査はできません。
こちらも検証用に特権をつけた状態でOS調査を依頼してみましたが、しっかり制限されました。
DevOps Agent自体が運用のチームメイトという位置付けで、変更を伴う作業（可能性のある作業を含む）は明確に責任分担している感じですね
MCPで機能拡張することができるので、どうしてもDevOps AgentでOS調査したい場合には独自にOS調査ツールを作成することもできそうですね
最後に
改めてDevOps Agentの調査能力を確認してみると、当時の検証時点と比べてかなり進化していて、Security Hubの調査も追加権限を付与することでより深掘りした調査が可能になっています。
一方で、削除などの変更系アクションや、GuardDutyのFindings直接取得、EC2のOS内部調査はガードレール側でしっかり遮断されており、調査支援に徹する「運用のチームメイト」というコンセプトが設計レベルで貫かれている印象です。
ユーザー側でできる拡張はIAMロールへの権限追加までで、その先はDevOps Agent側のガードレールで決まる、という二層構造を理解しておくと、できること／できないことの線引きで迷いにくくなりそうです。
OS調査のように現時点で対応していない領域については、MCPによる機能拡張で独自ツールを差し込んでいく方向も今後試してみたいところです。
以上、たかやま(@nyan_kotaroo)でした。
