🔐setup-security-agent
- ソース
- GitHub で見る ↗
説明
現在のワークスペース向けにAWS Security Agentを設定します。 エージェントスペース、IAMサービスロール、およびS3バケットのプロビジョニングまたは再利用を行います。 次のような場合に使用: ユーザーが「security agentをセットアップしたい」「security scannerを設定したい」「security agentは設定済みか」と尋ねた場合、 またはスキャンやペネトレーションテストを初めて実行する前の初回セットアップ時。
原文を表示
Configure AWS Security Agent for the current workspace — provision or reuse an agent space, IAM service role, and S3 bucket. Use when the user asks to "set up security agent", "configure security scanner", "is security agent configured", or on first-time use before any scan or pentest.
ユースケース
- ✓Security Agentをセットアップしたいとき
- ✓Security Scannerを設定したいとき
- ✓スキャンやペネトレーションテストを初めて実行するとき
- ✓Security Agentの設定状況を確認するとき
本文(日本語訳)
AWS Security Agent — セットアップ
このスキルが担うのは1つのことだけです: ワークスペースに、動作するagent space・IAMサービスロール・S3バケットが連携した状態で存在することを確認します。 スキャンおよびペネトレーションテストは別スキルで処理され、このセットアップが完了していることを前提としています。
ローカル状態の規約
すべてのSecurity AgentスキルはワークスペースローカルのステートをKEY .security-agent/ 配下で共有します:
config.json—{ "agent_space_id": "as-...", "region": "us-east-1", "code_reviews": { "<abs_path>": "cr-..." } }アカウントID・ロールARN・バケット名は命名規約から導出します。code_reviewsマップにより、スキャン時に同じCodeReviewをワークスペース内で再利用できます。scans.json—{ scan_id, code_review_id, job_id, agent_space_id, scan_type, title, started_at, status, path }の配列(最新50件を保持)pentests.json— 同じ構造、ペネトレーションテストジョブ用.gitignore— 内容は*(このディレクトリをGit管理外にする)findings-{scan_id}.md— 各スキャン完了後にスキャンスキルが書き出す
このスキルの役割は config.json を生成し、.gitignore を作成することです。
導出値(設定より規約)
他のスキルは config.json から読み込む代わりに、呼び出しのたびに以下の値を算出します:
| 値 | 規約 |
|---|---|
ACCOUNT |
aws sts get-caller-identity --query Account --output text |
REGION |
config.region(デフォルト: us-east-1) |
service_role_arn |
arn:aws:iam::${ACCOUNT}:role/SecurityAgentScanRole |
s3_bucket |
security-agent-scans-${ACCOUNT}-${REGION} |
config を最小限にする理由: ロール名とバケット名は決定的に導出できるため、それらを保存すると設定ドリフトのリスクが生じます(ユーザーが手動でロールを再作成した場合、古いパスがサイレントに使われ続けます)。
agent_space_id のみを保存する理由は、ユーザーが複数のagent spaceを持つ可能性があり、セッションごとにどれを使うか確認する手間を避けるためです。
ワークフロー
-
既存の状態を確認:
.security-agent/config.jsonが存在すれば読み込む。 -
呼び出し元のIDとリージョンを取得:
export ACCOUNT=$(aws sts get-caller-identity --query Account --output text) export REGION="${AWS_REGION:-us-east-1}" -
Agent space の処理:
-
config.agent_space_idが設定済みの場合、以下で存在を確認する:aws securityagent batch-get-agent-spaces --agent-space-ids <id>レスポンスが存在しないことを示す場合は、未設定として扱う。
-
未設定の場合、既存のagent spaceを一覧表示する:
aws securityagent list-agent-spaces-
既存のものがある場合 → 名前とIDを添えてユーザーに表示し、「いずれかを再利用しますか?それとも新しく作成しますか?」と尋ねる。回答を待つこと。自動選択は絶対にしない。
-
ユーザーが既存のものを選んだ場合、その
agentSpaceIdを使用する。 -
ユーザーが新規作成を希望する場合、または既存のものがない場合:
aws securityagent create-agent-space --name security-scans返された
agentSpaceIdを取得する。
-
-
-
サービスロールの処理 (
SecurityAgentScanRole、ARN:arn:aws:iam::$ACCOUNT:role/SecurityAgentScanRole):-
存在確認:
aws iam get-role --role-name SecurityAgentScanRole -
NoSuchEntityが返された場合はロールを作成する。 冪等性に関する注意: ロールが既に存在する場合、create-roleはEntityAlreadyExistsで失敗します。その場合はupdate-assume-role-policyにフォールスルーして、信頼ポリシーが正しいことを確認してください。# 信頼ポリシー — aws:SourceAccount による confused-deputy ガードを含む cat > /tmp/sa-trust.json <<EOF {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"securityagent.amazonaws.com"},"Action":"sts:AssumeRole","Condition":{"StringEquals":{"aws:SourceAccount":"${ACCOUNT}"}}}]} EOF # 権限ポリシー(S3 + CloudWatch Logs) cat > /tmp/sa-perms.json <<EOF {"Version":"2012-10-17","Statement":[ {"Effect":"Allow","Action":["s3:GetObject","s3:GetObjectVersion","s3:ListBucket"],"Resource":["arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}","arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}/*"]}, {"Effect":"Allow","Action":["logs:CreateLogGroup","logs:CreateLogStream","logs:PutLogEvents"],"Resource":"arn:aws:logs:*:${ACCOUNT}:log-group:/aws/securityagent/*"} ]} EOF aws iam create-role --role-name SecurityAgentScanRole --assume-role-policy-document file:///tmp/sa-trust.json # EntityAlreadyExists の場合: aws iam update-assume-role-policy --role-name SecurityAgentScanRole --policy-document file:///tmp/sa-trust.json # 常に権限ポリシーを(再)適用する: aws iam put-role-policy --role-name SecurityAgentScanRole --policy-name SecurityAgentCodeReviewAccess --policy-document file:///tmp/sa-perms.json
-
-
S3バケットの処理 (
security-agent-scans-$ACCOUNT-$REGION):-
存在確認:
BUCKET="security-agent-scans-${ACCOUNT}-${REGION}" aws s3api head-bucket --bucket "$BUCKET" -
404 の場合、作成する:
# us-east-1: LocationConstraint は不要 aws s3api create-bucket --bucket "$BUCKET" # 他のリージョンの場合: aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint="$REGION" -
常にパブリックアクセスブロックと30日ライフサイクルを(再)適用する:
aws s3api put-public-access-block --bucket "$BUCKET" \ --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true cat > /tmp/sa-lifecycle.json <<'EOF' {"Rules":[{"ID":"AutoDeleteUploads","Status":"Enabled","Filter":{"Prefix":""},"Expiration":{"Days":30}}]} EOF aws s3api put-bucket-lifecycle-configuration --bucket "$BUCKET" --lifecycle-configuration file:///tmp/sa-lifecycle.json
-
-
ロールとバケットをagent spaceに登録する(冪等):
-
既存のリソースを読み込む:
aws securityagent batch-get-agent-spaces --agent-space-ids <id>agentSpaces[0].awsResources.iamRolesとawsResources.s3Bucketsを確認する。 -
ロールARNまたはバケット名がリストに存在しない場合、マージして更新する:
aws securityagent update-agent-space --agent-space-id <id> --name <existing-name> \ --aws-resources iamRoles=[<arn1>,<arn2>...],s3Buckets=[<bucket1>,<bucket2>...]
-
-
.security-agent/config.jsonに保存する(最小構成 — アカウント/ロール/バケットは導出するため不要):{ "agent_space_id": "as-xxxxx", "region": "us-east-1" } -
.gitignoreを作成する(未存在の場合):mkdir -p .security-agent echo '*' > .security-agent/.gitignore -
ユーザーに確認メッセージを表示する: 「セットアップが完了しました。セキュリティスキャンまたはペネトレーションテストを実行できます。」
ルール
- 複数のagent spaceが存在する場合は自動選択せず、必ずユーザーに確認すること
- 安全保護機能を無効にしないこと(パブリックアクセスブロックは常に有効にする)
- 信頼ポリシーは
securityagent.amazonaws.com(本番サービスプリンシパル)を許可し、aws:SourceAccountによる confused-deputy ガードを含めること - ユーザーが規約のデフォルトと異なる独自のロール名やバケット名を指定した場合、次のように伝えること:
「このpluginは規約ベースのデフォルト(
SecurityAgentScanRole/security-agent-scans-${ACCOUNT}-${REGION})を使用します。デフォルトを受け入れるか、スキルを拡張してください。他のスキルはこれらの名前をconfigから読み込むのではなく導出しています。」 config.jsonが存在しない場合、スキャンおよびペネトレーションテストスキルからこのスキルをインライン呼び出しできます。初回ユーザーはセットアップを別途実行する必要はありません。
トラブルシューティング
iam:CreateRoleでAccessDenied→ ユーザーにIAM権限がありません。独自のロールARNを使用してセットアップを実行するか、iam:CreateRole+iam:PutRolePolicy権限の付与を依頼してください。s3api create-bucketでAccessDenied→ バケット名がグローバルで既に使用されているか、ユーザーにs3:CreateBucket権限がありません。ユーザーが所有する既存のバケットを使用して明示的に指定するよう提案してください。- ロールは存在するが信頼ポリシーが誤っている →
update-assume-role-policy(ステップ4のフォールバック)を実行します。ユーザーがそのロールの更新を望まない場合は、別のロールARNを確認してください。 - Agent spaceは存在するが別のリージョンにある → ユーザーに通知し、正しいリージョンを使用するか、現在のリージョンに新しいspaceを作成するよう提案してください。
原文(English)を表示
AWS Security Agent — Setup
This skill handles ONE thing: making sure the workspace has a working agent space, IAM service role, and S3 bucket linked together. Scans and pentests live in separate skills and assume this is done.
Local state convention
All Security Agent skills share workspace-local state at .security-agent/:
config.json—{ "agent_space_id": "as-...", "region": "us-east-1", "code_reviews": { "<abs_path>": "cr-..." } }. Account ID, role ARN, and bucket name are derived by convention. Thecode_reviewsmap lets scans reuse the same CodeReview for a workspace.scans.json— array of{ scan_id, code_review_id, job_id, agent_space_id, scan_type, title, started_at, status, path }(keep last 50)pentests.json— same shape, for pentest jobs.gitignore— contents*so this directory stays untrackedfindings-{scan_id}.md— written by the scan skill after each scan completes
This skill's job is to populate config.json and create .gitignore.
Derived values (convention over config)
Other skills compute these on each invocation rather than reading them from config.json:
| Value | Convention |
|---|---|
ACCOUNT |
aws sts get-caller-identity --query Account --output text |
REGION |
config.region (default us-east-1) |
service_role_arn |
arn:aws:iam::${ACCOUNT}:role/SecurityAgentScanRole |
s3_bucket |
security-agent-scans-${ACCOUNT}-${REGION} |
Why minimal config: the role name and bucket name are deterministic, so storing them adds drift risk (a user re-creating a role manually would silently use a stale path). Only agent_space_id is stored because users may have multiple agent spaces and we don't want to ask which one every session.
Workflow
-
Check existing state: read
.security-agent/config.jsonif it exists. -
Caller identity + region:
export ACCOUNT=$(aws sts get-caller-identity --query Account --output text) export REGION="${AWS_REGION:-us-east-1}" -
Agent space:
-
If
config.agent_space_idis set, verify with:aws securityagent batch-get-agent-spaces --agent-space-ids <id>If the response shows it doesn't exist, treat as missing.
-
If missing, list existing:
aws securityagent list-agent-spaces-
If any exist → show them to the user with name + id and ask: "Would you like to reuse one of these, or should I create a new one?" Wait for the answer. Do not auto-select.
-
If user picks one, use that
agentSpaceId. -
If user wants new, or none exist:
aws securityagent create-agent-space --name security-scansCapture returned
agentSpaceId.
-
-
-
Service role (
SecurityAgentScanRole, ARNarn:aws:iam::$ACCOUNT:role/SecurityAgentScanRole):-
Probe:
aws iam get-role --role-name SecurityAgentScanRole -
If
NoSuchEntityis returned, create the role. Idempotency note:create-rolewill fail withEntityAlreadyExistsif the role already exists. If that happens, fall through toupdate-assume-role-policyto ensure the trust policy is correct.# Trust policy — includes aws:SourceAccount confused-deputy guard cat > /tmp/sa-trust.json <<EOF {"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"securityagent.amazonaws.com"},"Action":"sts:AssumeRole","Condition":{"StringEquals":{"aws:SourceAccount":"${ACCOUNT}"}}}]} EOF # Permissions policy (S3 + CloudWatch Logs) cat > /tmp/sa-perms.json <<EOF {"Version":"2012-10-17","Statement":[ {"Effect":"Allow","Action":["s3:GetObject","s3:GetObjectVersion","s3:ListBucket"],"Resource":["arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}","arn:aws:s3:::security-agent-scans-${ACCOUNT}-${REGION}/*"]}, {"Effect":"Allow","Action":["logs:CreateLogGroup","logs:CreateLogStream","logs:PutLogEvents"],"Resource":"arn:aws:logs:*:${ACCOUNT}:log-group:/aws/securityagent/*"} ]} EOF aws iam create-role --role-name SecurityAgentScanRole --assume-role-policy-document file:///tmp/sa-trust.json # if EntityAlreadyExists: aws iam update-assume-role-policy --role-name SecurityAgentScanRole --policy-document file:///tmp/sa-trust.json # always (re)apply permissions: aws iam put-role-policy --role-name SecurityAgentScanRole --policy-name SecurityAgentCodeReviewAccess --policy-document file:///tmp/sa-perms.json
-
-
S3 bucket (
security-agent-scans-$ACCOUNT-$REGION):-
Probe:
BUCKET="security-agent-scans-${ACCOUNT}-${REGION}" aws s3api head-bucket --bucket "$BUCKET" -
If 404, create:
# us-east-1: no LocationConstraint aws s3api create-bucket --bucket "$BUCKET" # other regions: aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint="$REGION" -
Always (re)apply public access block + 30-day lifecycle:
aws s3api put-public-access-block --bucket "$BUCKET" \ --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true cat > /tmp/sa-lifecycle.json <<'EOF' {"Rules":[{"ID":"AutoDeleteUploads","Status":"Enabled","Filter":{"Prefix":""},"Expiration":{"Days":30}}]} EOF aws s3api put-bucket-lifecycle-configuration --bucket "$BUCKET" --lifecycle-configuration file:///tmp/sa-lifecycle.json
-
-
Register role + bucket on the agent space (idempotent):
-
Read existing resources:
aws securityagent batch-get-agent-spaces --agent-space-ids <id>Look at
agentSpaces[0].awsResources.iamRolesandawsResources.s3Buckets. -
If the role ARN or the bucket name is missing from those lists, merge and update:
aws securityagent update-agent-space --agent-space-id <id> --name <existing-name> \ --aws-resources iamRoles=[<arn1>,<arn2>...],s3Buckets=[<bucket1>,<bucket2>...]
-
-
Persist to
.security-agent/config.json(minimal — account/role/bucket are derived):{ "agent_space_id": "as-xxxxx", "region": "us-east-1" } -
Create gitignore if missing:
mkdir -p .security-agent echo '*' > .security-agent/.gitignore -
Confirm to user: "Setup complete. You can run security scans or pentests now."
Rules
- Never auto-select an agent space when multiple exist — always ask the user
- Never disable safety protections (the public-access-block stays on)
- Trust policy must allow
securityagent.amazonaws.com(production service principal) and include theaws:SourceAccountconfused-deputy guard - If the user provides their own role name or bucket name (different from the conventional defaults), tell them: this plugin uses convention-based defaults (
SecurityAgentScanRole/security-agent-scans-${ACCOUNT}-${REGION}). Either accept those defaults or extend the skill — the other skills derive these names rather than reading them from config. - The scan and pentest skills can call this skill inline if
config.jsonis missing — first-time users don't need to run setup separately.
Troubleshooting
AccessDeniedcallingiam:CreateRole→ user lacks IAM permissions. Ask them to run setup with their own role ARN, or to grantiam:CreateRole+iam:PutRolePolicy.AccessDeniedons3api create-bucket→ either the bucket name is taken globally, or the user lackss3:CreateBucket. Suggest using an existing bucket they own and pass it explicitly.- Role exists but trust policy is wrong →
update-assume-role-policy(step 4 fallback). If they don't want that role updated, ask them for a different role ARN. - Agent space exists but in a different region → tell the user; suggest using the right region or creating a new space in the current region.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。