5.2.5. AWS Security Agent: Findings, Reports, and Remediation
💡 First Principle: GuardDuty, Inspector, Macie and Config watch your AWS environment. None of them attacks your application to prove that a flaw is exploitable. AWS Security Agent fills that gap. It is an AI agent that reviews designs and code against your security requirements and runs penetration tests on demand against applications you own. For the exam, the operator's job is to set it up safely, read its findings correctly, and close the loop from finding to fix to revalidation.
The AWS documentation now describes Security Agent as "now part of AWS Continuum". The exam guide calls it AWS Security Agent, and so does this guide.
Three interfaces, three roles:
| Interface | Who | What happens there |
|---|---|---|
| AWS Management Console | Administrator | Create Agent Spaces (one per application or project), define security requirements, verify target domains, connect code repositories, manage user access |
| Security Agent web application | User | Run penetration tests, code reviews, threat models and design reviews; review findings |
| Code repository / IDE (GitHub, IDEs such as Kiro) | Developer | Security findings as pull request comments; remediation pull requests with code fixes |
User access to the web application is managed through IAM Identity Center (assign users in the Security Agent console) or, with IAM-only access, through the admin access link in the console.
Four capabilities:
| Capability | Input | Output |
|---|---|---|
| Design review | Uploaded design and architecture documents | Findings against your security requirements, with remediation guidance, before code is written |
| Code review | Connected repositories or S3 buckets; pull requests | Vulnerabilities and requirement violations; PR comments; optional fix pull requests |
| Threat modeling | Source code, scope documents, or both | System overview (trust boundaries, data flows) plus threats classified by STRIDE |
| Penetration testing | Target URLs, credentials, source code and docs | Validated, exploitable vulnerabilities with evidence, steps to reproduce and fix pull requests |
Security requirements (for example approved authorization libraries, logging standards and data access policies) are defined once in the console as requirement packs: AWS-managed, custom, or generated from your uploaded security documentation. They apply across all Agent Spaces and drive design and code reviews.
Setting up a penetration test (the operator's checklist):
| Setting | What to know |
|---|---|
| Domain verification | Only verified domains can be Targets. Verify with a DNS TXT record (One-click verification if the zone is in Route 53 in the same account) or an HTTP route token file. DNS and HTTP verification also cover the domain's subdomains. Private VPC verification is for private targets, and the verified name must match the full domain name of the target endpoints. |
| Network scope | Target is attacked. Accessible is reached but not attacked (hosted login page, CDN) and needs no verification. Out of scope is never accessed, including nested paths, and takes precedence over Accessible. By default only Targets are reachable. |
| Private applications | Configure the VPC, subnets and a security group that allows outbound traffic to the targets. |
| Credentials | Username and password, or references to AWS Secrets Manager or a Lambda credential vendor. Use a typical-user account, never production admin credentials. |
| Service role and logs | The IAM service role must reach VPC resources and CloudWatch Logs. Run logs go to the chosen log group, or to a new one with the /aws/securityagent prefix. |
| Cost control | Billing is by task hours (agent work across parallel tasks, not wall-clock time). You can set a maximum of at least 20 hours; when it is reached, the run completes and keeps the findings already discovered. |
AWS recommends running penetration tests against pre-production environments. The agent uses minimal-impact payloads and velocity guardrails, but it still adds traffic and can trigger your monitoring alarms. The default quota is 5 concurrent penetration test runs per account per Region (adjustable).
Reading findings and reports:
- Run summary: status, duration, an application overview, the discovered endpoints (coverage), and findings by severity and risk type. The penetration test logs record every action the agent took.
- Severity (Critical, High, Medium, Low, Informational, with a CVSS breakdown) says how bad a flaw is. Agent confidence (High, Medium, Low) says how sure the agent is. By default only High-confidence findings are shown. Turn off Hiding unverified findings to see the rest.
- Each finding carries a description, impact, steps to reproduce, the evidence trail ("Trace actions & logs") and, for confirmed vulnerabilities, a downloadable verification script.
- You can edit a finding (severity, risk score, status). With Findings Personalization (on by default), your edits, including marking a finding FALSE_POSITIVE, tune how similar findings are rated on later runs.
Remediation loop:
Remediation pull requests require an administrator to enable code remediation for the connected repository, and the repository must be included in the test configuration. After deploying a fix, revalidate the finding to confirm it is no longer exploitable, and schedule a follow-up test to catch anything the change introduced.
Where Security Agent fits with the services from 5.2.4 and 4.2.3:
| Finding type | Service | Where you act on it |
|---|---|---|
| Malicious or anomalous activity (crypto mining, known-bad IPs, credential misuse) | GuardDuty | Security Hub, or EventBridge to Lambda or SSM for containment |
| Known CVEs in EC2 packages, ECR images, Lambda code | Inspector | Patch or rebuild (SSM Patch Manager, new image) |
| Sensitive data (PII) in S3 | Macie | Restrict access, move or encrypt the data |
| Resource misconfiguration or drift | Config | Config remediation with an SSM Automation runbook |
| Best-practice control failures across accounts | Security Hub CSPM | Automation rules and EventBridge (see 5.2.4) |
| Exploitable flaws in your own application (SQL injection, XSS, IDOR, SSRF), and design or code gaps against your standards | Security Agent | Its web application; fix through pull requests; revalidate |
Security Agent findings are not part of the Security Hub pipeline. The unified Security Hub lists its AWS sources as Security Hub CSPM, GuardDuty, Inspector, Macie and IAM Access Analyzer, and the Security Agent FAQ states that it does not integrate with existing security tools (SIEM, vulnerability management) or CI/CD pipelines. Its API calls, such as CreatePentest and ListFindings, are recorded in CloudTrail with the caller identity and source IP address, which is where you answer "who created or started this test?"
⚠️ Exam Trap: Security Agent does not replace the detective services. A clean Inspector scan does not mean the application is safe: IDOR and business-logic flaws have no CVE. A clean Security Agent test does not detect a compromised instance either; that is GuardDuty's job. Also watch for the scope trap: a domain you do not own (a third-party login page) belongs in Accessible, never in Target.
Reflection Question: A team runs its first Security Agent penetration test against staging. The run finishes with two findings shown, the logs mention several other candidates, and the login page is hosted by a SaaS identity provider. What would you check to see all candidate findings? How should the identity provider's domain be classified? What sequence of actions takes the Critical finding from report to verified fix?
