Attacking the Agent Itself

Every other post in this series is built on my own hands-on testing: a vulnerable app I stood up myself, logs I downloaded from my own account, findings from pentests I actually ran. This post is different, and I want to say that plainly before anything else. I did not attack AWS Security Agent's own infrastructure, and I have no independent findings to report about it. What follows is a summary of what AWS itself publishes about the agent as its own attack surface, drawn only from its official documentation. Where AWS's own words are the source, I say so.

The agent is, by design, a system with real power. It executes code in a sandbox, sends requests to whatever application you point it at, reads source code, and runs with credentials scoped for the job. Any system with that much capability is worth asking "what happens if this goes wrong," so this post collects everything AWS documents about the answer.

AWS's Own Answer to "Can the Agent Itself Pose a Risk?"

AWS asks and answers this question directly in its own security guidance, under Security & Control:

"AWS Security Agent is instructed to discover security risks, but to do so using intentionally minimal impacting payloads (like extracting the SQL version instead of dropping a table when a SQL injection attack is discovered). AWS Security Agent is also confined to deterministic guardrails to prevent risky behavior like creating excessive load against the target application. While guardrails are in place, there could still be unintentional or non-obvious business logic interactions, therefore, we always recommend doing penetration testing against a pre-production environment." (Security Considerations for AWS Security Agent)

Two things stand out in that answer. First, AWS explicitly designs for minimal-impact exploitation, not maximum impact: the example it gives, extracting the SQL version string rather than dropping a table when it finds a SQL injection, is a deliberate choice about how the agent proves a vulnerability without needlessly damaging what it is testing. Second, AWS does not claim the guardrails are foolproof. The recommendation to test against pre-production environments is AWS telling you, in its own documentation, that "guardrails in place" is not the same thing as "nothing can go wrong." That is a more honest answer than a lot of vendors give, and it is worth taking at face value rather than reading past it.

The Guardrails AWS Documents

AWS's FAQ describes rate limiting and denial-of-service prevention as a built-in property of the agent, not an opt-in setting:

"AWS Security Agent has guardrails to prevent it from disrupting or taking down endpoints under test, including DOS. It has internal velocity controls to detect and handle unexpected traffic patterns." (Security Considerations for AWS Security Agent)

The same page describes the operational expectation directly: testing still increases traffic and can trigger monitoring alerts, and AWS's own recommendation is to run it only against pre-production environments for exactly that reason. If a run is causing problems, the documented remedy is that customers can stop an ongoing pentest themselves; the agent does not have a scheduling or throttling API of its own to pre-limit that traffic ahead of time.

Scope Enforcement: What Stops the Agent From Testing the Wrong Target

This is the part of the threat model that matters most if you are worried about the agent being pointed somewhere you did not intend, and AWS documents it as a network-level control, not just a policy:

"Endpoints that are specified as target URLs for pentesting will require DNS validation or HTTP validation as a measure of ownership. AWS Security Agent will ask the customer to add a TXT record to the endpoint's DNS or expose an HTTP Route returning validation string as proof of ownership. Only after demonstrating proof of ownership will the user be able to proceed with a pentest. Requests to URLs outside of the target and accessible URLs will be blocked by the network." (Security Considerations for AWS Security Agent)

The mechanics of ownership verification are documented separately, and there are three supported methods (Enable an application domain for penetration testing):

• DNS TXT record. AWS generates a token; you add it as a TXT record with your DNS provider. If the domain is registered in Route 53 under the same AWS account, this can happen automatically through one-click verification.
• HTTP route. You place a token AWS provides at a fixed path (.well-known/aws/securityagent-domain-verification.json) on your web server, and AWS Security Agent fetches it over HTTPS to confirm you control the server.
• Private VPC. Used specifically for private-VPC pentesting, this verifies that the domain resolves to an IP inside a private CIDR range, and the domain name configured must match the target endpoint's full domain name exactly.

Verifying a base domain automatically covers its subdomains for DNS TXT and HTTP route verification. AWS also documents an explicit exception path: if you are authorized to test an endpoint but genuinely cannot complete ownership verification, you can open a support case and request manual verification, with your business justification.

Beyond verification, AWS documents active monitoring for abuse: "AWS Security Agent continuously monitors requests and attempts to access URLs that are outside of the target URLs. If abuse is detected, such as attempting to use AWS Security Agent to conduct unauthorized testing on a third party endpoint, any ongoing pentests in the account will be terminated." That is a second, independent layer behind the initial verification: even after a domain is verified, out-of-scope requests are watched for and can end the run.

Credential and Data Handling

The agent only authenticates to a target system during penetration testing, and AWS documents exactly how: "The AWS Security Agent accepts credentials in the form of static username and password credentials (stored in Secrets Manager), or a credential vendor (as a Lambda Function) as configuration before starting the pen test." AWS's own recommendation is to create credentials scoped specifically for the pentest rather than reusing broader ones.

On data protection, AWS documents encryption at rest for everything the service touches: design documents and code you provide (AES-256), security findings and vulnerability reports, configuration data, and audit logs, all encrypted using AWS-managed keys by default, with the option to bring your own customer-managed KMS key. Data in transit is TLS 1.2 or higher across API calls, console access, repository connections, and agent-to-service communication. If you delete data from the service, AWS documents that it becomes inaccessible immediately and is fully deleted from AWS Security Agent's systems within 30 days. (Data protection in AWS Security Agent)

What This Post Cannot Tell You

I want to be direct about the limits of an AWS-documentation-only summary. AWS's public docs describe the guardrails that exist and the design intent behind them. They do not publish a history of specific security findings against the service, disclosed vulnerabilities, or incidents, so this post cannot tell you whether those controls have ever been tested by an outside researcher, bypassed, or fixed after the fact. If that kind of independent testing exists publicly somewhere, it is outside the scope of what I am willing to state as fact here, because I have not verified it myself and it is not part of AWS's own published record.

What I Take Away

AWS's own documentation describes a threat model with three real layers: minimal-impact-by-design exploitation, deterministic velocity and DoS guardrails, and network-enforced scope limited to domains you have proven you own, backed by active out-of-scope monitoring that can terminate a run. AWS also documents where its confidence stops: guardrails are not a guarantee against "unintentional or non-obvious business logic interactions," which is why AWS itself recommends pre-production targets.

None of that should stop you from using the agent. It should tell you what AWS is actually claiming, in AWS's own words, so you can decide how much of your own verification you want to do on top of it. That is the same standard the rest of this series holds AWS's product claims to; this post just could not add my own hands-on evidence to it.

The next post looks at the agent from the AWS side of the wire: what CloudTrail, Secrets Manager, and VPC Flow Logs reveal about the agent's own footprint in your account, in The Agent's AWS Footprint.