AWS Security Agent reached general availability on 31 March 2026 as an autonomous, on-demand penetration testing service priced at $50 per task-hour, metered per second, per the AWS Security Blog. It combines static application security testing (SAST), dynamic application security testing (DAST), and active exploitation into a single context-aware agent that ingests your source code, architecture diagrams, API specifications, and threat models, then chains findings into multi-step attack paths. That is a real capability, and it changes how often teams can test. It does not, on its own, change what an independent third party cloud penetration test is for.
This post is the Stingrai team's decision guide for the one question buyers keep asking since the launch: can we cancel the third party test now that the cloud provider ships an autonomous pentester? The short answer is no, and this guide explains exactly where the agent is strong, where it stops, and how the two fit together. It is accurate as of July 2026 and refreshed quarterly. Every product claim below is attributed to AWS's own documentation, and every framework rule is attributed to its standard.
The direct answer
No, AWS Security Agent does not replace an independent third party cloud penetration test, and by itself it is not the artifact an auditor is looking for. It is complementary velocity tooling, not a substitute for independent assurance. Three facts drive that conclusion, and none of them is a knock on the tool:
A tool you run yourself is a self-assessment. Independence of assurance is a property of who runs the test, not how clever the automation is. AWS Security Agent is operated by you or by AWS on your behalf, so it does not carry the organizational independence that buyers, customers, and card-data auditors ask for.
It is an application security testing agent. AWS describes it as combining SAST, DAST, and penetration testing of your application, starting from the OWASP Top 10 and adapting to your app's context, per the AWS Security Agent FAQs. A human cloud penetration test also covers the control plane and identity: over-permissioned roles, privilege escalation, cross-account trust, and segmentation.
AWS makes no compliance-acceptance claim. Nothing in AWS's GA announcement, pricing page, or FAQ states that the agent's reports satisfy SOC 2, ISO 27001, or PCI DSS. That is not an oversight to work around; it reflects that acceptance depends on an independent, competent party standing behind the methodology, not on the export itself.
Keep both. Run AWS Security Agent for continuous coverage between engagements, and keep a scoped, independent third party test for the assurance that a self-operated tool cannot provide. The rest of this guide is the evidence behind that recommendation.
What AWS Security Agent actually does well
Being balanced about the agent is the point, so start with its genuine strengths. AWS Security Agent is not a repackaged vulnerability scanner.
It validates, not just flags. Rather than reporting a theoretical issue, the agent attempts to exploit discovered vulnerabilities to confirm they are real risks, and it reported a 92.5% success rate on CVE-Bench v2.0, per the AWS Security Blog. Exploit validation cuts the false-positive triage that eats analyst time.
It runs on demand and continuously. As a "frontier agent," it operates without a human babysitting each step, so a team can trigger a test on every meaningful release instead of once or twice a year. That compresses timelines from weeks to days.
It is multicloud. Testing operates across AWS, Azure, GCP, other cloud providers, and on-premises, per AWS's GA announcement. One agent covering a hybrid estate is a real convenience.
It is cheap per run. At $50 per task-hour, an average test of roughly 24 task-hours costs about $1,200, and new customers get a two-month free trial, per AWS's pricing page. That is a fraction of a manual engagement.
It produces a structured report. Findings ship with CVSS risk scores, application-specific severity ratings, reproduction steps, and remediation suggestions, downloadable as a PDF with an executive summary, scope and methodology, and findings detail, per AWS's reports announcement.
If your problem is "we only test once a year and releases outpace it," AWS Security Agent is a strong answer. That is a coverage-and-cadence problem, and the agent solves it well. The cancel-or-keep question is different, because a third party test solves an assurance problem, and those are not the same thing.
The fit and gap: AWS Security Agent vs an independent third party test
The two are not competing for the same job. This matrix maps six dimensions buyers care about.
Dimension | AWS Security Agent | Independent third party cloud pentest |
|---|---|---|
Independence of assurance | Self-assessment: a tool you or AWS operate on your behalf | Organizationally independent from your build and run teams, the independence PCI DSS and buyers expect |
Scope: control plane vs app layer | Application security testing (SAST, DAST, exploitation), OWASP Top 10 baseline | App layer plus the control plane: IAM privilege escalation, cross-account trust, over-permissioned roles, segmentation |
Business-logic and authorization depth | Chains findings and validates exploitability against the app | Purpose-built to hunt IDOR, broken authorization, and business-logic flaws unique to your app's rules |
Auditor-evidence acceptance | Structured PDF; AWS makes no SOC 2, ISO 27001, or PCI DSS acceptance claim | A report a qualified, independent tester wrote and can defend, mapped to the framework's control text |
Cross-cloud coverage | Multicloud by design: AWS, Azure, GCP, other clouds, on-premises | Scoped to your estate; humans reason about cross-cloud identity federation and trust |
Objective-based red teaming | Not an adversary emulation; AWS policy gates red team, C2, and phishing behind approval | Objective-based red teaming: social engineering, assumed breach, lateral movement toward a defined goal |
AWS Security Agent clearly wins on cadence, cost, and cross-cloud reach. The independent test wins on the five things a self-operated tool structurally cannot provide. The next sections walk each gap.
Independence of assurance
Independence is not about tool quality; it is about who is standing behind the result. When your own team or your cloud vendor's tool grades the security of workloads you own, that is a self-assessment. It is useful, but it is not the independent third party attestation your enterprise customers request in a security questionnaire, and it is not what a card-data auditor treats as external validation. PCI DSS v4.0.1 Requirement 11.4 is explicit that the tester must have organizational independence from the systems being tested; the tester need not be a QSA, but they cannot be the party responsible for managing or developing the environment under test. A tool operated by the app owner does not by itself establish that separation for the external assurance buyers ask for.
Control-plane and IAM depth
AWS Security Agent is framed by AWS as application security testing. The most damaging cloud breaches often start below the application: an over-permissioned role, a public snapshot, a trust policy that lets one account assume into another, or a segmentation control that does not actually segment. That is the terrain of a human cloud IAM penetration test, and it is why teams still need a tester who models privilege escalation and cross-account trust paths, not only the app's request and response surface. Tooling that starts from the OWASP Top 10 is aimed at the application; the control plane needs its own scoped engagement, which is exactly what a cloud penetration test scoped for SOC 2 Type 2 on AWS is built to cover.
Business-logic and authorization depth
Automated agents have become good at chaining known and discoverable classes, and AWS Security Agent's exploit validation is a real step up from scanning. The hardest class for any automated approach is still the flaw that only exists because of your application's specific rules: an object reference that should be scoped to one tenant but is not, an authorization check that passes for a role it should reject, a multi-step workflow that can be driven out of order to move money or escalate access. This is precisely the class our autonomous web-application agent, Snipe, was built to hunt. Snipe is custom-trained on more than 6,000 HackerOne Hacktivity disclosure reports plus skills distilled from senior Stingrai pentesters, and it targets IDOR, broken authorization, and business-logic flaws directly, then senior testers validate and extend what it finds. That combination goes after your bespoke authorization model, which is where generic application coverage is thinnest. You can read how that works on our web application penetration testing service.
Auditor-evidence acceptance
Auditors do not accept or reject a test based on whether AI ran it. They evaluate the report: a documented, industry-accepted methodology, a competent and independent tester behind it, scope that matches the audited environment, and evidence quality an examiner can trace. For SOC 2, penetration testing is the evidence auditors expect under the AICPA Trust Services Criteria, and for a Type 2 report the test has to fall inside the observation period. ISO 27001:2022 points auditors at Annex A 8.8 and A.8.29. PCI DSS 4.0.1 Requirement 11.4 is the strictest, mandating a documented methodology based on an industry-accepted approach such as NIST SP 800-115, internal and external testing on a defined cadence, and organizational independence. AWS Security Agent produces a structured PDF, which is a helpful input, but AWS makes no acceptance claim for any of these frameworks, and the methodology narrative plus the independent tester behind it are still what turn a findings export into audit-ready evidence. We cover this in depth in will an auditor accept an AI pentest.
Cross-cloud coverage and rules of engagement
Multicloud reach is a genuine AWS Security Agent strength, and for a hybrid estate it is convenient to point one agent at everything. Two caveats keep it in the complementary column. First, AWS's own penetration testing policy permits customer testing of listed services without prior approval but gates red team, blue team, purple team, Command and Control hosting, DDoS simulation, and phishing behind a Simulated Events request submitted at least two weeks in advance, which means adversary-style activity still needs deliberate scoping. Second, cross-cloud risk often lives in the seams between providers: federated identity, trust relationships, and inconsistent guardrails that a human tester reasons about end to end. Getting that scoping right is the whole subject of our guide to cloud penetration testing rules of engagement across AWS, Azure, and GCP.
Objective-based red teaming
An autonomous application pentester runs against the app. Objective-based red teaming asks a different question: given a goal, such as reaching a specific data store or a production admin path, can an adversary get there through any combination of people, process, cloud identity, and application weakness. That involves social engineering, assumed-breach starting positions, and lateral movement that no application-scoped agent performs, and that AWS's policy specifically gates behind approval. When the buyer's real question is "would we detect and stop a determined attacker," the answer comes from red teaming, not from a scan cadence. Where autonomous tooling and human testers each fit is the subject of our autonomous vs human pentesting scope split.
Will an auditor accept it?
By itself, a raw AWS Security Agent export is not the artifact most auditors treat as a completed penetration test, for the same reasons any tool-only output falls short: it does not carry a written methodology narrative, an independence attribution, or the human-authored analysis an examiner expects to see. That is not unique to AWS; it is true of every automated tester's raw output. The agent's PDF, with its scope and methodology section and validated findings, is a strong input to an audit-ready report, and a continuous agent can even demonstrate coverage across an entire SOC 2 observation period rather than a single point in time. The acceptance still hinges on a qualified, independent party owning the methodology and defending the result. Framed positively, AWS Security Agent supports your SOC 2, ISO 27001, and PCI DSS program as continuous coverage, and an independent third party test supplies the assurance layer that carries the evidence.
Keep or cancel: the decision
The decision is not either-or, and treating it that way is the mistake.
Run AWS Security Agent when you need:
Continuous application testing on every release, not once or twice a year.
Fast, cheap exploit-validated findings to catch regressions early.
Multicloud application coverage from a single tool.
A structured findings input your team can remediate against between engagements.
Keep an independent third party test when you need:
Independence of assurance for customers, security questionnaires, and card-data audits.
Control-plane and IAM depth: privilege escalation, cross-account trust, segmentation.
Bespoke business-logic and authorization testing against your app's specific rules.
Objective-based red teaming across people, process, and cloud identity.
An auditor-ready report a qualified, independent tester wrote and can defend.
The strongest 2026 posture combines them: let the agent carry continuous coverage, and let an independent team carry the depth and the assurance. That hybrid model is how continuous, AI-augmented PTaaS is meant to work, and it is why cloud-native tooling and independent testing sit in the same program rather than replacing one another. Related reading on where automated cloud tooling leaves gaps is in CNAPP blind spots in cloud penetration testing and, for AI-heavy stacks, AWS Bedrock penetration testing for AI infrastructure.
What this means for defenders
Do not cancel your third party test on the strength of a tool launch. You would be trading independent assurance for a self-assessment, and the questionnaire and the auditor will notice.
Adopt the agent for cadence, and say so. Continuous, exploit-validated application testing between engagements is a real maturity gain. Use it, and document it as continuous coverage in your compliance program.
Scope the human engagement where the tool is thin. Point your independent test at the control plane, IAM, bespoke authorization, and objective-based scenarios rather than duplicating the app scan the agent already runs.
Keep the methodology and independence with a named party. Whether autonomous tooling or a human does most of the testing, the artifact an auditor accepts needs a competent, independent tester behind it.
Stingrai, a CREST-accredited firm, runs exactly this hybrid: senior human pentesters for cloud control plane, IAM, and objective-based red teaming, and Snipe for autonomous, depth-focused web-application testing, so continuous coverage and independent assurance live in one program. See the full offensive security services, or pricing to scope an engagement.
Frequently asked questions
Does AWS Security Agent replace a third party cloud penetration test, and will an auditor accept it?
No. AWS Security Agent, which reached general availability on 31 March 2026 at $50 per task-hour, is strong autonomous application testing, but a tool you operate yourself is a self-assessment, not independent assurance. It focuses on application security testing rather than the control plane, and AWS makes no SOC 2, ISO 27001, or PCI DSS acceptance claim for its reports. An auditor still expects a documented methodology and a competent, independent tester behind the artifact, so the agent complements an independent third party test rather than replacing it.
What does AWS Security Agent actually do?
It combines SAST, DAST, and active exploitation into one context-aware agent that ingests source code, architecture diagrams, API specifications, and threat models, then attempts to exploit findings to confirm real risk, per the AWS Security Blog. It runs on demand and continuously across AWS, Azure, GCP, other clouds, and on-premises, and exports a PDF report with CVSS scores, reproduction steps, and remediation suggestions.
How much does AWS Security Agent cost?
AWS Security Agent is priced at $50 per task-hour, metered per second, per AWS's pricing page. AWS states an average test of roughly 24 task-hours costs about $1,200, and new customers receive a two-month free trial. Design review, code review, and threat modeling features were in preview and free at launch.
Is AWS Security Agent a substitute for a human cloud pentest of IAM and the control plane?
No. AWS frames it as application security testing that starts from the OWASP Top 10 and adapts to app context. The most damaging cloud breaches often start in the control plane: over-permissioned roles, cross-account trust, public snapshots, and segmentation that does not segment. Those require a human cloud IAM penetration test that models privilege escalation paths, which an application-scoped agent does not target.
Does AWS Security Agent satisfy PCI DSS penetration testing requirements?
Not by itself. PCI DSS v4.0.1 Requirement 11.4 requires a documented, industry-accepted methodology such as NIST SP 800-115, internal and external testing on a defined cadence, and a tester with organizational independence from the systems under test. The agent's validated findings are a useful input, but the methodology narrative and the independent tester behind the report are what an assessor evaluates, and AWS makes no PCI acceptance claim.
Can AWS Security Agent do red team or social engineering testing?
No. It is an application security testing agent, not an objective-based adversary emulation. AWS's own penetration testing policy gates red, blue, and purple team exercises, Command and Control hosting, DDoS simulation, and phishing behind a Simulated Events request submitted at least two weeks in advance. Objective-based red teaming across people, process, and cloud identity remains a human engagement.
Should we run both AWS Security Agent and an independent pentest?
Yes, and that is the recommended posture. Run AWS Security Agent for continuous, low-cost, exploit-validated application coverage on every release, and keep a scoped independent third party test for control-plane depth, bespoke authorization testing, objective-based red teaming, and auditor-ready evidence. The agent solves cadence; the independent test supplies assurance.
Where does Stingrai's Snipe fit against AWS Security Agent?
Snipe is Stingrai's autonomous web-application penetration testing agent, custom-trained on more than 6,000 HackerOne Hacktivity reports plus senior-pentester skills, and purpose-built to hunt IDOR, broken authorization, and business-logic flaws in your application, with AutoFix pull requests and PR-gating. It concentrates on the bespoke application authorization layer, while Stingrai's human pentesters cover cloud control plane, IAM, and objective-based red teaming. Together they provide the independence and depth that a self-operated tool cannot.
References
Amazon Web Services. AWS Security Agent: on-demand penetration testing now generally available. AWS Security Blog, 31 March 2026. https://aws.amazon.com/blogs/security/aws-security-agent-on-demand-penetration-testing-now-generally-available/. GA announcement detailing SAST plus DAST plus exploitation, CVE-Bench v2.0 result, pricing, and regions.
Amazon Web Services. AWS Security Agent on-demand penetration testing is now generally available. AWS What's New, March 2026. https://aws.amazon.com/about-aws/whats-new/2026/03/aws-security-agent-ondemand-penetration. GA notice listing capabilities, multicloud support, and available regions.
Amazon Web Services. AWS Security Agent now supports downloading penetration testing reports. AWS What's New, March 2026. https://aws.amazon.com/about-aws/whats-new/2026/03/aws-security-agent-generates-customizable. Details the PDF report format, executive summary, scope and methodology, and findings sections.
Amazon Web Services. AWS Security Agent Pricing. Accessed July 2026. https://aws.amazon.com/security-agent/pricing. Pay-as-you-go pricing at $50 per task-hour, average test cost, and the new-customer free trial.
Amazon Web Services. AWS Security Agent FAQs. Accessed July 2026. https://aws.amazon.com/security-agent/faqs/. States the agent starts from the OWASP Top 10, adapts to application context, and tests across cloud and on-premises environments.
Amazon Web Services. Penetration Testing (Customer Support Policy for Testing and Simulated Events). Accessed July 2026. https://aws.amazon.com/security/penetration-testing/. Lists services testable without approval and the simulated-events activities requiring prior authorization.
AICPA. Trust Services Criteria (2017, with revised points of focus 2022). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022. Control criteria SOC 2 examinations are performed against.
ISO/IEC. ISO/IEC 27001:2022, Information security management systems. https://www.iso.org/standard/27001. Annex A 8.8 and A.8.29 cover technical vulnerability management and security testing.
PCI Security Standards Council. PCI DSS v4.0.1. Published June 2024. https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1. Requirement 11.4 mandates documented methodology, internal and external testing, and tester independence.
NIST. SP 800-115, Technical Guide to Information Security Testing and Assessment. September 2008. https://csrc.nist.gov/pubs/sp/800/115/final. The industry-accepted testing methodology referenced by PCI DSS.
