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 pentest.
- Skill ID
- aws/agent-toolkit-for-aws/setup-security-agent
- Publisher
- aws
- Repository
- agent-toolkit-for-aws
- Installs
- 0
- Files
- 1
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
aws/agent-toolkit-for-aws/setup-security-agentInstalls these files- SKILL.md
What this skill tells the agent
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):
Bucket-ownership enforcement (required). The bucket name is derived from the caller's AWS account ID and region — both non-secret and publicly derivable from ARNs / ECR URIs — so any third party can pre-register ("squat") the predictable name in their own account. Every S3 call MUST pass--expected-bucket-owner "$ACCOUNT"so the operation fails closed if the bucket is owned by someone else. A403 Forbiddenon a bucket that exists but is foreign-owned is fatal — abort setup and never upload.
- Probe (asserts ownership):
BUCKET="security-agent-scans-${ACCOUNT}-${REGION}"
NEED_CREATE=0
if aws s3api head-bucket --bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT" 2>/tmp/sa-head.err; then
: # bucket exists and is owned by this account — safe to reuse
elif grep -q '404' /tmp/sa-head.err; then
NEED_CREATE=1
elif grep -Eq '403|Forbidden' /tmp/sa-head.err; then
echo "FATAL: bucket $BUCKET exists but is owned by another account (403). Possible bucket-squatting — aborting. Nothing was uploaded." >&2
exit 1
else
cat /tmp/sa-head.err >&2; exit 1
fi- If not found, create it. A
BucketAlreadyExistserror means another account already holds the global name — treat it as fatal and distinct fromBucketAlreadyOwnedByYou(which is a safe no-op). Re-assert ownership after creation before any further use:
if [ "$NEED_CREATE" = "1" ]; then
if [ "$REGION" = "us-east-1" ]; then
# us-east-1: no LocationConstraint
aws s3api create-bucket --bucket "$BUCKET" 2>/tmp/sa-create.err || true
else
# other regions:
aws s3api create-bucket --bucket "$BUCKET" \
--create-bucket-configuration LocationConstraint="$REGION" 2>/tmp/sa-create.err || true
fi
if grep -q 'BucketAlreadyExists' /tmp/sa-create.err; then
echo "FATAL: bucket name $BUCKET is already owned by another account (BucketAlreadyExists). Possible bucket-squatting — aborting." >&2
exit 1
elif [ -s /tmp/sa-create.err ] && ! grep -q 'BucketAlreadyOwnedByYou' /tmp/sa-create.err; then
cat /tmp/sa-create.err >&2; exit 1
fi
# Confirm ownership of the freshly created bucket before using it.
aws s3api head-bucket --bucket "$BUCKET" --expected-bucket-owner "$ACCOUNT"
fi- 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:
More from aws
Use this skill in a project
Open any RiverX project, search the Skills panel for aws/agent-toolkit-for-aws/setup-security-agent, and install it in one click.
