/setup-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
$ npx -y skills add aws/agent-toolkit-for-aws --skill setup-security-agent --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/setup-security-agent
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
setup-security-agent.SKILL.mdname: setup-security-agent
description: 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.
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. 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 untracked
- `findings-{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
1. **Check existing state:** read `.security-agent/config.json` if it exists. 2. **Caller identity + region:**
export ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
export REGION="${AWS_REGION:-us-east-1}"3. **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`. 4. **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.json5. **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.json6. **Register role + bucket on the agent space (idempotent):**
- Read existi
Read more
name: setup-security-agent description: 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.
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. 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 untracked
- `findings-{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
1. **Check existing state:** read `.security-agent/config.json` if it exists. 2. **Caller identity + region:**
export ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
export REGION="${AWS_REGION:-us-east-1}"3. **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`. 4. **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.json5. **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.json6. **Register role + bucket on the agent space (idempotent):**
- Read existi
Help AI coding agents build, deploy, and manage applications on AWS. The Agent Toolkit for AWS gives AI coding agents the tools, knowledge, and guardrails they need to work with AWS services.
Repo: aws/agent-toolkit-for-aws
Other skills on agent-toolkit-for-aws.
- /analyzing-release-readiness
Trigger a pre-merge release readiness review on a GitHub PR, GitLab MR, or local branch. Use when the user wants to analyze code changes for risk, correctness, and potential rollback issues before merging. Trigger words include release readiness, analyze PR, analyze MR, review
Open skill - /chatting-with-aws-devops-agent
Have a fast, conversational analysis with the AWS DevOps Agent. Use for cost optimization, architecture review, topology mapping, knowledge / runbook discovery, security audits, dependency questions, and quick diagnostics — anything that needs a 5-30 second answer rather than a
Open skill - /coordinating-multi-space-devops-agent
Coordinate the AWS DevOps Agent across multiple AgentSpaces from one Claude Code session — route questions to the right space (prod vs staging vs knowledge), query several spaces in parallel and synthesize, or compare findings across accounts. Use whenever the user has more than
Open skill - /diff-scanning-with-aws-security-agent
Run a fast AWS Security Agent diff scan on only the changed code since a git ref. Use when the user asks to scan changes, run a diff scan, check what changed for security issues, scan before committing, scan before PR, or any pre-commit/pre-push security check.
Open skill - /investigating-incidents-with-aws-devops-agent
Run a deep root-cause investigation on the AWS DevOps Agent. Use when the user describes an incident, alarm, outage, or unexplained behavior — keywords like "5xx", "503", "OOM", "latency spike", "deployment failure", "rollback", "sev1", "investigate", "root cause", "debug",
Open skill - /pentesting-with-aws-security-agent
Run an AWS Security Agent penetration test against a live web application — registers and verifies the target domain, exercises the supplied endpoints with the managed Security Agent service, and returns verified runtime findings. Use when the user asks to pentest, run a
Open skill

