setup-security-agent

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
     
      > /tmp/sa-perms.json <<
     
     aws iam create-role --role-name SecurityAgentScanRole --assume-role-policy-document file:///tmp/sa-trust.json
     
     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
     

---

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 the aws:SourceAccount confused-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.json is missing — first-time users don't need to run setup separately.

---

Troubleshooting

• 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.
• 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.