Not affiliated with AWS
← Back to BlogRSS

AWS Security Agent Is GA. What It Does and Doesn't Do.

iamblast-radiusaws-securitycomparison

On March 31, 2026, AWS announced general availability of AWS Security Agent, an autonomous AI system that performs penetration testing on web applications. It chains SAST, DAST, and active exploitation into a single workflow, runs 24/7, generates validated findings with CVSS scores and reproduction steps, and even creates pull requests with suggested fixes.

This is a significant product. It addresses a real gap: most organizations can only afford to pentest a fraction of their applications, and they do it infrequently. AWS Security Agent makes application-layer security testing continuous and affordable.

But "penetration testing" means different things depending on what you're testing. AWS Security Agent tests your applications. It doesn't test your IAM permissions, your role trust policies, your credential chains, or the blast radius of your compute identities. Those are different problems with different tools.

This post examines what AWS Security Agent does, what early reviewers have found, and how it compares to what we're building at hackaws.cloud.

What AWS Security Agent does

AWS Security Agent is an application security testing tool. You give it a target URL, optionally connect your source code and documentation, and it autonomously probes the application for vulnerabilities. From the GA announcement:

Input: Web application URL, optional source code (GitHub integration), API specs, architecture docs, threat models, and authentication credentials for different user roles.

What it finds: Application-layer vulnerabilities: XSS, SQL injection, authentication bypasses, insecure API endpoints, session management flaws, access control issues. It validates findings by actively exploiting them rather than just flagging potential issues.

What makes it interesting: It chains findings together. AWS's example in the GA post shows a medium-severity stored XSS (CVSS 6.1) that enables session hijacking, which unlocks an admin config endpoint leaking database credentials (CVSS 9.8). Individual scanners flag the XSS and move on. Security Agent identifies the full chain and elevates the severity accordingly.

Output: Validated findings with CVSS scores, reproduction steps, business impact analysis, and auto-generated pull requests with code fixes. AWS reports an 80% success rate on CVE Bench v2.0 in unassisted testing, rising to 92.5% with guided scaffolding.

Pricing: $50 per task-hour, metered per second. A typical test runs about 24 task-hours (~$1,200). AWS estimates 70-90% savings compared to manual pentesting.

Scope: Multicloud and on-premises. Works against any web application reachable via URL or VPC connection.

What early reviewers found

AWS Security Agent has been available in preview since re:Invent 2025. Several practitioners have published their experiences.

Richard Fan's security research

Richard Fan published detailed security findings from testing the agent itself. His research uncovered several issues worth noting:

DNS confusion attack. By manipulating Route53 private hosted zones, the agent could be tricked into targeting domains the operator doesn't own. AWS fixed this in March 2026 with enhanced periodic verification.

Reverse shell to agent sandbox. Through aggressive link-following behavior, Fan demonstrated a chain from RCE to circumventing outbound firewall guardrails, privilege escalation via sudo misconfigurations, container escape via mounted Docker sockets, and extraction of IAM credentials from the EC2 metadata service. AWS classified this as within their documented threat model for isolated single-tenant environments.

Destructive testing behavior. The agent used DROP TABLE commands during initial SQL injection probes and accidentally destroyed /etc/crontab files during cleanup attempts. AWS implemented fixes to discourage deletion via attack methods.

Sensitive information disclosure. Discovered secrets (like user passwords) appeared unredacted in findings reports, broadening exposure beyond the vulnerability itself. AWS determined redaction is out of scope.

Fan also tested common defenses against the agent: User-Agent blocking was effective (the agent consistently identifies itself as "securityagent"), rate limiting was partially effective, but Cloudflare bot detection was bypassed in over 99% of requests, and robots.txt was ignored entirely.

Practitioner experiences

Rodell Lemit tested the preview against OWASP Juice Shop on EC2 and experienced repeated aborted and failed scans due to application crashes and Cloudflare interference. His conclusion: tools like this make a pentester's life easier, but they're "definitely a force multiplier. They handle the repetitive stuff so testers can spend more time on creative testing, digging into context, and chasing down things like business logic flaws."

Sena Yakut's walkthrough on AWS in Plain English found a roughly two-hour test time and recommended treating the agent as "a teammate, not a replacement." Yakut encountered VPC configuration issues that prevented the agent from reaching publicly available targets, though fresh configurations resolved the problem.

The consistent theme across reviews: useful for automating repetitive application testing, not yet a replacement for human judgment on business logic and complex attack chains.

What AWS Security Agent doesn't do

AWS Security Agent tests your applications from the outside in. It finds the XSS, the SQL injection, the broken access control. It answers the question: can an attacker break into this application?

It does not answer a different question: once an attacker has AWS credentials, what can they reach?

AWS Security Agent doesn't:

  • Map IAM blast radius. It doesn't enumerate which roles a compromised identity can assume, which secrets it can read, or which resources it can access.
  • Test lateral movement paths. It doesn't attempt sts:AssumeRole calls across accounts to discover trust chains. It doesn't follow credential chains from Secrets Manager access through to the databases those secrets unlock.
  • Assess privilege escalation within AWS. It doesn't check whether an IAM role can attach policies, create access keys, modify trust policies, or escalate to admin through any of the 34 known IAM privilege escalation techniques.
  • Probe resource-based policies. It doesn't test whether S3 buckets, SNS topics, SQS queues, or Lambda functions have overly permissive resource policies that expose them beyond their intended scope.
  • Build an attack graph of your AWS environment. It doesn't show you the full set of paths from a starting identity to every reachable resource.

These aren't gaps in AWS Security Agent. They're simply outside its scope. It's an application security tool, not an IAM security tool. The LexisNexis breach started with an application vulnerability (React2Shell) that Security Agent might well have caught. But the actual damage, 536 Redshift tables and 3.9 million records, came from the blast radius of the compromised ECS task role. The application was the door. The IAM permissions determined the damage.

What hackaws.cloud does

hackaws.cloud tests your AWS environment from the inside out. You give it a starting identity (an IAM role, IAM user, or SSO user) and it autonomously maps everything that identity can reach.

Input: A foothold identity in your AWS environment, scope accounts, exclusions, and which technique categories to enable.

What it finds: Lateral movement paths (role assumption chains across accounts), privilege escalation vectors (IAM policy manipulation, credential creation, trust policy modification), credential chains (secrets that unlock databases that contain more credentials), and overly permissive resource policies.

How it works: The agent starts from your foothold identity and systematically:

  1. Enumerates all IAM roles visible from the current identity
  2. Attempts AssumeRole on every reachable role, discovering trust chains
  3. Evaluates each identity's effective permissions against 34 privilege escalation techniques
  4. Executes confirmed privilege escalation paths (with guardrails and cleanup)
  5. Detects admin access per account and attempts cross-account pivots
  6. Repeats until no new paths are found (convergence)

Every discovery is recorded in a live attack graph. Every action is logged with full audit trail. Every change made during privilege escalation comes with a cleanup command.

Output: A live attack graph showing every lateral movement and privilege escalation path from your starting identity, with a full event log and cleanup instructions sorted by account.

What it doesn't do: hackaws.cloud doesn't test your web applications. It doesn't find XSS, SQL injection, or broken authentication in your application code. It operates at the AWS identity and access management layer, not the application layer.

Different layers, same environment

The distinction matters because real attacks cross both layers. The typical breach starts with an application vulnerability and escalates through IAM permissions:

Application vulnerability (XSS, SSRF, RCE, credential leak)
  -> Compromised compute identity (EC2 role, ECS task role, Lambda role)
    -> Lateral movement (AssumeRole chains, cross-account trust)
      -> Privilege escalation (policy manipulation, credential creation)
        -> Data access (S3, RDS, Secrets Manager, Redshift)

AWS Security Agent tests the first layer. hackaws.cloud tests everything below it. Neither tool covers the full chain alone.

AWS Security Agent hackaws.cloud
What it tests Web applications (URLs, APIs, source code) AWS IAM permissions and identity relationships
Starting point Target URL + optional source code AWS identity (IAM role, user, or SSO user)
Attack surface Application layer: XSS, SQLi, auth bypass, session mgmt IAM layer: role chains, privesc, resource policies, credential chains
Validation method Active exploitation of application vulnerabilities Active role assumption, privilege escalation, permission probing
Finding output CVSS-scored vulnerabilities with reproduction steps Attack graph with lateral movement paths and blast radius map
Remediation Auto-generated PRs with code fixes Cleanup commands for every change made during assessment
Cloud scope Multicloud (AWS, Azure, GCP, on-prem) AWS-only (deep)
What it misses IAM blast radius, lateral movement, privesc paths Application vulnerabilities, web exploits

The question each tool answers

When Scout24 reports that AWS Security Agent "identified a critical publicly exploitable issue that other approaches had not surfaced," that's the application security question: can someone break in?

When the 93 HackerOne reports we analyzed show SSRF after SSRF turning into full infrastructure access because nobody measured the blast radius of the compromised identity, that's the IAM security question: once they're in, what can they reach?

Both questions need answers. The Capital One breach wasn't caused by a missing application-layer test. It was caused by an IAM role whose blast radius encompassed 106 million customer records. The SSRF was the entry point. The IAM permissions were the payload.

AWS Security Agent could have found the SSRF. hackaws.cloud would have shown that the role attached to that instance could reach every S3 bucket in the environment, long before an attacker proved it.

Key takeaways

  • AWS Security Agent is a strong application security tool. It combines SAST, DAST, and active exploitation with vulnerability chaining and auto-remediation. For web application testing, it addresses a real gap in coverage and frequency.

  • It doesn't test your IAM blast radius. Application pentesting and IAM blast radius assessment are different disciplines with different tools. The application is the entry point. The IAM permissions determine the damage.

  • Early reviews show promise with caveats. Reviewers consistently describe it as a "force multiplier" rather than a replacement for human testers. Richard Fan's security research surfaced real issues around destructive testing behavior and agent-specific attack surface that AWS is actively addressing.

  • Real breaches cross both layers. The application vulnerability gets the attacker in. The overpermissioned IAM role gives them everything. Testing one layer without the other leaves a gap that attackers have been exploiting for years.

  • Continuous testing at both layers is now possible. AWS Security Agent makes application pentesting continuous and affordable. hackaws.cloud does the same for IAM blast radius assessment. The combination covers the full attack chain from initial access through infrastructure compromise.

Ready to map the other half of the attack chain? Sign up for hackaws.cloud and find out what an attacker could reach from your AWS identities, the part that starts where the application pentest ends.