Letting an AI agent attack your app takes minutes to set up. Deciding what it can reach is the hard part.
Imagine an online shop that sells outdoor gear across Europe. Its developers ship to production every week, but its last external penetration test was eleven months ago. The application they tested is not the application they are running.
AWS Security Agent, now part of AWS Continuum, is built for that gap. You point it at your application, specialized AI agents run multi-step attacks, and you get validated findings with reproduction steps and a pull request with a fix. Pricing is $50 per task-hour, metered per second.
That pitch is easy to like. But every feature that makes it easier to point an AI attacker at your application is also a decision about what that attacker can reach. Here are the five decisions hiding in the setup wizard.
1. Scope: verify the narrowest domain you can
Before the agent attacks anything, AWS makes you prove you own the target, with a DNS TXT record, an HTTP file or a private VPC check. The catch is easy to miss: verifying a domain also covers all of its sub-domains. Verify example.com and your production www and api become valid targets for anyone who can start a test. Verify staging.example.com instead, and list sensitive paths such as payment and account deletion as out of scope.
2. Identity: the agent needs two sets of keys
The agent assumes an IAM service role in your account and logs in to your application. The default role the console creates can reach VPC resources, CloudWatch log groups, Secrets Manager and Lambda functions. For anything beyond a sandbox, write a scoped role with the documented external-ID trust policy, and give the agent a dedicated test user that only exists in staging. Since September 2026, you can check that login before the run starts.
3. Egress: the suggestion list is a trust decision
During a test, the agent can only reach target URLs and accessible URLs. The credential test now suggests every domain the login flow touched. It is tempting to accept them all, but AWS is clear about what that means: test data, including credentials, may be sent to every accessible URL. Keep the identity provider, drop the analytics domain.
4. Data: know where the agent does its thinking
Cross-Region inference is always on, and Service Control Policies or Control Tower controls do not affect it. From Ireland or Frankfurt, inference stays in the EU. From Mumbai, Singapore or São Paulo, it may run in any commercial AWS Region. Your Region choice is a compliance decision, not a latency one.
5. Impact: pre-production, with a budget
AWS recommends pre-production, because tests may modify data or disrupt services. Since August 2026, you can cap task-hours per test. A cap of 8 task-hours means a maximum bill of $400, and it also limits how long an autonomous attacker runs against your environment. Send every generated fix through normal code review, and watch the agent's API calls in CloudTrail like any other privileged identity.
The takeaway
AWS Security Agent turns penetration testing from a yearly event into something a team can run whenever it ships. But it is also a new, privileged identity in your account, with keys to your application and a list of places it is allowed to talk to. Configure it like one.
The full article walks through each decision in more depth, including the IAM trust policy, the cost math behind task-hours, and how revalidation closes the loop after a fix.
Read the full article on Towards AWS: Who Pentests the AI Pentester? Securing AWS Security Agent First
Top comments (0)