/remediating-with-aws-security-agent

name: remediating-with-aws-security-agent
description: >-
  Pull AWS Security Agent findings (penetration tests and code reviews) and drive
  remediation. Use this whenever the user mentions Security Agent, security findings,
  pentest or penetration test results, code review findings, vulnerabilities found in
  their AWS account, "what did the security scan find", remediating or triaging security
  risks, or wants to start fixing reported vulnerabilities — even if they don't name the
  service explicitly. Trigger it for phrases like "get my security findings", "what
  vulnerabilities do we have", "let's fix the pentest results", or "triage the security
  report". The skill discovers scans, exports findings to a gitignored local directory
  (so sensitive exploit detail is never committed), produces a prioritized triage
  summary, and offers to start fixing the highest-risk issues.

Security Agent Remediation

AWS Security Agent is a frontier agent that runs on-demand penetration tests and code reviews against a customer's applications and reports verified security risks. This skill takes you from "I have findings somewhere in AWS" to "I'm actively fixing the most important ones," while keeping the sensitive exploit detail out of source control.

The flow has four stages, and they matter in order:

1. **Discover** which scans exist and how the account is configured (live, read-only). 2. **Export** the findings to a local gitignored directory. 3. **Triage** the findings into a prioritized, human-readable plan. 4. **Remediate** by offering to fix the highest-risk issues.

Why the ordering and the guardrails matter

Findings contain working attack scripts, reproduction steps, file paths, and sometimes leaked secrets or environment details. If that lands in a Git repo, a customer can accidentally commit and publish a step-by-step exploit for their own production system. So the non-negotiable rule is: **findings are written only to `.security-agent/`, and that path is gitignored before anything is written.**

Stage 1: Discover scans (live, read-only)

Find out what the account has. All commands are read-only `list-*` operations.

AWS Security Agent organizes data as a hierarchy — work down it:

Application (account + Region)
└── Agent Space        (workspace for design review, code review, and pentests)
    ├── Penetration test → Pentest job → Findings
    └── Code review      → Code review job → Findings

Run these to orient yourself and show the user what exists:

aws securityagent list-agent-spaces
aws securityagent list-pentests          --agent-space-id <as-...>
aws securityagent list-code-reviews      --agent-space-id <as-...>
aws securityagent list-pentest-jobs-for-pentest         --agent-space-id <as-...> --pentest-id <pt-...>
aws securityagent list-code-review-jobs-for-code-review --agent-space-id <as-...> --code-review-id <cr-...>

Job `status` is one of `IN_PROGRESS`, `STOPPING`, `STOPPED`, `FAILED`, `COMPLETED`. Only `COMPLETED` jobs have a stable, full set of findings.

Match the codebase to a scan, then confirm

Agent spaces, pentests, and code reviews are named after the application they target. Before asking the user to pick from a raw list, make an informed guess about which scan corresponds to *this* repository — the user is working in a codebase for a reason, and the relevant findings are almost always for the app in front of them.

Infer the app identity from the workspace using cheap, high-signal sources:

• The repository / root directory name and the Git remote URL (`git remote -v`).
• Project manifests and their `name`/`description` (`package.json`, `pyproject.toml`,

`*.csproj`, `go.mod`, `Cargo.toml`).

• README titles, product/steering docs, and any obvious product or company name.
• Distinctive frameworks or domains that match a scan title.

Compare those signals against the agent space / scan names (case-insensitive, allow partial and fuzzy matches). Then **always confirm before exporting** — present your best guess and your reasoning, and let the user correct it:

> "This repo looks like **`<product>`** (from `<signal>`), which matches the **<name>** agent > space. Use that, or pick another? [Other Agent Space names, ...]"

If nothing matches with reasonable confidence, say so plainly and show the full list rather than forcing a wrong guess. Never export from a guessed scan without the user's confirmation.

Stage 2: Export findings to `.security-agent/` (gitignored)

Pull findings using AWS CLI commands. Write everything into `.security-agent/` in the repo — never to chat or stdout — because findings include working attack scripts, reproduction steps, and sometimes leaked secrets.

1. Lock down the output directory before pulling anything

mkdir -p .security-agent
echo '*' > .security-agent/.gitignore

2. Resolve the latest COMPLETED job

You should already have the `agentSpaceId` and the pentest/code-review id from Stage 1. List jobs for the chosen scan:

# Pentest jobs:
aws securityagent list-pentest-jobs-for-pentest \
  --agent-space-id <as-...> --pentest-id <pt-...>

# Code review jobs:
aws securityagent list-code-review-jobs-for-code-review \
  --agent-space-id <as-...> --code-review-id <cr-...>

Paginate by passing `--next-token` from the previous response until absent. Filter the job summaries to `status == "COMPLETED"`. If none are COMPLETED, stop and tell the user "No completed jobs found. Please wait for a job to complete or check job statuses." Otherwise, pick the COMPLETED job with the greatest `createdAt` timestamp.

3. List finding summaries and filter by confidence

# Pentest findings:
aws securityagent list-findings \
  --agent-space-id <as-...> --pentest-job-id <pj-...>

# Code review findings:
aws securityagent list-findings \
  --agent-space-id <as-...> --code-review-job-id <cj-...>

Paginate on `--next-token` until exhausted. Confidence values from weakes