無料GitHub で公開

pentesting-with-aws-security-agent

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.

aws/agent-toolkit-for-aws

インストール方法を見る

含まれるファイル（1）

SKILL.md6.4 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

AWS Security Agent — Penetration Test

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.

Resolving the values you need

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`

Pre-pentest checks

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.

Workflow

1. Register target domain (one-time per domain)

aws securityagent create-target-domain --agent-space-id <id> \
  --target-domain-name <domain> --verification-method HTTP_ROUTE

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

2. Create a pentest

Ask the user for:

Title (no spaces — use hyphens; default pentest-<timestamp>)
Endpoints to test (one or more URIs under the verified domain)

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.

3. Start the pentest job

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

4. Polling loop

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.

5. Findings

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"

6. Stop a pentest

aws securityagent stop-pentest-job --agent-space-id <id> --pentest-job-id <pj-id>

Rules

Always confirm authorization to test the target before starting
Verify the target domain before creating a pentest — create-pentest will fail otherwise
Reuse a verified target_domain_id from config.json instead of re-verifying
Pentest titles must not contain spaces — use hyphens
Poll every 15 minutes max — pentests are long-running
Don't auto-restart a failed pentest — show the failure to the user first

Troubleshooting

ValidationException 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.
Pentest stuck in 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.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

agent-advisor

無料

Entry point for AI-agent work on AWS: pick a runtime, plan a migration for existing workloads, and build an executable POC — one phased flow. Triggers on: which runtime for my agent, AgentCore vs ECS vs EKS vs Lambda, AgentCore vs Lambda MicroVMs, deploy an AI agent on AWS, agent architecture on AWS, I have an agent idea what do I build, move/migrate my agents to AWS, agent migration plan, add AgentCore services (memory, gateway, identity, policy, observability) to an agent already on AWS, Temporal on AWS (migrate/run Temporal workers on AWS, a service orchestrated by Temporal, Temporal Cloud vs self-hosted). Temporal Workflow code is never rewritten into Step Functions. Requires at least one agentic component — a purely non-agent system (plain services, batch jobs, HTTP endpoints, non-agent Temporal Activities) is out of scope, redirected to gcp-to-aws / heroku-to-aws / llm-to-bedrock. Not for: compute/data migration with no AI agent; pure LLM SDK rewrite (use llm-to-bedrock); per-model pricing.

日本語の概要は準備中です。原文の説明を表示しています。