Run an AWS Security Agent penetration test against a live web application — registers and verifies the target domain, exercises the supplied endpoints with the managed Security Agent service, and returns verified runtime findings. Use when the user asks to pentest, run a penetration test, test their app's attack surface, find runtime vulnerabilities, register or verify a target domain, or check pentest status / findings.
80
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
This skill handles pentest setup, execution, and findings. Initial Security Agent setup (agent space, role, bucket) is handled by the setup-security-agent skill — if .security-agent/config.json is missing, the pentest workflow auto-runs setup inline first.
Pentests are slow (1-24 hours) and active — they probe a real running app. Always confirm the user is authorized to test the target before starting.
The CLI examples below use placeholders. Resolve them at the start of every pentest:
| Placeholder | How to resolve |
|---|---|
<id> (agent space) | config.agent_space_id |
<region> | config.region (default us-east-1) |
<account> | aws sts get-caller-identity --query Account --output text (cache for the rest of the turn) |
<role-arn> | arn:aws:iam::<account>:role/SecurityAgentScanRole |
<td-id> | targetDomainId returned by create-target-domain (cache under config.target_domains[<domain>]) |
<pentest-id> | pentestId returned by create-pentest |
<pj-id> | pentestJobId returned by start-pentest-job |
Read .security-agent/config.json. If missing → tell the user one line — "First pentest in this workspace — running setup first." — and run the setup-security-agent workflow inline before continuing.
Verify agent space still exists:
aws securityagent batch-get-agent-spaces --agent-space-ids <id>If missing, clear agent_space_id from config.json and run setup-security-agent again.
Resolve account and role ARN from the table above.
Authorization check: ask the user "Do you own or have explicit permission to pentest <target>?" if it's not obvious from context. Do not proceed without confirmation.
aws securityagent create-target-domain --agent-space-id <id> \
--target-domain-name <domain> --verification-method HTTP_ROUTEThe response includes a verification token / route. Tell the user what to put on their server (typically a .well-known/... file or HTTP route returning a token), then:
aws securityagent verify-target-domain --agent-space-id <id> --target-domain-id <td-id>Persist the verified target_domain_id in .security-agent/config.json under target_domains: { "<domain>": "<td-id>" } so future pentests can reuse it.
Ask the user for:
pentest-<timestamp>)aws securityagent create-pentest --agent-space-id <id> --title <title> \
--service-role <role-arn> \
--assets endpoints=[{uri=https://example.com/api/login},{uri=https://example.com/api/upload}]Capture pentestId.
aws securityagent start-pentest-job --agent-space-id <id> --pentest-id <pentest-id>Capture pentestJobId. Append to .security-agent/pentests.json (create as [] if it doesn't exist yet — the directory itself is already created by setup):
{
"pentest_id": "p-...",
"pentest_job_id": "pj-...",
"agent_space_id": "as-...",
"title": "pentest-...",
"endpoints": ["https://..."],
"started_at": "2026-06-01T20:00:00Z",
"status": "IN_PROGRESS"
}Tell user: "Pentest started ({pentest_job_id}). Pentests typically run 1-24 hours depending on scope. I'll check every 15 minutes — say 'stop polling' to opt out."
sleep 900 (15 minutes) between checks. Do not poll faster.
Status:
aws securityagent batch-get-pentest-jobs --agent-space-id <id> --pentest-job-ids <pj-id>Only respond when status changes or on terminal state (COMPLETED, FAILED, STOPPED).
On COMPLETED → run the Findings workflow.
aws securityagent list-findings --agent-space-id <id> --pentest-job-id <pj-id>If nextToken is returned, call again with --next-token <token> until empty.
aws securityagent batch-get-findings --agent-space-id <id> --finding-ids <id1> <id2> ...Present in chat grouped by severity (same icons + format as code scans):
🟣 CRITICAL: {name}
Endpoint: {endpoint}
{description}Write a full report to .security-agent/pentest-{pentest_job_id}.md with every field returned (findingId, name, description, riskLevel, riskType, confidence, status, endpoint, request/response samples if present, and remediationCode if present).
Tell user: "Full details written to .security-agent/pentest-{pentest_job_id}.md"
aws securityagent stop-pentest-job --agent-space-id <id> --pentest-job-id <pj-id>create-pentest will fail otherwisetarget_domain_id from config.json instead of re-verifyingValidationException on verify-target-domain → the verification route isn't responding correctly yet. Ask user to confirm the route is live and serving the expected token.target domain not verified → run verify-target-domain (step 1) again.IN_PROGRESS for >24 hours → likely a backend issue or the target is unreachable. Stop and inspect.AccessDenied on the service role → the service role doesn't have the network/runtime permissions a pentest needs. The default SecurityAgentScanRole is for code scans only — pentests against AWS resources may need broader permissions. Direct user to the AWS Security Agent console to configure a pentest-specific role.222ce56
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.