On this page · 12 sections
- What actually changed on 19 August 2026
- The floor, and why it is not a detail
- Task hours are not wall-clock hours, and that is the part teams get wrong
- Quotas will not save you
- What breaks, and how to tell if it is you
- The rebrand the documentation has not absorbed
- India-specific considerations
- What is still unknown
- What to do this week
- FAQ
- How eCorpIT can help
- References
Summary. On 19 August 2026 AWS announced budget controls and finding revalidation for AWS Security Agent, describing the new cap as "a preset value (for example, 20 or 30 hours), a custom value, or no limit at all". The user guide is narrower than that. It states plainly that "The smallest limit you can set is 20 hours" and that "A custom limit must be at least 20 hours". The AWS Price List API rates penetration testing at $50.00 per hour in all 9 regions that carry the usage type, unchanged across US East (N. Virginia), EU (Frankfurt) and Asia Pacific (Mumbai), in a price file published 6 July 2026. So the floor on a per-test budget cap is 20 task-hours, or $1,000. With the default quota of 5 concurrent penetration test runs per account per region, the smallest exposure a fully-parallel test window can be capped at is $5,000.
That is the number the announcement does not carry, and it is the number a security budget owner needs before turning the feature on.
What actually changed on 19 August 2026
Two capabilities landed together in the AWS What's New entry, which is also the first AWS communication to describe the product as "now part of AWS Continuum".
The first is the maximum task-hours limit. Before it, a penetration test ran until the agent decided it was finished, and AWS billed every second of agent work. Now you set a ceiling at creation time and the run stops when it reaches it, keeping every finding discovered up to that point and closing with a status of Completed rather than an error state.
The second is finding revalidation. After you deploy a fix, you select one or more findings from a completed run and Security Agent re-tests only those, returning Active if it reproduced the vulnerability and Resolved if it could not. The revalidation documentation is explicit that revalidation "does not rediscover new vulnerabilities or test other parts of your application", and that it runs as its own job with a run type of Revalidation.
Both are real improvements on what came before. Neither behaves the way a conventional cloud spending control behaves.
The floor, and why it is not a detail
The Create a penetration test page in the user guide gives the constraint twice, once in prose and once inside the configuration steps. Both readings agree: 20 hours is the minimum, and a custom value below 20 is not accepted.
Pair that with the rate. The AWS Price List API offer file for SecAgent, version 20260706202749, prices the Penetration-Testing usage type at $50.00 per Hour with no regional variation across the 9 regions that publish it, and prices Threat-Modeling and repository-code-review at $0.00 per Hour. The pricing and billing page in the user guide confirms the same split in words: penetration testing "meters each task hour by the second of task time", while code review, design review and threat modeling carry "No charge while in preview".
| Configuration | Task-hour cap | Worst-case cost at $50.00/hr | What AWS calls it |
|---|---|---|---|
| Smallest allowed preset | 20 | $1,000 | "budget controls" |
| Documented larger preset | 30 | $1,500 | recommended for larger apps |
| Custom below the floor | not accepted | n/a | rejected at configuration |
| No limit | unbounded | unbounded | "No limit" |
| 5 concurrent runs at the floor | 100 | $5,000 | default concurrency quota |
The right way to read the feature is not "AWS added a budget". It is "AWS added a kill switch with a 20-hour fuse". For a small internal application where a human tester would quote two days, the cap cannot be set below the price of the whole engagement. AWS mitigates this in the pricing FAQ by noting that billing reflects only the task hours actually used, so a high cap costs nothing extra if the run finishes early. True, and beside the point for anyone who needs a hard ceiling approved before the first run.
Task hours are not wall-clock hours, and that is the part teams get wrong
The pricing page draws the distinction in unusually direct language. Duration is "the elapsed time from when a run starts until it finishes". Task hours are "the agent work inside that run", and the page adds that "Task hours exceed duration when the agent runs many tasks at the same time".
A run that takes 4 hours on the wall can bill considerably more than 4 task-hours, because the agent fans out. Nothing in the console warns you at configuration time how wide that fan-out will be. Asked directly whether a test can be costed in advance, the same page answers: "There is no precise estimation. Task hours depend on the breadth of the target application and the risk types you select. The agent also adapts its plan as it explores your application."
Then there is the monitoring gap. AWS publishes a PentestExecutionDuration metric to Amazon CloudWatch, and the pricing page states it "reports duration in seconds". Duration is the unit you are not billed on. The billed unit, task hours, is visible in the Security Agent web application's All runs table and per-task in the Logs tab, and after the fact in AWS Cost Explorer. You cannot currently raise a CloudWatch alarm on the number that generates the invoice.
Quotas will not save you
Security Agent's Service Quotas page is unusually candid, and worth quoting because it removes a common assumption: "Quotas limit capacity but don't limit spending. The monthly quotas on this page cap how many reviews you can run, and reaching one blocks additional reviews until the next month. They don't cap what you spend, and a quota increase doesn't change your rate."
The published defaults, all per account per region:
| Quota | Default | Adjustable | Bills anything? |
|---|---|---|---|
| Concurrent pentest runs | 5 | Yes | Yes, at $50.00/task-hour |
| Pentest projects | 1,000 | Yes | Only when run |
| PR code reviews per month | 1,000 | Yes | No, $0.00 in preview |
| Design reviews per month | 200 | Yes | No, $0.00 in preview |
| Integrations | 20 | No | No |
| Enabled security requirements | 150 | No | No |
The one that matters for spend is concurrent pentest runs, and it is adjustable upward. Raising it raises your maximum simultaneous burn and nothing else. The quota that caps the free capabilities, PR code reviews at 1,000 a month, caps something that currently costs nothing.
The practical consequence: the only enforcement boundary that touches money is the per-run task-hour cap, applied by the person creating each run, one run at a time. There is no account-level or Agent-Space-level ceiling documented anywhere in the user guide. AWS Budgets and Cost Explorer are the fallback the pricing page points at, and both are detective rather than preventive. They tell you after the task hours have accrued.
What breaks, and how to tell if it is you
Three checks, in the order they cost you money.
One. Anyone who can create a penetration test can choose "No limit". The Create a penetration test flow lists Max task hours as an optional section, with No limit as one of the choices. If your Agent Space grants pentest creation broadly, the cap is a convention, not a control. Review who holds that permission before you review the cap value.
Two. Stopping a run does not refund it. The pricing FAQ answers "If I stop a run before it finishes, am I charged?" with "Yes, the task hours that accrue until the job stops are charged." Watching the logs and killing a run that has wandered is one of AWS's own four cost-control recommendations, alongside narrowing the test to specific URL paths, selecting only the risk types you need, and reusing a configuration to build a baseline. All four reduce spend. None of them undo it.
Three. Revalidation billing is undocumented. The revalidation page describes revalidation as its own job with its own run type, and says nothing about whether it accrues task hours. The pricing page lists penetration testing as the billable capability without naming revalidation either way. If you plan to revalidate on every deploy, treat the cost as unknown and measure it on a single finding first. Do not model it as free because the announcement framed it as an efficiency.
The rebrand the documentation has not absorbed
The announcement headline reads "AWS Security Agent (now part of AWS Continuum)". Checked on 22 August 2026, the user guide has not followed. The What is AWS Security Agent? page describes the product as "a frontier agent" and does not mention AWS Continuum at all. The documentation set still lives under docs.aws.amazon.com/securityagent/, the console strings quoted throughout the guide still say AWS Security Agent, and the Price List offer code is still SecAgent.
That matters for two operational reasons. Cost allocation tags and Cost Explorer filters keyed to the old service name keep working, because the billing identity has not moved. And any runbook, ticket template or procurement document you write this month should use both names, because AWS is currently using both.
This is a familiar pattern for anyone tracking AWS launches closely: the announcement leads, the reference documentation lags, and the gap between them is where teams make wrong assumptions. We saw the same shape with AWS Cost Anomaly Detection and third-party Bedrock models and again with the IAM 20 managed policies per role change, where the headline number and the enforced limit were not the same number.
India-specific considerations
Asia Pacific (Mumbai) carries the Penetration-Testing usage type at the same $50.00 per hour as US East (N. Virginia), so there is no regional discount to plan around. At the 20 task-hour floor that is roughly ₹88,000 per capped test at an exchange rate near ₹88 to the dollar, before the fan-out that pushes task hours past wall-clock duration.
For Indian teams, the sharper question is scope rather than rate. A penetration test requires you to hand the agent target URLs, authentication details, source code and application documentation. Where the target application processes personal data, that handover is a processing decision under the Digital Personal Data Protection Act 2023, and the test environment you point the agent at should be the one your data-handling posture already covers. Running an agentic test against production because the staging environment lacks realistic data is a shortcut worth refusing.
What is still unknown
- Whether revalidation jobs accrue billable task hours. Neither the pricing page nor the revalidation page says.
- Whether any account-level or Agent-Space-level task-hour ceiling exists. The user guide documents only the per-run limit.
- Whether the 20-hour floor varies by region or account age. The documentation states it as a flat constraint with no exceptions listed.
- What a typical task-hours-to-duration ratio looks like. AWS declines to give one, and tells you to build your own baseline by re-running the same configuration.
What to do this week
Set the cap at 20 for the first run against any new target, accept that it may stop short, and record the task hours it consumed. That single number is your baseline, and AWS's own guidance is that there is no substitute for it. Restrict who can select No limit. Create an AWS Budgets alert on the Security Agent line specifically, because the CloudWatch metric will not warn you. And revalidate exactly one finding before you build revalidation into a release pipeline, so the first invoice answers the billing question the documentation does not.
FAQ
How eCorpIT can help
Agentic penetration testing changes what your security budget looks like more than it changes what your security posture looks like, and the difference between the two shows up in the first invoice. eCorpIT designs and runs application security programmes for teams on AWS, including code scanning and application security rollout and software supply chain security, and we build the guardrails, baselines and cost controls around tools like this rather than treating the tool as the programme. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified. If you are costing an agentic pen testing rollout, talk to our team.
References
- AWS Security Agent (now part of AWS Continuum) now supports budget controls and finding revalidation — AWS What's New, 19 August 2026.
- Create a penetration test — AWS Security Agent User Guide, section "Set a maximum task-hours limit".
- Pricing and billing — AWS Security Agent User Guide, billable capabilities table and pricing FAQ.
- Service Quotas — AWS Security Agent User Guide, operations and configuration quota tables.
- Revalidate penetration test findings — AWS Security Agent User Guide.
- What is AWS Security Agent? — AWS Security Agent User Guide, retrieved 22 August 2026.
- Security considerations for AWS Security Agent and AI assisted penetration testing — AWS Security Agent User Guide.
- AWS Price List API offer index — AWS, offer code SecAgent.
- AWS Price List API, SecAgent current offer file — AWS, version 20260706202749, published 6 July 2026.
- AWS Security Agent pricing — AWS product pricing page.
- Analyzing your costs with AWS Cost Explorer — AWS Cost Management User Guide.
- Managing your costs with AWS Budgets — AWS Cost Management User Guide.
Last updated: 22 August 2026.