AWS セキュリティエージェント(クラウドセキュリティの監視・検査を行う自動化ツール)を現在のワークスペースに設定します。エージェント用のスペース、IAM サービスロール(アクセス権限)、S3 バケット(データ保存場所)を新規作成または既存のものを再利用します。 次のような場合に使用: - ユーザーが「セキュリティエージェントをセットアップしてほしい」と依頼したとき - 「セキュリティスキャナを設定してほしい」と依頼されたとき - 「セキュリティエージェントは設定済みですか」と質問されたとき - 初めてセキュリティスキャンやペネトレーションテスト(脆弱性診断)を実行する前に必要な初期設定として
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.
このスキルが担うのは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
ユーザーに確認メッセージを表示する: 「セットアップが完了しました。セキュリティスキャンまたはペネトレーションテストを実行できます。」
securityagent.amazonaws.com(本番サービスプリンシパル)を許可し、aws:SourceAccount による confused-deputy ガードを含めること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を確認してください。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.
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. The code_reviews map 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 completesThis skill's job is to populate config.json and create .gitignore.
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.
Check existing state: read .security-agent/config.json if 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_id is 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-scans
Capture returned agentSpaceId.
Service role (SecurityAgentScanRole, ARN arn:aws:iam::$ACCOUNT:role/SecurityAgentScanRole):
Probe:
aws iam get-role --role-name SecurityAgentScanRole
If NoSuchEntity is returned, create the role. Idempotency note: create-role will fail with EntityAlreadyExists if the role already exists. If that happens, fall through to update-assume-role-policy to 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.iamRoles and awsResources.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."
securityagent.amazonaws.com (production service principal) and include the aws:SourceAccount confused-deputy guardSecurityAgentScanRole / 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.config.json is missing — first-time users don't need to run setup separately.AccessDenied calling iam:CreateRole → user lacks IAM permissions. Ask them to run setup with their own role ARN, or to grant iam:CreateRole + iam:PutRolePolicy.AccessDenied on s3api create-bucket → either the bucket name is taken globally, or the user lacks s3:CreateBucket. Suggest using an existing bucket they own and pass it explicitly.update-assume-role-policy (step 4 fallback). If they don't want that role updated, ask them for a different role ARN.原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。