Who Pentests the AI Pentester? Securing AWS Security Agent First

Xander De Visch — Fri, 09 Oct 2026 09:47:47 +0000

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

Using Claude on AWS: Why Your Integration Choice Matters

Xander De Visch — Thu, 03 Sep 2026 17:38:29 +0000

AWS customers now have two ways to use Claude with AWS: Claude Platform on AWS and Claude in Amazon Bedrock.

At first glance, they can look very similar. Both involve AWS, both can use AWS identity and billing, and both give teams access to Claude models. But from a security architecture point of view, they are not the same thing. The difference is not really about the model. It is about the trust boundary.

When I look at a GenAI workload from a security perspective, I do not start with the model name. I start with a simpler question:

Who receives and processes the prompt?

That question matters because with generative AI, the prompt is often the data. It might contain internal documents, source code, customer context, financial information, architecture details, incident notes, or other sensitive business information. So before talking about features, latency, or developer experience, I want to understand where that data goes and which party operates the platform that processes it.

This is where Claude Platform on AWS and Amazon Bedrock differ. Claude Platform on AWS gives AWS customers access to Anthropic's native Claude platform experience through AWS, including the Claude Console, native API behavior, and faster access to certain Claude platform features. But the platform is operated by Anthropic. Amazon Bedrock is different: it is AWS's managed foundation model service. Claude is available inside Bedrock, but the service boundary, governance model, and operating responsibility sit with AWS.

That does not make one option automatically right and the other wrong. It means the security review is different.

"Available Through AWS" Is Not the Same as "Operated by AWS"

If a team says, "We are using Claude through AWS," that can mean two different things. It can mean they are using Claude Platform on AWS, where AWS provides integration points such as account access, billing, and familiar controls, but Anthropic operates the Claude platform experience. Or it can mean they are using Claude through Amazon Bedrock, where Claude is consumed through the AWS-managed Bedrock service.

From a security review perspective, those are very different answers. For Claude Platform on AWS, the review needs to include Anthropic as a platform operator and data processor. That means looking at Anthropic's terms, privacy commitments, retention behavior, support model, and third-party risk posture. For Bedrock, the review fits more naturally into the existing AWS governance model. If your organization already uses AWS Organizations, IAM, CloudTrail, CloudWatch, VPC endpoints, central security accounts, and AWS compliance evidence, Bedrock aligns more directly with that operating model.

Data Privacy, Compliance, and Residency

For me, the privacy discussion is where this comparison becomes very practical. With Claude Platform on AWS, prompts and completions are processed by Anthropic. That means your data crosses a third-party platform boundary. For low-risk experimentation, public content, or workloads where Anthropic has already been approved as a processor, that may be acceptable. But for confidential, regulated, customer-owned, or highly sensitive data, I would not treat this as a small implementation detail. Legal, procurement, privacy, and security teams should all understand the operating model before production usage.

With Amazon Bedrock, AWS is the operating party for the service, and the model provider does not receive access to customer prompts and completions through the Bedrock service model. That makes Bedrock the more natural starting point when the requirement is AWS-operated inference or AWS as the sole data processor.

Compliance is often where this becomes less theoretical. Claude Platform on AWS is a third-party offering, so it should not automatically be treated the same as an AWS-operated service for audit evidence, compliance scope, or regulatory approval. Amazon Bedrock fits more directly into AWS compliance programs where applicable. For organizations in financial services, healthcare, public sector, or other regulated environments, that can make a major difference.

Data residency still needs design in both cases. With Claude Platform on AWS, a workspace being tied to an AWS Region does not automatically answer every residency question. Teams still need to understand where inference runs and how geography is enforced. With Bedrock, the Regional AWS service model is more familiar for AWS teams, but the full workload still matters: logging destinations, S3 buckets, CloudWatch log groups, backups, and downstream services can all affect where data ends up.

Logging Needs Intentional Design

Logging deserves its own attention. It is tempting to say "log everything" for security, but with AI workloads that can backfire. If prompts and outputs are logged, those logs may contain the same sensitive data as the original request.

That means log buckets and log groups may become sensitive data stores. They need encryption, access control, retention policies, and monitoring that match the classification of the data being processed. More logging is not automatically better security. Intentional logging is.

My Decision Rule

If I had to reduce the choice to one starting point, I would use data classification.

For public content, early experimentation, internal enablement, or teams that need the newest Anthropic-native capabilities quickly, Claude Platform on AWS can be a strong option. The native platform experience and feature velocity are real advantages. For confidential, regulated, customer-owned, or centrally governed enterprise workloads, I would usually start with Amazon Bedrock. It gives you the AWS-operated service boundary, AWS-native governance, and a cleaner path for organizations that already manage cloud risk through AWS controls.

So the trade-off is not simply innovation versus security. It is more specific than that:

native Claude platform velocity versus AWS-native governance depth.

I would consider Claude Platform on AWS when the team needs the native Claude platform experience, the data classification allows Anthropic as a processor, and the organization is comfortable completing the required third-party risk review. I would start with Amazon Bedrock when AWS-operated inference is required, AWS must be the sole data processor, the workload is regulated or highly confidential, or the organization wants GenAI workloads to stay inside its existing AWS governance model.

Both options can be valid. But they are not equivalent from a security, compliance, and data privacy perspective.

The model may be Claude in both cases. The risk decision is not the same.

DEV Community: Xander De Visch