Remediating With AWS Security Agent
Pull AWS Security Agent findings (penetration tests and code reviews) and drive...
Install
npx skills add aws/agent-toolkit-for-aws --skill remediating-with-aws-security-agent -g -a claude-code -y- Repository
- aws/agent-toolkit-for-aws3.4k
- Category
- Testing
- Updated
- 5d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 2,671 tokens
- Runs scripts
- No, instructions only
What it does
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:
- Discover which scans exist and how the account is configured (live, read-only).
- Export the findings to a local gitignored directory.
- Triage the findings into a prioritized, human-readable plan.
- 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:
