For most of its history, the penetration test has been a periodic event: a specialist 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 exactly which question is the difference between deploying it well and mistaking it for something it is not.
This is a practitioner's walk through the service: what it actually does, where and how you deploy it, what it costs, where it stops, and where it is going, with high-level and low-level designs so you can see the flows. Then an honest comparison to a human penetration test, because the two are complementary, not interchangeable.
What AWS Security Agent actually is
AWS Security Agent is one of AWS's "frontier agents," a class of autonomous systems announced at re:Invent 2025 that work independently towards a goal, run for hours without supervision, and scale across many concurrent tasks. Its on-demand penetration testing capability 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.
Underneath the branding, it does four related things across the development lifecycle. It performs design security review, reading architecture documents against a set of security requirements you define. It performs code security review, scanning pull requests in connected repositories for vulnerabilities and policy violations. It performs on-demand penetration testing, running multi-step attack scenarios against a live, verified target to find exploitable flaws. And it closes the loop with remediation, returning validated findings with exploit paths and, where possible, opening remediation pull requests, then revalidating that a fix actually resolved the issue.
The important framing: this is an application-security service. It reasons over your design, your code, and your running application to find vulnerabilities in the software you build and operate. It tests against the OWASP Top 10 and, notably, business-logic flaws that pattern-based scanners miss, because the agent reasons about application context rather than matching signatures. That context-awareness is the real advance over traditional static and dynamic scanners.
Where and how you deploy it
Deployment is more structured than "point it at a URL," and the structure is worth understanding because it is also your safety model. The service uses a three-layer resource hierarchy, and each layer exists to keep testing scoped and authorised.
At the top sits the Application, which is the per-region configuration of the service, created once when you first set it up in the console. Inside it you create one or more Agent Spaces. An Agent Space is a logical container, ideally one per application you want to test, that groups the things a test needs: the target domains, the IAM service role the agent assumes, and any VPC configuration for reaching private applications. Beneath that is the Target Domain, a domain you have proven you control and are therefore authorised to test.
That domain-verification step is the linchpin of the whole safety model, and it is not optional. Before the agent will test anything, you verify ownership of the target domain either by adding a DNS TXT record or by serving an HTTP verification route. For a Route 53 domain in the same account, this is one click; for a domain on another DNS provider, you copy a token and add the TXT record yourself. The agent will only run against verified domains, which is the mechanism that stops it, and stops anyone using your account, from pointing autonomous attack traffic at systems you do not own.
From there you configure the optional pieces per Agent Space: VPC, subnet and security-group access so the agent can reach a private application; CloudWatch logging so every test run is recorded; AWS Secrets Manager or a Lambda function to supply test credentials for authenticated testing; and an S3 bucket to hand the agent extra application context. Code review is wired up separately by connecting a repository, which at present means GitHub, so the agent can comment on pull requests and open remediation PRs.
Crucially, the reach is not limited to AWS. Although the control plane, your account, billing and identity, lives in AWS, the target can be an application running in AWS, in Azure or GCP, in a hybrid setup, or on-premises. For an organisation running a multicloud estate, that means one consolidated pen-testing capability rather than one per provider, which is a genuine operational advantage.
Put together, a typical deployment looks like this. The agent sits in the account control plane, driven from the console, the API or the MCP server, holding its IAM role, test credentials and logging, and reaching a verified target: here, an ordinary internet-facing three-tier application spread across two availability zones. The point of the diagram is what the agent touches and what it does not. It reaches the running application to test it and the repository to review code, and it stays clear of the request path and the data tier that a controls-validation exercise would exercise instead.
Three ways to run it, matched to three needs. The console gives a guided, human-in-the-loop setup, ideal for your first runs and for reviewing findings. The API and CLI, with operations like create-pentest, start-pentest-job and list-findings, are how you wire a test into a CI/CD pipeline so a release can trigger one. And the AWS Labs MCP server exposes the full operation set to any MCP-compatible agent, which is how you let an autonomous workflow scan code, run a pen test and apply fixes without a human driving each step. That last option is powerful and, as I will come to, the one to treat with the most care.
What it costs
Pricing is consumption-based and, deliberately, aimed at making the ROI conversation against manual testing unavoidable. On-demand penetration testing is billed at roughly $50 per task-hour, measured across the cumulative time of the parallel testing tasks a run spins up. In practice, a typical full evaluation running up to around 24 hours costs on the order of $1,200. Against a human engagement that runs into the thousands and takes weeks, the headline economics are stark, and that is the point AWS is making.
Two recent additions matter for controlling that spend. AWS added budget controls, so security teams can cap what a test is allowed to consume rather than discovering the bill afterwards, and finding revalidation, so you can efficiently confirm a remediated vulnerability is actually resolved without paying for a fresh full run. Both address real gaps that early users hit, and both signal a service being hardened for routine operational use rather than experimentation.
The honest way to think about cost is not "cheaper than a pen test" in isolation, but cost-per-coverage over time. The agent's economics make sense when you want frequent, broad testing across a portfolio, running on every significant release. They make less sense as a one-off, where a scoped human test may give you more actionable depth for comparable money.
How it compares to a human penetration test
This is where clear thinking matters most, because the two are easy to conflate and genuinely different in what they deliver. The comparison is not "which is better," it is "which question are you answering."
| Dimension | AWS Security Agent | Human penetration test |
|---|---|---|
| Cadence | On demand, every release, hours to complete | Periodic, weeks to schedule and run |
| Coverage | Broad and consistent: OWASP Top 10 and business-logic flaws, across a whole portfolio | Deep and creative: chained exploits, novel logic abuse, judgement about what matters |
| Context | Reasons over design, code and behaviour together | Reasons over the business, the people and the intent behind the system |
| Cost | ~$50 per task-hour, ~$1,200 per full run | Thousands per engagement |
| Assurance | Fast, machine-validated findings | Signed, accountable, often required for audits and compliance |
| Best at | Continuous coverage in the gaps between human tests | The subtle, high-impact findings a machine still misses |
The pattern that emerges is a division of labour rather than a replacement. The agent is superb at breadth and frequency: it can test your entire application estate on every release and catch the regressions and common classes that would otherwise slip through between annual tests. 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 of a hundred findings is the one that 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 will still require.
The right model for most organisations is the agent as the continuous layer and the human test as the periodic deep dive, each doing what it is best at. Used that way, the agent does not devalue the human test; it 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
A fair assessment has to name the boundaries, and there are several that matter for how you deploy and rely on it.
First, and most important for a security programme: it tests applications, not your defensive controls. It answers "is my application exploitable," not "did my detection and response actually catch an attacker." Those are different assurance questions requiring different tooling, and I will come back to that distinction because it is the one most likely to cause a false sense of coverage.
Second, autonomous penetration testing is still a nascent category. It outperforms traditional scanners by understanding context, but it is early, and it will miss classes of issue that a good human finds. Treat its clean result as "no common exploitable issues found by an automated agent," not as "this application is secure."
Third, compliance often still needs a human. Many audit and regulatory regimes require a penetration test conducted and signed by certified professionals. The agent supplements that obligation; in most regimes it does not currently satisfy it on its own.
Fourth, authorisation is your responsibility. The domain-verification model enforces that you can only test what you own, which is exactly right, but the corollary is that you must be certain of your authority to test a target, especially for applications shared across teams or tenants.
Fifth, the MCP path adds attack surface. Letting an autonomous agent drive the service via the MCP server is powerful, but AWS itself notes that custom MCP server connections can introduce prompt-injection risk, and that anyone with access to the connected data sources inherits reach into the workflow. Agentic convenience and agentic risk arrive together.
Sixth, and more strategic, it is native to AWS. The multicloud target reach is real, but the control plane, billing and identity anchor you to AWS, and Continuum's direction is to absorb more of the testing-and-remediation lifecycle under one provider's platform. That is a legitimate convenience and a quiet form of lock-in at the same time, and it is worth weighing deliberately rather than by default.
Where it is heading
The roadmap signal is clear from the moves AWS has already made. The standalone agent is being subsumed into AWS Continuum, a broader AI-native security platform that pairs the pen-testing and code-review capabilities with continuous threat modelling and automated patching, positioned to shift the majority of security scanning, vulnerability management and remediation as early into the development process as possible. The recent budget-control and revalidation additions show a service being tuned for continuous, cost-governed operation rather than novelty.
The broader trajectory is the one to plan around: security testing is moving towards autonomous, agentic and continuous, priced to displace manual effort where the work is repeatable. AWS has a genuine lead here; at the time of writing no other hyperscaler offers an equivalent autonomous pen-testing capability. That lead will not last, and the sensible assumption is that this becomes a standard platform capability across providers, which makes the strategic question less "should I use this one" and more "how do I build a testing programme that uses autonomous coverage well without becoming dependent on a single vendor's version of it."
The honest summary, and where it leaves your programme
AWS Security Agent is a strong, genuinely useful service that does exactly what it says: autonomous, context-aware application penetration testing and code review, fast, multicloud in reach, and priced to run continuously. Deploy it as the continuous application-testing layer, wire it into CI/CD, set budget caps, verify your domains, and treat the MCP integration with the caution any autonomous, credential-bearing workflow deserves. Keep a periodic human penetration test for depth and for the compliance sign-off it does not replace.
But hold onto the one distinction that the branding blurs. This tool 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, however capable, 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.
If you want help placing autonomous testing and controls validation correctly in your security programme, across AWS, Azure and beyond, that is the kind of work I do through Cyber Spartans.