Name: setup-security-agent
Author: aws

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: 3. Agent space: If config.agent space id is set, verify with: If the response shows it doesn't exist, treat as missing. If missing, list existing: 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: Capture returned agentSpaceId . 4. Service role ( SecurityAgentScanRole , ARN arn:aws:iam::$ACCOUNT:role/SecurityAgentScanRole ): Probe: 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. 5. 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. A 403 Forbidden on a bucket that exists but is foreign owned is fatal — abort setup and never upload. Probe (asserts ownership): If not found, create it. A BucketAlreadyExists error means another account already holds the global name — treat it as fatal and distinct from BucketAlreadyOwnedByYou (which is a safe no op). Re assert ownership after creation before any further use: Always (re)apply public access block + 30 day lifecycle: 6. Register role + bucket on the agent space (idempotent): Read existing resources: 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: 7. Persist to .security agent/config.json (minimal — account/role/bucket are derived): 8. Create gitignore if missing: 9. 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) Every S3 call against the derived bucket MUST pass expected bucket owner "$ACCOUNT" . The bucket name is derived from a non secret account ID, so a third party can pre register it; a 403 / BucketAlreadyExists on a foreign owned bucket is fatal — abort and never upload. 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. 403 Forbidden / BucketAlreadyExists on the derived bucket → the predictable name is owned by a different account (bucket squatting). This is fatal by design — do not upload. Have the user pick a bucket name they own (or run from the expected account/region) and re run setup. 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.