Inside AWS FinOps Agent: Continuous Cost Governance on Bedrock AgentCore

AWS’s newest frontier agent is also its most conservative one by design. That restraint is the actual selling point for regulated Enterprise clients.

AWS FinOps Agent entered preview in June 2026, built on Amazon Bedrock, aimed squarely at a problem every FinOps practice knows well: cost anomalies get discovered days after they start, by which point the wasted spend is already booked. The agent’s job is to compress that discovery window from days to hours — without, notably, taking any autonomous action on spend itself.

1. What It Does

FinOps Agent answers cost questions in natural language against a customer’s actual cost and usage data, continuously monitors for anomalies, and — the part that differentiates it from a dashboard — automatically investigates and reports on anomalies without waiting for a human to start digging. It surfaces optimization recommendations by pulling from Cost Optimization Hub and Compute Optimizer into one place, with the option to open a Jira ticket automatically when it finds something actionable. Findings and recurring reports land in Slack and Jira — where FinOps and engineering teams already work, not in a console tab someone has to remember to check.

Cost data in, investigation out, human approval before anything happens.
Technical deep-dive — how the anomaly-to-report pipeline actually runs. FinOps Agent’s continuous monitoring loop polls Cost and Usage Report data at the granularity CUR 2.0 exports it, cross-references against Compute Optimizer’s rightsizing signals, and applies anomaly detection tuned against each account’s own historical baseline rather than a fixed percentage threshold — which is why it catches a $400/day anomaly on a normally $600/day account as readily as a $4,000/day anomaly on a $500,000/day account. When an anomaly clears its confidence threshold, the agent opens an investigation, attributes the spend delta to a specific resource, service, or tag dimension, and routes the finding to Slack or opens a Jira ticket — but every one of those routes terminates at a human decision point. There is no code path from “anomaly detected” to “resource terminated.”

2. The Deliberate Design Constraint

Unlike DevOps Agent, which can act on reversible infrastructure changes, FinOps Agent is intentionally built with a human in the loop for every finding — it does not autonomously terminate resources, cancel commitments, or resize infrastructure. AWS’s own framing is explicit: autonomous cost actions require a level of trust the industry is still building toward. That is a product decision, not a current limitation waiting to be lifted quietly — and it is worth stating plainly to clients, because the alternative framing (“an AI agent that can touch your production spend on its own”) is the one that kills deals with a cautious CFO.

3. Productizing the Practice

Enterprise — FinOps Agent wired into the client’s existing multi-account cost allocation structure, findings routed to a dedicated FinOps Slack channel, monthly board-ready reports generated in PPT format automatically. The human-in-the-loop design is the actual pitch here: it lets a regulated client adopt agentic cost governance without a governance committee fight over autonomous spend control.

SMB — a standard configuration against Cost Explorer and Compute Optimizer, recurring PDF reports on a monthly cadence, sold as a fixed-fee FinOps subscription layered on top of the landing zone.

DNB — Slack-native, engineering-team-facing: anomaly alerts and Jira tickets flow directly into the same channels the engineering team already lives in, with the MSP’s role limited to initial configuration and quarterly tuning rather than ongoing report delivery.

What changes for the SI partner

Traditional FinOps engagements sell a monthly or quarterly cost review meeting. This sells continuous investigation with human sign-off — the review meeting becomes a checkpoint on findings the agent already surfaced, not the moment discovery happens. That shortens the sales cycle for renewal, because the value is visible in Slack every week instead of once a quarter in a slide deck.

Business Value Mapping

Technical capabilityBusiness outcomeMetric / KPIPrimary stakeholder
Continuous, baseline-tuned anomaly detectionCost spikes caught in hours, not discovered days later at month-end closeDays from anomaly onset to detectionFinOps lead
Automatic root-cause attributionNo manual digging through CUR data to find the driverTime from alert to identified causeCloud engineering
Human-in-the-loop approval on every findingGovernance-committee-safe adoption for regulated clientsZero autonomous spend actions (compliance requirement)CFO / risk committee
Slack- and Jira-native findings routingFindings surface where teams already work, not in an ignored consoleFinding-to-acknowledgment timeEngineering manager
Automated board-ready PPT/PDF reportsRecurring FinOps review prep time eliminatedHours saved per reporting cycleCFO / board

The agent that refuses to act on its own is not the weaker product. For the client who has to explain every dollar to a board, it’s the only one they’re allowed to buy.

Sources: AWS launches FinOps agent to bring AI cost governance to cloud spend (SiliconANGLE, June 2026) · AWS FinOps Agent in preview (AWS Weekly Roundup, June 2026) · Introducing AWS FinOps Agent (DEV Community / AWS Builders) · AWS Previews FinOps Agent for Cost Analysis and Optimization (InfoQ, June 2026).

The Multi-Tenant AWS Landing Zone: Architecting for MSP Scale

Every agent covered in this series runs inside an AWS account. This article is the foundation those accounts need to exist on — architected once, provisioned for every new client in hours instead of weeks.

DevOps Agent, Security Agent, and FinOps Agent all need somewhere consistent to run: an account structure with the right guardrails, the right cross-account roles, and the right centralized visibility, provisioned identically for the tenth client as for the first. Without that, every new client onboarding becomes a bespoke infrastructure project, and the agentic practice described elsewhere in this series never scales past a handful of hand-built accounts.

1. The Core Structure

AWS Organizations with Control Tower provides the account-vending machine at the top: a management account applying Service Control Policies and org-wide guardrails, with organizational units separating security (log archive, audit, GuardDuty delegated administration), infrastructure (shared networking, Direct Connect or Transit Gateway attachments), and workloads (one account per tenant, or per environment within a tenant for larger clients).

Each tenant account is templated, not hand-built — the same account factory blueprint applied every time, with per-tier variation limited to explicit override points rather than ad hoc configuration drift. Cross-account IAM roles, scoped narrowly per tenant, are what the MSP’s own tooling and the agents from earlier articles assume when they act on a client’s behalf.

One account factory, three tenant tiers, one centralized logging and billing account.

Technical deep-dive — what the account factory template actually enforces. The blueprint’s value is in what it makes structurally impossible, not just what it configures by default. A minimal SCP attached at the Workloads OU denies any action that would disable the mandatory guardrails, regardless of what permissions an individual tenant account’s IAM roles later grant:

{
  "Effect": "Deny",
  "Action": [
    "cloudtrail:StopLogging",
    "cloudtrail:DeleteTrail",
    "guardduty:DeleteDetector",
    "config:DeleteConfigurationRecorder",
    "config:StopConfigurationRecorder"
  ],
  "Resource": "*",
  "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws:iam::MGMT_ACCOUNT:role/BreakGlassAdmin" } }
}

That single SCP is what lets an MSP promise a client “your account cannot silently go dark on audit logging,” even from an admin inside that tenant’s own account — the guarantee that makes the centralized logging account in Figure 4 actually trustworthy rather than merely convenient.

2. Centralization Without Losing Tenant Boundaries

A dedicated logging and billing account aggregates CloudTrail, Config, and GuardDuty findings across every tenant account, and consolidates billing. Cross-account metrics centralization lets the MSP designate a monitoring account that automatically aggregates metrics from every member account, which is what makes fleet-wide dashboards and alarms possible without manual per-account setup — the same centralization pattern this series’ earlier observability work depends on.

The design tension is between centralization (one place to see everything) and isolation (a tenant’s data never leaks sideways to another tenant, and a security incident in one account cannot escalate laterally). Getting this boundary right, once, in the account factory template is what lets every subsequent client onboarding skip the argument entirely.

3. Productizing the Practice

Enterprise — a custom OU structure reflecting the client’s own business units or compliance boundaries, with SCP overrides negotiated as part of the onboarding statement of work, but still provisioned through the same underlying account factory.

SMB — the standard templated baseline, provisioned with no negotiation on structure — the value is speed and consistency, not customization.

DNB — fast, self-service provisioning, often triggered by the client’s own platform team through an API rather than an MSP ticket, with the MSP’s role concentrated in the initial template design and periodic guardrail review.

What changes for the SI partner

The landing zone stops being a one-time setup fee buried inside a larger migration engagement and becomes a standalone, repeatable asset — the thing that makes every other article in this series deployable in days rather than months for the next client. Partners who template this well measure client onboarding time in hours; partners who don’t measure it in weeks, and that gap compounds across every new logo.

Business Value Mapping

Technical capabilityBusiness outcomeMetric / KPIPrimary stakeholder
Templated account factory (Control Tower blueprint)New client onboarding in hours, not a bespoke infra projectTime from signed SOW to first workload account liveDelivery lead / partner ops
SCP-enforced guardrails at the OU levelCompliance posture is structural, not a policy on paperGuardrail violation rate across tenant fleetCISO / compliance
Centralized logging & billing accountOne place to see and bill every tenant, no manual per-account setupTime to produce a cross-tenant reportFinance / partner ops
Scoped cross-account IAM rolesMSP tooling and agents act on a client’s behalf without shared credentialsLeast-privilege audit pass rateCISO
Tier-based override points (Enterprise/SMB/DNB)Customization only where it’s sold, standardization everywhere else% of onboardings requiring off-template changesDelivery lead

The landing zone is the least visible thing you build and the reason everything else you sell can be sold twice as fast.

Sources: AWS Control Tower and Organizations documentation · CloudWatch cross-account metrics centralization (AWS documentation, 2026) · AWS Cloud Operations Blog, multi-account architecture patterns.

Inside AWS DevOps Agent: Building an AI-Augmented NOC on Bedrock AgentCore

How AWS DevOps Agent is architected, and what it means to restructure a managed-services NOC around it instead of around headcount.

An SRE responding to a page must manually correlate telemetry from multiple sources, trace dependencies across services, and form a hypothesis — a process that routinely takes hours even for a strong engineer. AWS DevOps Agent, generally available since March 2026 and built on Amazon Bedrock AgentCore, is AWS’s attempt to compress that process into minutes by running as an autonomous operational teammate rather than a query tool.

1. How It’s Architected

DevOps Agent ingests signal from wherever a team’s operational data actually lives: CloudWatch alarms, PagerDuty and ServiceNow tickets, Dynatrace problems, and — critically for a partner running a hybrid or multi-tool estate — built-in integrations with Datadog, Splunk, New Relic, Grafana, GitHub, GitLab, and Azure DevOps. It learns application relationships over time rather than requiring them to be hand-mapped, and correlates telemetry, code, and deployment data to form a root-cause hypothesis before a human has opened a dashboard.

When an incident triggers via any configured webhook, the agent begins investigating immediately, without a human prompting it. If the investigation resolves cleanly, it can act through SSM Automation on reversible operations — scale out, restart, toggle a feature flag. If it hits genuine ambiguity, it surfaces a disambiguation card to the on-call engineer rather than guessing, and the investigation resumes once a human responds. Since June 2026 this runs through Model Context Protocol (MCP) and Agent-to-Agent (A2A) support, letting DevOps Agent call external tools and orchestrate with other agents — including, notably, calling AWS Security Agent or FinOps Agent as sub-investigators when an incident’s root cause turns out to be a security or cost event rather than a pure availability one.

Figure 3. Signal in, hypothesis out, act-or-ask decision — the DevOps Agent loop.
Technical deep-dive — the act-or-ask decision boundary. The design choice that makes DevOps Agent safe to run unattended is not model capability, it is the explicit scoping of what “act” is allowed to mean. Reversible actions are wired to SSM Automation documents with a narrow, auditable action set:
{
  "investigation_id": "inv-2026-06-1147",
  "root_cause_confidence": 0.93,
  "decision": "act",
  "action": {
    "runbook": "ssm-automation:scale-out-service",
    "target": "svc-checkout-prod",
    "reversible": true,
    "requires_approval": false
  },
  "iam_scope": ["ssm:StartAutomationExecution"],
  "blast_radius": "single service, single environment"
}

Below a confidence threshold, or for any action tagged requires_approval: true (scaling in, terminating a resource, rolling back a deployment), the agent stops and emits a disambiguation card instead of guessing — the investigation state persists so the human’s answer resumes it rather than restarting it. That threshold, and the IAM policy scoping which actions the agent’s execution role can even call, is the actual governance surface a partner configures per client — not a setting exposed once and forgotten.

2. What GA Added Since Preview

The preview version (re:Invent 2025) worked AWS-native environments. General availability added the ability to investigate applications running in Azure and on-premises environments, custom agent skills so a team can extend the agent with its own institutional knowledge, custom charts and reports, and updated IAM managed policies for tighter permission scoping. June 2026 layered on custom SRE agents (encoding a specific team’s runbooks and failure modes), webhook-triggered invocation from any external system, and static IP support for outbound calls — the detail that lets the agent integrate with an on-premises ITSM platform sitting behind an IP allowlist.

3. Productizing the Practice

DevOps Agent bills on cumulative agent task time, billed per second — a fundamentally different cost shape from a headcount-based NOC. That opens a pricing conversation most MSPs have wanted to have for years but couldn’t justify: moving clients off time-and-materials support retainers onto outcome-based SLA pricing, where the fee is tied to measured MTTR rather than hours staffed. AWS reported preview customers seeing up to 75% lower MTTR and 94% root-cause accuracy — treat that as a starting negotiating anchor, not a guarantee, and instrument your own baseline against your own incident history before quoting it to a client.

Enterprise — custom SRE agents encoding the client’s specific architecture and runbooks, full MCP integration with their existing Datadog/Splunk investment rather than requiring migration to CloudWatch.

SMB — a standardized agent configuration across CloudWatch and a small set of common integrations, sold as a flat monthly NOC replacement.

DNB — webhook-driven, API-first: the client’s own engineering team owns the pager, and the agent runs as an investigation accelerant rather than a full NOC replacement, priced per incident investigated.

What changes for the SI partner

The billable unit stops being a shift and becomes an investigation. That is a harder number to pad and a more attractive one to a client comparing your quote against a traditional MSP’s staffing-based rate card — which is exactly why this is worth leading with in new-logo conversations rather than only offering it to existing accounts.

Business Value Mapping

Technical capabilityBusiness outcomeMetric / KPIPrimary stakeholder
Autonomous investigation on webhook triggerInvestigation starts in seconds, not after an engineer picks up a pageTime-to-first-hypothesisVP Engineering / Ops
Cross-tool correlation (CloudWatch, Datadog, Splunk, GitHub)No migration required to unlock the agent on an existing toolchainIntegration time for net-new clientIT/Ops director
Reversible-action automation via SSMCommon incidents resolved without waking an engineer% of incidents auto-remediatedOn-call SRE lead
Disambiguation card on low-confidence findingsNo false-confidence automated actions on ambiguous incidentsFalse-action rateCTO / risk owner
Per-second consumption billingNOC cost tracks incident volume, not fixed headcountCost per investigation vs. cost per staffed hourCFO
MCP/A2A handoff to Security or FinOps AgentRoot cause resolved even when it crosses domain boundaries% of incidents correctly routed cross-domainHead of Managed Services

A NOC staffed by people bills for time spent looking. A NOC run on an investigation agent bills for answers found — and that difference is the entire pitch.

Sources: Announcing general availability of AWS DevOps Agent (AWS Cloud Operations Blog) · AWS Announces General Availability of DevOps Agent (InfoQ, April 2026) · This Month in AWS Observability: June 2026 (custom SRE agents, MCP/A2A, webhook triggers) · Leverage agentic AI for autonomous incident response with AWS DevOps Agent (AWS DevOps Blog).

Beyond the Frontier Agent: A Defense-in-Depth AWS Security Architecture for MSPs

Security Agent is the newest layer, not the only one. This article covers the AWS-native services an MSP still needs underneath it, and how to price the whole stack by client tier.

A single agent, however capable, is not a security practice — it is a layer. AWS Security Agent covers the application layer: design, code, and runtime exploitability. Everything below that — account posture, network perimeter, and cross-account threat correlation — still runs on the AWS-native security services that predate the agentic wave and remain the actual foundation an MSP builds on.

1. The Three Layers Below the Agent

Perimeter. AWS WAF now sits in front of Amazon Bedrock AgentCore Gateway, which matters the moment your own practice starts running agent workloads on behalf of clients — the agent’s tool-calling interface is itself a surface that needs the same perimeter controls as any public endpoint.

Detection and posture. GuardDuty for continuous threat detection across accounts, workloads, and EKS runtime; Security Hub aggregating findings into one view; Security Lake normalizing that data into OCSF format for long-term correlation and, increasingly, for feeding third-party detection signals (Check Point, Zscaler, Rubrik, Netskope, and SentinelOne integrations were added to AgentCore-adjacent workflows in 2026); Config and IAM Access Analyzer for continuous posture and least-privilege drift detection.

Application. Security Agent, covered in depth in Article 1, sitting atop all of the above.

Figure 2. Four layers, one architecture — the SI partner’s actual deliverable.
Technical deep-dive — the correlation that makes four layers act as one architecture. The layering only pays off commercially if findings cross layer boundaries, not just sit side by side in four separate consoles. Security Lake normalizes GuardDuty, Config, and Security Hub findings into OCSF (Open Cybersecurity Schema Framework), and Security Agent’s application-layer findings are tagged with the same account and resource identifiers used across that OCSF data. A practical example: GuardDuty raises a low-confidence finding on unusual API call volume from an EC2 instance role; independently, Security Agent’s code-review checkpoint had flagged that the same role is attached to a service with a known input-validation gap. Correlated on the shared resource ARN, that becomes one incident timeline instead of two disconnected alerts in two different tools — the difference between an analyst noticing a pattern by luck and a SOC seeing it by design.

2. Why the Layering Matters Commercially

Selling Security Agent alone invites an obvious client question: what happens to an attacker who never touches the application layer at all — a leaked credential, a misconfigured S3 bucket, a compromised third-party integration? The honest answer is that Security Agent does not see any of that; it is scoped to application security. An MSP that sells only the agent is selling a partial answer to a full-estate problem, and a technically literate buyer will notice.

The correct commercial framing is the full stack: perimeter, detection, posture, and application, packaged as one managed offering with Security Agent as the newest and most visible component — not the whole product.

3. Tiering the Practice

Enterprise — custom SOC integration: Security Lake feeding the client’s existing SIEM or a dedicated tenancy, GuardDuty and Security Hub findings correlated against Security Agent’s application-layer findings for a single incident timeline.

SMB — a managed baseline across GuardDuty, Security Hub, and Config, with Security Agent’s managed-cadence tier from Article 1 layered on top. This is the volume tier: standardized, not customized.

DNB — self-serve API-first guardrails: Config rules and IAM Access Analyzer findings exposed via API for the client’s own platform team to consume, with the partner’s value concentrated in guardrail design and quarterly review rather than day-to-day operation.

What changes for the SI partner

The pitch stops being “we run your SOC” and becomes “we run the four-layer stack, and the layer you can see — Security Agent’s pentest reports and remediation PRs — is backed by three layers you don’t have to think about.” That framing sells the agent and the foundation as one motion instead of two separate line items competing for the same budget line.

Business Value Mapping

Technical capabilityBusiness outcomeMetric / KPIPrimary stakeholder
WAF in front of AgentCore GatewayAgent tool-calling surface does not become an unguarded attack vectorBlocked malicious requests per monthCISO
GuardDuty + Security Hub + Security Lake correlationOne incident timeline instead of four disconnected consolesMean time-to-correlate an incidentSOC lead
Config + IAM Access Analyzer continuous posture checksDrift caught before it becomes an exploitable gapDays of posture drift before remediationCloud security architect
Application-layer findings tagged to shared resource identityCross-layer correlation instead of siloed alerts% of incidents correlated across >1 layerCISO
Four-layer stack sold as one managed offeringSingle retainer replaces multiple point-tool contractsNet revenue per client vs. point-solution pricingPartner CRO / sales

An agent is a capability. A defense-in-depth architecture is what a client is actually buying when they sign a security retainer.

Sources: AWS Security Agent GA (AWS What’s New, March 2026) · AWS WAF adds support for Amazon Bedrock AgentCore Gateway (AWS What’s New, June 2026) · Amazon Bedrock AgentCore Policy and third-party detection integrations (AWS re:Invent 2025 announcements)

Inside AWS Security Agent: Architecting Autonomous AppSec on Bedrock AgentCore

A technical breakdown of AWS Security Agent’s architecture, and what it means to build a productized AppSec practice around it as an AWS partner.

Application security has run on a fixed cadence for two decades: design review at kickoff, code review in CI, a penetration test before launch and once a year after. That cadence assumed releases were infrequent enough for a human-scheduled process to keep pace. They no longer are. AWS Security Agent, generally available since 31 March 2026, is AWS’s answer: a system of purpose-built agents that runs all three checkpoints continuously, not on a calendar.

1. What Security Agent Actually Does

Security Agent ingests source code, architecture diagrams, API specifications, and threat models to build application context once, then reuses that context across three checkpoints: design review, automated code review on every pull request, and on-demand penetration testing. It combines static analysis (SAST), dynamic analysis (DAST), and active exploitation into a single context-aware pipeline, chaining individual findings into multi-step attack paths rather than reporting them as isolated vulnerabilities — the difference between “this endpoint lacks input validation” and “this endpoint lacks input validation, which combined with the over-permissioned IAM role three services downstream, allows full account takeover.”

Two operational details matter for how a partner sells this. First, findings on pull requests can open remediation PRs directly rather than just filing a ticket. Second, pentest runs are downloadable as structured reports as of March 2026 — the artifact a compliance-driven Enterprise buyer actually needs to hand to an auditor.


Technical deep-dive — how attack-chain correlation actually works. Security Agent’s differentiator over a conventional SAST/DAST pipeline is that findings are correlated against the same application-context graph across all three checkpoints, not scored in isolation. A representative chain looks like this: the code-review checkpoint flags an endpoint accepting unvalidated input (a CWE-20 class finding, moderate severity in isolation); separately, the design-review checkpoint had already logged an IAM role three services downstream as over-permissioned (an iam:PassRole wildcard against a data-plane resource); the pentest checkpoint then chains the two by demonstrating that the unvalidated input reaches a code path capable of assuming that role. The reported finding is not two moderate items — it is one critical finding with a proof-of-concept exploitation path, which is what materially changes the triage conversation with a client’s engineering lead from “add to backlog” to “patch before next release.”

 

{
  "finding_id": "SA-2026-04-0192",
  "severity": "CRITICAL",
  "chain": [
    { "checkpoint": "code_review",  "cwe": "CWE-20",  "component": "svc-orders/api/checkout" },
    { "checkpoint": "design_review","finding": "iam_overpermission", "role": "orders-worker-role" },
    { "checkpoint": "pentest",      "verified": true, "impact": "full account takeover via assumed role" }
  ],
  "remediation_pr": "opened",
  "task_hours_billed": 0.9
}

2. The AgentCore Substrate

Security Agent is not a standalone product bolted onto the console — it runs on Amazon Bedrock AgentCore, the same platform underpinning DevOps Agent and FinOps Agent. Two AgentCore primitives matter specifically for a security-sensitive workload. AgentCore Runtime isolates each agent session in its own Firecracker microVM, so one agent’s code execution cannot read another session’s data — a materially stronger boundary than container isolation, and part of why AWS positions frontier agents as usable in regulated industries. And AgentCore Gateway, the interface layer through which agents call external tools, is now protected by AWS WAF as of June 2026, closing the obvious objection that an autonomous pentesting agent is itself a new attack surface.

Coverage extends beyond AWS: Security Agent supports multicloud and on-premises environments, which is the detail that makes it relevant to this series specifically — an SI partner running a hybrid estate does not need a separate tool for the on-prem half.

3. Productizing the Practice

The commercial shift is pricing. Security Agent bills at $50 per
task-hour with a two-month free trial for new customers — consumption
pricing, not a project fee. That maps cleanly onto three partner-side
SKUs:

Enterprise — Security Agent embedded directly in the
CI/CD pipeline, triggering on every merge to a protected branch, with
pentest runs before every production release. Billed as a continuous
AppSec subscription, priced against the client’s release frequency
rather than a once-a-year statement of work.

SMB — a managed baseline: scheduled design and code
reviews on a fixed cadence, on-demand pentest before major releases,
delivered as a fixed monthly retainer that absorbs the task-hour
variability.

DNB — self-serve, API-triggered: the client’s own CI
pipeline calls Security Agent directly, and the partner’s value is in
the guardrail configuration, findings triage dashboard, and quarterly
attestation report — not in running the pipeline itself.

What changes for the SI partner

The traditional pentest sales motion — a six-week engagement sold
once or twice a year — does not survive this. The replacement motion
sells continuous coverage against a release cadence, competes on
hours-not-weeks turnaround, and prices on agent-consumption economics
rather than consultant-day rates. Partners who keep selling
point-in-time pentests against a competitor offering pentest-per-release
are pricing against a shrinking market.

Business Value Mapping

 

Technical capability Business outcome Metric / KPI Primary stakeholder
Continuous design + code + pentest checkpoints on every merge Vulnerabilities caught before production, not after an annual audit Mean time-to-detect (design-time vs. post-release) CISO / AppSec lead
Multi-step attack-chain correlation across checkpoints Fewer false-positive tickets; engineering trusts and acts on findings Finding-to-fix conversion rate Engineering manager
Automated remediation PRs Reduced developer time spent on triage and patching Hours saved per critical finding CTO
Downloadable structured pentest reports Audit-ready evidence on demand instead of a once-a-year engagement Time-to-produce compliance evidence Compliance / auditor
Consumption-based task-hour pricing AppSec spend scales with release cadence, not a fixed annual fee Cost per release vs. cost per year CFO / procurement
Firecracker microVM session isolation Autonomous pentesting itself does not become a new attack surface Isolation boundary audit pass rate CISO

Continuous AppSec is not a faster version of the old pentest. It is a different product, sold on a different cycle, to a buyer who no longer accepts an annual answer to a weekly question.

Sources: AWS launches frontier agents for security testing and cloud operations (AWS Machine Learning Blog) · AWS Security Agent on-demand penetration testing GA (AWS What’s New, March 2026) · AWS Security Agent now supports downloading penetration testing reports (AWS What’s New) · AWS WAF adds support for Amazon Bedrock AgentCore Gateway (AWS What’s New, June 2026).

We are now live on AWS Marketplace.
The integrated view of your cloud infrastructure is now easier than ever!