AWS Security Agent, explained: what it does, how to deploy it, and how it compares to a pen test

For most of its history, the penetration test has been a periodic event: a firm is booked, spends a couple of weeks, and hands back a report, once or twice a year, while your developers ship dozens of releases in between. AWS Security Agent sets out to change that rhythm by putting an autonomous agent where the quarterly pen test used to be.

It is a genuinely capable service and a signal of where the market is heading. It also answers a narrower question than the branding implies, and understanding which question is the difference between deploying it well and mistaking it for something it is not.

What it actually is

AWS Security Agent is one of AWS's "frontier agents," autonomous systems announced at re:Invent 2025 that work independently, run for hours without supervision, and scale across concurrent tasks. On-demand penetration testing reached general availability on 31 March 2026. Since the New York summit, the agent has been folded into a wider platform AWS calls Continuum, which wraps continuous threat modelling, code-vulnerability monitoring and automated remediation around the same core.

It does four things across the lifecycle. Design security review reads architecture documents against security requirements you define. Code security review scans pull requests in connected repositories. On-demand penetration testing runs multi-step attack scenarios against a live, verified target. And remediation closes the loop with validated findings, exploit paths and remediation pull requests, then revalidates that a fix actually worked.

The framing that matters: this is an application-security service. It reasons over your design, code and running application to find vulnerabilities in the software you build. It tests the OWASP Top 10 and, notably, business-logic flaws that signature-based scanners miss, because it reasons about application context. That context-awareness is the real advance over traditional scanners.

Where and how you deploy it

Deployment is more structured than "point it at a URL," and the structure is also your safety model. The service uses a three-layer hierarchy. At the top is the Application, the per-region configuration, created once. Inside it you create Agent Spaces, ideally one per application, each grouping the target domains, the IAM service role the agent assumes, and any VPC configuration for private apps. Beneath that is the Target Domain, a domain you have proven you control.

That domain-verification step is the linchpin and is not optional. Before the agent tests anything, you verify ownership by DNS TXT record or an HTTP route. For a Route 53 domain in the same account it is one click; elsewhere you add the TXT record yourself. The agent only runs against verified domains, which is what stops anyone using your account to point autonomous attack traffic at systems you do not own.

From there you configure per Agent Space: VPC access for private apps, CloudWatch logging, Secrets Manager or Lambda for test credentials, and an S3 bucket for extra context. Code review is wired up by connecting a repository, currently GitHub.

The reach is not limited to AWS. The control plane, your account, billing and identity, lives in AWS, but the target can run in AWS, Azure, GCP, hybrid, or on-premises. For a multicloud estate that means one consolidated pen-testing capability instead of one per provider.

You can drive it three ways. The console gives guided, human-in-the-loop setup for first runs and review. The API and CLI (create-pentest, start-pentest-job, list-findings) wire a test into CI/CD so a release triggers one. The AWS Labs MCP server exposes every operation to an MCP-compatible agent, so an autonomous workflow can scan code, run a pen test and apply fixes. That last option is powerful and the one to treat with the most care.

What it costs

Pricing is consumption-based and aimed squarely at the ROI conversation against manual testing. On-demand pen testing runs at roughly $50 per task-hour across the cumulative time of parallel tasks. A typical full evaluation of up to around 24 hours lands near $1,200. Against a human engagement in the thousands over weeks, the headline economics are stark, which is the point.

Two recent additions matter: budget controls, so you cap spend rather than discover the bill afterwards, and finding revalidation, so you confirm a fix resolved a vulnerability without paying for a full fresh run. Both signal a service being hardened for routine operation.

Think in cost-per-coverage over time, not "cheaper than a pen test" in isolation. The economics work when you want frequent, broad testing across a portfolio on every release. They work less well as a one-off, where a scoped human test may give more actionable depth for comparable money.

How it compares to a human pen test

The comparison is not "which is better," it is "which question are you answering."

The agent is superb at breadth and frequency: it can test your whole application estate on every release and catch the common classes and regressions that slip through between annual tests, fast and cheap. A skilled human tester remains better at the creative, chained, deeply context-dependent findings, the business-logic abuse that only makes sense once you understand what the application is for, and the judgement to say which finding will actually hurt you. And for compliance, a certified human test carries an accountability and sign-off that an autonomous run does not yet replace, which auditors in many regimes still require.

So it is a division of labour, not a replacement: the agent as the continuous layer, the human test as the periodic deep dive. Used that way, the agent frees the human tester to spend their limited, expensive time on the problems that need a human, instead of re-checking the OWASP Top 10 for the tenth time.

The limitations worth stating plainly

It tests applications, not your defensive controls. It answers "is my app exploitable," not "did my detection and response catch an attacker." Different question, different tooling.

Autonomous pen testing is still a nascent category. Its clean result means "no common exploitable issues found by an automated agent," not "this application is secure."

Compliance often still needs a human, signed and certified.

Authorisation is your responsibility. The verification model enforces testing only what you own, so you must be certain of your authority, especially for shared or multi-tenant apps.

The MCP path adds attack surface. AWS itself notes custom MCP connections can introduce prompt-injection risk, and anyone with access to the connected data sources inherits reach. Agentic convenience and agentic risk arrive together.

And it is native to AWS. The multicloud target reach is real, but billing and identity anchor you to AWS, and Continuum's direction is to absorb more of the lifecycle under one platform. A genuine convenience and a quiet lock-in at once, worth weighing deliberately.

Where it is heading

The standalone agent is being subsumed into AWS Continuum, a broader AI-native platform pairing pen testing and code review with continuous threat modelling and automated patching, positioned to shift security scanning as early into development as possible. The budget-control and revalidation additions show a service tuned for continuous, cost-governed use. AWS has a genuine lead; at the time of writing no other hyperscaler offers an equivalent autonomous pen-testing capability. That lead will not last, so the strategic question is less "should I use this one" and more "how do I build a testing programme that uses autonomous coverage well without depending on a single vendor's version of it."

The one distinction to hold onto

AWS Security Agent tests whether your applications are exploitable. It does not tell you whether your defences work: whether your EDR caught the technique, whether your SIEM alerted, whether your segmentation held. That is the job of breach and attack simulation and adversary emulation, a different question entirely, and one an application pen-testing agent does not answer. A mature programme runs both: the agent to find the holes in what you build, and controls validation to prove that what you deployed to defend it actually fires. Confuse the two and you will have tested one layer thoroughly while assuming the other, which is precisely the gap a real attacker looks for.

The full version, with high-level and low-level design diagrams and the deployment sequence, is here: AWS Security Agent, explained.

Saleem Yousaf is a Cloud and Cyber Security Architect. He is the Founder of BreachForge, a breach and attack simulation platform, and Director at Cyber Spartans Ltd. He works across AWS and Azure, securing UK government, critical national infrastructure, and global enterprise. Website: saleemyousaf.co.uk. Consultancy: cyberspartans.co.uk.