AWS Continuum: Because 3,200 Findings Without Context Isn't a Strategy

TL;DR

Reading time: ~12 minutes (skip to sections using the headings)

What you'll walk away with:

• A clear understanding of what AWS Continuum actually does (and what it doesn't)

• Two real worked examples with output samples showing how it finds, validates, and fixes vulnerabilities

• An honest assessment of limitations and gaps

• Whether this fits your workflow or if you should wait

The one-liner: Continuum is an AI-native security service that reasons about your environment, proves what's exploitable, and drafts fixes as PRs. It does not touch production. It's promising but early.

Who this is for: Developers, DevSecOps engineers, and security practitioners evaluating agentic security tooling.

---

It's Monday Morning. You Have 3,200 Security Findings.

You grab your coffee. You open Security Hub. 3,200 findings.

Some are critical. Some are noise. Most are somewhere in between. Your backlog from last sprint? Still there. The new CVE that dropped Friday afternoon? Added to the pile.

You know the drill: open the finding, context-switch to IAM to check permissions, flip to VPC to verify reachability, check CloudTrail for activity, read the runbook (if one exists), figure out who owns the service, draft a fix, test the fix, pray the fix doesn't break prod.

Multiply that by 3,200.

Here's the thing most scanners won't tell you: the findings that represent real risk are often individually unremarkable. Mediums and lows that only become critical when something stitches them together. That medium-severity path traversal? Harmless in isolation. Pair it with an overprivileged role and an internet-reachable ALB? Now you have a breach.

And while you're triaging finding #47, an attacker with a frontier AI model has already turned a disclosed vulnerability into a working exploit. In minutes.

The gap between how fast attacks happen and how fast we respond isn't closing. It's widening.

---

Context is Everywhere. Answers are Nowhere.

The context that would answer "does this finding matter?" is scattered across infrastructure config, IAM policies, application topology, runbooks, architecture diagrams, or worse, it lives in the memory of the engineer who built the system two years ago who's now on a different team.

Teams spend weeks chasing risks that don't matter. Meanwhile, the real threats hide in plain sight, waiting for something to stitch them together.

---

The AI Paradox: More Tools = More Backlog

Here's the cruel irony of our AI-accelerated world:

AI generates more code. Scanners find more vulnerabilities. Backlog only grows.

Every new security tool gets you to the wall faster. None help you over it. Human validation and fix cycles create too much churn. Scaling humans is no longer working.

And yet, every enterprise security team says the same thing:

"We have the data and the tools. We don't have something that sits on top and makes decisions at machine speed."

---

The Asymmetry

	Attacker	Defender
Speed	Disclosure to Exploit in minutes	Finding to Fix in days to weeks
Powered by	AI-generated exploits	Human-coordinated response
Scaling model	Automated	Headcount

This asymmetry is structural, not a skills gap. You can't hire your way out of it.

---

What If Your Security Tooling Could Think Like Your Best Engineer?

Not replace them. Think like them.

Your best security engineer doesn't treat every "Critical" finding the same. They ask:

• "Is this thing actually deployed?"

• "Can anything reach it from the internet?"

• "What data does it touch?"

• "What's the blast radius if this gets exploited?"

That's context. That's judgment. That's what takes hours of tab-switching across six different consoles.

AWS Continuum is built on this premise: security can no longer scale by adding more humans. It must scale by teaching machines to reason like security engineers.

Announced at AWS Summit NYC on June 17, 2026, Continuum addresses the full lifecycle of a code vulnerability, from discovery through remediation, at machine speed.

---

The 30-Second Version

AWS Continuum is an AI-native security service that:

1. Discovers vulnerabilities (yours + its own scans)

2. Prioritizes by actual business impact, not just CVSS scores

3. Validates by reproducing exploits in a sandbox (proof, not guesses)

4. Remediates by generating tested fixes as PRs you review and ship

It integrates with your IDE (Kiro, Claude Code), your Git platform (GitHub/GitLab/Bitbucket), your ticketing system (Jira/ServiceNow), and your SIEM (Splunk/Sentinel).

---

How It Actually Works: The Continuous Loop

Traditional security is point-in-time. Quarterly pen tests. Annual audits. Continuum runs continuously. Every outcome feeds the next cycle.

DISCOVER → PRIORITIZE → VALIDATE → REMEDIATE ↑ | └────────────────────────────────────┘ (every outcome feeds back)

Signals In

• AWS Security Hub, Amazon GuardDuty, Amazon Inspector

• Third-party tools (Wiz, Snyk, CrowdStrike)

• Your existing vulnerability backlog

Decisions Out

• IDE / PR: Developer gets a fix, inline, where they code

• Slack: SOC gets an actionable alert, not noise

• Jira / ServiceNow: Context-rich ticket, routed to the right owner

• SIEM: Enriched findings in Splunk or Sentinel

• MCP: Agent-to-agent communication for automated workflows

---

Three Agents, Three Mindsets

Under the hood, Continuum operates through three specialized agents, each with a distinct way of thinking:

Prioritization Agent (Thinks like a threat intel analyst)

This agent doesn't just look at CVSS scores. It traverses a typed context graph across your environment:

• Context graph traversal: Walks the relationships between services, resources, network paths, and data stores

• Crown jewel proximity scoring: How many hops from the internet to your most critical data?

• SSVC classification: Stakeholder-Specific Vulnerability Categorization for your context

• Business impact ranking: Is this a dev sandbox or your payment processing pipeline?

Validation Agent (Thinks like a red team operator)

No more guessing whether a vulnerability is actually exploitable. This agent:

• Analyzes your infrastructure configuration

• Reproduces exploits in a sandboxed environment

• Maps blast radius

• Returns three-valued verdicts with confidence scores

Key insight: Most scanners give you binary "vulnerable/not vulnerable." Continuum is honest. If evidence is insufficient, it says Inconclusive rather than guessing. No false confidence.

{
  "verdicts": [
    {
      "finding_id": "SEC-2026-4471",
      "verdict": "EXPLOITABLE",
      "confidence": 0.95,
      "evidence": "Reproduced path traversal in sandbox. Response: 200 OK with file contents.",
      "proof_artifact": "s3://continuum-evidence/trace-7f3a2b1c/exploit-replay.har"
    },
    {
      "finding_id": "SEC-2026-4472",
      "verdict": "INCONCLUSIVE",
      "confidence": 0.50,
      "evidence": "IMDSv1 check requires runtime env vars not available in static analysis.",
      "missing": ["IMDS_ENDPOINT", "EC2_METADATA_TOKEN_TTL"]
    },
    {
      "finding_id": "SEC-2026-4473",
      "verdict": "NOT_EXPLOITABLE",
      "confidence": 0.90,
      "evidence": "WAF rule waf-regional-path-traversal blocks request. Confirmed HTTP 403.",
      "proof_artifact": "s3://continuum-evidence/trace-8a4b3c2d/waf-block.har"
    }
  ]
}

Remediation Agent (Thinks like a security engineer)

Once a vulnerability is validated as real:

• Generates a code-level patch

• Runs the same test that proved the bug to prove the fix works (symmetric proof)

• Integrates with your IaC (AWS CDK, Terraform)

• Includes a full rollback path

• Routes to the correct team via an ownership graph

"The same exercise that proved the bug now proves the fix." No separate QA cycle. The proof is baked in.

The critical principle: Continuum drafts. You ship. It never touches production autonomously. Lambda, S3, DynamoDB, ECS, IAM are never modified without your approval. The PR goes through your review process.

---

The Secret Sauce: Typed Context Graph

Continuum builds a rich understanding of your environment by ingesting data from 15+ sources, pulling together all that scattered context that used to live across six consoles and one engineer's memory:

Structured data:

• AWS Config, IAM, VPC Reachability Analyzer, IAM Access Analyzer

• Security Hub, GuardDuty, WAF, Macie, CloudTrail

• X-Ray, Application Signals, VPC Flow Logs

Unstructured data:

• Source code, architecture decision records (ADRs)

• Threat models, runbooks, business priority docs

The graph uses typed edges (Calls, DataFlows, ExposedTo, Trusts, NetworkReaches, ProtectedBy) to map how everything connects.

Multi-Source Corroboration

Confidence isn't just a number. It's evidence-backed:

Evidence Sources	Confidence Score
4 sources agree	1.0
3 sources agree	0.9
2 sources agree	0.75
1 runtime source	0.6
1 inferred source	0.3

Safety rule: When two sources disagree, the most restrictive value wins. If one source says "publicly exposed" and another says "not exposed," the output is "publicly exposed." Always err on the side of caution.

---

Worked Example 1: The Routine Cleanup Job That Could Delete Everything

Let's start with something deceptively simple.

Continuum reviewed a routine cleanup job, the kind every team has. It noticed a missing input validation field. Without that input? The job deletes everything. Including protected resources.

Here's the prioritization output:

{
  "finding_id": "CONT-2026-7892",
  "source": "continuum-code-scan",
  "title": "Missing input validation in cleanup-job handler",
  "cwe": "CWE-20 (Improper Input Validation)",
  "raw_severity": "CRITICAL",
  "continuum_severity": "HIGH",
  "severity_justification": "Downgraded from CRITICAL. Environment graph confirms: not reachable from outside the account. No internet-facing path. Internal service-to-service invocation only.",
  "reachability": {
    "internet_exposed": false,
    "internal_only": true,
    "invocation_path": "EventBridge Rule > Lambda (cleanup-job)"
  },
  "business_context": {
    "environment": "production",
    "data_classification": "internal",
    "blast_radius": "S3 bucket contents (non-PCI, non-PII)"
  },
  "recommended_action": "FIX_WITHIN_7_DAYS"
}

What happened next:

Continuum wrote a unit test, ran it, and reproduced the bug. Not a matter of opinion. Proof.

# Unit test generated by Continuum Validation Agent
# File: tests/test_cleanup_job_input_validation.py

import pytest
from cleanup_job.handler import process_cleanup_request

class TestCleanupJobInputValidation:
    """
    Proves CWE-20: Missing input validation allows
    unrestricted deletion when 'target_prefix' is empty.
    """

    def test_empty_prefix_triggers_full_deletion(self):
        """BUG: Empty prefix causes deletion of ALL objects."""
        event = {
            "bucket": "prod-data-store",
            "target_prefix": "",  # <-- Missing validation
            "dry_run": False
        }
        with pytest.raises(ValueError, match="target_prefix cannot be empty"):
            process_cleanup_request(event)

    def test_none_prefix_triggers_full_deletion(self):
        """BUG: None prefix also causes unrestricted deletion."""
        event = {
            "bucket": "prod-data-store",
            "target_prefix": None,
            "dry_run": False
        }
        with pytest.raises(ValueError, match="target_prefix cannot be empty"):
            process_cleanup_request(event)

    def test_valid_prefix_processes_normally(self):
        """PASS: Valid prefix scopes deletion correctly."""
        event = {
            "bucket": "prod-data-store",
            "target_prefix": "tmp/2026-06/",
            "dry_run": True
        }
        result = process_cleanup_request(event)
        assert result["scoped_to"] == "tmp/2026-06/"
        assert result["objects_matched"] >= 0

Then it drafted the fix and verified it with the same test:

# Fix generated by Continuum Remediation Agent
# File: cleanup_job/handler.py (diff)

  def process_cleanup_request(event: dict) -> dict:
+     # CONTINUUM-FIX: Validate target_prefix to prevent unrestricted deletion
+     target_prefix = event.get("target_prefix")
+     if not target_prefix or not target_prefix.strip():
+         raise ValueError(
+             "target_prefix cannot be empty. "
+             "Refusing to delete without explicit scope."
+         )
+
+     # Additional guard: prevent root-level deletion patterns
+     if target_prefix.strip() in ("/", "*", "**"):
+         raise ValueError(
+             f"Dangerous prefix pattern: '{target_prefix}'. "
+             "Root-level deletion is not permitted."
+         )
+
      bucket = event["bucket"]
-     target_prefix = event.get("target_prefix", "")
      dry_run = event.get("dry_run", True)

      # Proceed with scoped deletion
      objects = list_objects(bucket, prefix=target_prefix)

Test result after fix:

$ pytest tests/test_cleanup_job_input_validation.py -v

test_empty_prefix_triggers_full_deletion    PASSED
test_none_prefix_triggers_full_deletion     PASSED
test_valid_prefix_processes_normally         PASSED

3 passed in 0.12s

The change goes to the team to ship through their own review and release process. Continuum drafts. You ship.

---

Worked Example 2: The Media Service Attack Path

Now let's look at something scarier. A multi-hop attack path hiding in plain sight.

Setup: Your media service has a path traversal vulnerability (CWE-22).

What Continuum finds via graph traversal:

INTERNET > CloudFront > ALB > media-service > s3:pii-bucket
            (4 hops from internet to PII data)

Here's the actual graph walk logic:

{
  "trace_id": "7f3a2b1c-e9d4-4a5f-8c2e-1b3d5f7a9c0e",
  "graph_traversal": {
    "target_asset": "s3:pii-bucket",
    "classification": "PCI-DSS scope",
    "traversal_path": [
      {
        "node": "s3:pii-bucket",
        "question": "Who reads this?",
        "answer": "media-svc-role",
        "edge_type": "Trusts",
        "confidence": 1.0
      },
      {
        "node": "media-svc-role",
        "question": "Who assumes this?",
        "answer": "media-service (ECS)",
        "edge_type": "AssumedBy",
        "confidence": 1.0
      },
      {
        "node": "media-service",
        "question": "What reaches this?",
        "answer": "ALB (arn:aws:elasticloadbalancing:us-east-1:123456:loadbalancer/app/media-alb)",
        "edge_type": "NetworkReaches",
        "confidence": 1.0
      },
      {
        "node": "media-alb",
        "question": "What reaches this?",
        "answer": "INTERNET (0.0.0.0/0)",
        "edge_type": "ExposedTo",
        "confidence": 1.0
      }
    ],
    "hops_to_internet": 4,
    "crown_jewel_proximity": "DIRECT"
  }
}

The evidence chain and prioritization:

{
  "priority_decision": "ACT_IMMEDIATELY",
  "compound_confidence": 0.95,
  "evidence": [
    {
      "step": 1,
      "finding": "s3:* permissions on media-svc-role",
      "source": "IAM Policy (arn:aws:iam::123456:policy/media-svc-access)",
      "confidence": 1.00
    },
    {
      "step": 2,
      "finding": "PCI-tagged data in pii-bucket",
      "source": "Amazon Macie scan (2026-06-10T14:22:00Z)",
      "confidence": 0.95
    },
    {
      "step": 3,
      "finding": "Internet-reachable via ALB",
      "source": "VPC Reachability Analyzer",
      "confidence": 1.00
    },
    {
      "step": 4,
      "finding": "WAF rule exists but in COUNT mode (not blocking)",
      "source": "AWS Config rule (waf-regional-path-traversal)",
      "confidence": 1.00,
      "detail": "Mode: COUNT. Action: None. Attack passes through unblocked."
    }
  ],
  "business_impact": {
    "pipeline": "Payment processing",
    "compliance": "PCI-DSS",
    "revenue_exposure": "$2M/day",
    "confidence": 0.85,
    "source": "architecture-doc-v3.md"
  },
  "additional_gaps": [
    {
      "finding": "Missing CloudTrail monitoring on DynamoDB table",
      "resource": "arn:aws:dynamodb:us-east-1:123456:table/payment-sessions",
      "risk": "No audit logging for data access"
    }
  ]
}

The remediation PR generated:

# Continuum Remediation: Scope down media-svc-role
# File: infrastructure/iam-roles.yaml (CDK)

  MediaServiceRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: media-svc-role
      AssumeRolePolicyDocument:
        # ... (unchanged)
      Policies:
        - PolicyName: media-bucket-access
          PolicyDocument:
            Statement:
-             - Effect: Allow
-               Action: "s3:*"
-               Resource: "*"
+             - Effect: Allow
+               Action:
+                 - "s3:GetObject"
+                 - "s3:ListBucket"
+               Resource:
+                 - "arn:aws:s3:::media-assets-prod"
+                 - "arn:aws:s3:::media-assets-prod/*"
+             # CONTINUUM: Removed s3:* on all resources.
+             # PII bucket access severed. Attack path broken.

Routing metadata:

{
  "remediation_routing": {
    "owner_team": "payments-team",
    "identified_via": "OwnedBy edge in context graph",
    "pipeline": "CDK (aws-cdk v2.148.0)",
    "rollback_path": "cdk deploy --rollback",
    "pr_target": "main",
    "reviewer_suggestion": ["@security-oncall", "@payments-lead"]
  }
}

---

"But Can I Trust It?" Safety Architecture Deep Dive

This is the question every security-conscious developer asks. Here's how Continuum earns trust:

Four-Layer Authorization Pipeline

Every AI tool call goes through:

AI/LLM Tool Call Request
        |
1. Cedar Policy Engine    > Deterministic. Sub-millisecond. Rust-backed.
        |
2. Input Validation       > Schema checks + account binding
        |
3. Fail-Closed Audit      > Logged BEFORE execution. Fail = no dispatch.
        |
4. Credential Broker      > Fresh STS token. 1 action. 1 resource. 15-min TTL.
        |
   AUTHORIZED ACTION

Credential Design: Triple-Scoped

Property	Design
Scope	1 API action + 1 resource only
Lifetime	15-minute TTL (ephemeral)
Permission	Your role policy intersect Session policy intersect Resource ARN

Execution Isolation

All code runs in a disposable sandbox with no path to the real environment:

• Private VPC subnet with no NAT, no IGW, no VPC endpoints

• Zero-egress security group with no outbound traffic

• No IAM execution role with zero AWS credentials inside

• Fresh MicroVM per invocation with memory destroyed after each task

"It ran code and drafted a change, boxed in. Test ran in a disposable sandbox with no path to the real environment. Nothing applied. Drafting the fix is as far as it goes on its own."

Graduated Autonomy: You Control the Dial

Continuum doesn't ask for full trust on day one. Whether a change gets enforced is always a setting you control:

Action Type	Automation Level
Remove unused permissions	~80%
Tighten security groups	~60%
Modify IAM roles	~20%
Delete resources	0%. Always human. No exceptions.

It starts in learn mode (human in the loop, every recommendation includes full reasoning). You graduate to enforce mode as confidence grows, on your terms.

---

One Trace. Every Claim Verifiable.

Every claim Continuum makes is backed by something you can open:

• "Not reachable from outside" = proven from the environment graph (not asserted)

• "Bug is real" = unit test + result (not inferred)

• Each step has its own evidence, confidence score, and proof artifact

trace_id: 7f3a2b1c-e9d4-4a5f-8c2e-1b3d5f7a9c0e

14:23:01.003  ingestion    Ingested from GuardDuty           12ms
14:23:01.045  scoring      Prioritized: Immediate            32ms
14:23:01.112  dispatch     Dispatched > Red Team agent       67ms
14:23:03.445  red-team     Tool calls: 4 (VPC,IAM,Config,Macie) 2333ms
14:23:05.890  red-team     Verdict: Exploitable (0.95)       2445ms
14:23:05.923  dispatch     Dispatched > Green Team agent     33ms
14:23:08.112  green-team   Remediation plan generated        2189ms
14:25:44.001  human        Approved > Applied                manual

Total machine time: ~7 seconds from ingestion to remediation plan. Human step: manual (you control when). Retention: 90-day audit trail. Sensitive values auto-redacted. W3C trace format.

The system also explicitly separates LLM judgment (qualitative) from deterministic math (quantitative), so you can audit exactly which part was reasoning and which was calculation.

---

What I Liked

After spending time analysing this service across docs, presentations, and demo materials, here's what impressed me:

1. Honest verdicts. The three-valued logic (Exploitable / Inconclusive / Not Exploitable) is refreshing. Most tools hide uncertainty. Continuum surfaces it explicitly with confidence scores. This builds trust.

2. Proof, not assertions. The "same test proves the bug, same test proves the fix" approach is elegant. It removes the "trust me" element from security findings.

3. Correct calibration. The cleanup job example where it downgraded severity from Critical to High because of reachability context is exactly what senior engineers do manually. Automation that calibrates correctly is more valuable than automation that escalates everything.

4. The safety architecture is genuinely well-thought-out. Cedar policies, ephemeral credentials, MicroVM isolation, and the graduated autonomy model feel like they were designed by people who've seen agentic AI go wrong.

5. It doesn't try to be everything. The focus on code vulnerabilities (not CSPM, not SIEM, not identity governance) keeps it sharp.

---

What Concerns Me (Honest Assessment)

1. It's early. The full lifecycle capability is in gated preview. The design partners (Capital One, MongoDB, Rivian, Robinhood) are working with it, but there are no published case studies yet with quantified outcomes. "Works great in controlled demos" and "works great in a 10,000-microservice environment" are different things.

2. The context graph depends on your hygiene. If your AWS Config is incomplete, your tags are inconsistent, or your architecture docs are stale, the graph will have gaps. Continuum is only as good as the data it can reach. Garbage in, garbage out still applies.

3. Multi-cloud and hybrid are unclear. The current integration points are heavily AWS-native (Security Hub, GuardDuty, Inspector, Config, Macie). If you're running significant workloads on GCP/Azure alongside AWS, it's unclear how much context Continuum can build outside the AWS perimeter.

4. Cost and pricing are not published. For a service that runs continuously and makes thousands of API calls per finding (VPC Reachability Analyzer, IAM Access Analyzer, Macie scans), the cost structure matters. Especially for large environments with thousands of resources.

5. The "Inconclusive" verdict is both a strength and a limitation. Yes, honesty is good. But if 40% of your findings come back Inconclusive because runtime context is unavailable, you're still stuck with manual triage for a big chunk of your backlog.

6. No autonomous remediation path. The "Continuum drafts, you ship" principle is the right safety choice, but it also means this doesn't reduce the human review burden for the fix. It reduces discovery and context-gathering time. The PR review bottleneck remains.

7. Model transparency. It uses "multiple frontier models" (including Claude Mythos) but doesn't expose which model made which decision. For regulated environments that need to explain AI decisions to auditors, this could be a gap.

---

What's Not Covered (Gaps in This Post)

For completeness, here's what this blog does NOT cover:

• Pricing and cost modelling: Not yet published by AWS

• Benchmarks against competitors: No head-to-head comparisons with Wiz Defend, Snyk AI, or Orca AI. Would need hands-on access for a fair comparison.

• Multi-account / AWS Organizations setup: How does it work across 200+ accounts? What's the deployment model?

• Regulatory compliance mapping: How does the audit trail map to SOC 2, FedRAMP, or ISO 27001 evidence requirements?

• Performance at scale: No published latency or throughput data for environments with 50K+ resources

• Custom policy authoring: How much can you customise the Cedar policies? Can you write your own rules for the graduated autonomy model?

• Integration depth with third-party scanners: Beyond ingesting findings from Wiz/Snyk/CrowdStrike, does it get full context from them or just alert metadata?

I'll follow up on these as more documentation becomes available and if I get hands-on access to the gated preview.

---

Developer Integration Points

Here's where it fits in your daily workflow:

Tool	Integration
Kiro	Run security reviews directly in your IDE via Kiro Power
Claude Code	Inline security analysis while you code
GitHub / GitLab / Bitbucket	PR scanning with auto-remediation
Amazon Inspector	Correlates runtime vulnerability findings
AWS CloudTrail	Full audit trail of all agent actions
MCP	Standard protocol for agent-to-agent communication

The goal: you never context-switch out of your development flow to deal with security.

---

What's Available Today

Capability	Status
On-demand penetration testing	Generally Available
Pull request code scanning with remediation	Generally Available
Kiro Power and Claude Code plugins	Generally Available
Simulated exploit validation	Generally Available
Threat modeling (STRIDE format)	Public Preview
Continuum for code vulnerabilities (full lifecycle)	Gated Preview

---

Design Partners

Continuum for code vulnerabilities is currently working with select design partners including Capital One, MongoDB, Rivian, and Robinhood across financial services, automotive, and technology sectors. These are named in the official AWS First Call Deck as design partners shaping the product during gated preview.

Note: No published case studies or quantified outcomes are available yet from these partners.

---

The Shift, in One Sentence

Security that reasons about your environment, proves what's real, and drives toward resolution at the speed your code deploys.

No more 3,200-finding Mondays. No more PDF pen test reports that go stale in a week. No more context-switching across six consoles to answer "does this actually matter?"

---

Getting Started

1. Try pen testing today: It's GA. Point it at your app and see what it finds.

2. Enable PR scanning: Shift left without slowing down your team.

3. Explore threat modeling: Feed it a design doc. Get a STRIDE model in minutes.

4. Sign up for the gated preview: Full lifecycle vulnerability management.

Learn more at the AWS Continuum product page and the official announcement blog.

---

My Verdict

AWS Continuum is tackling a real problem that every security team faces. The approach is sound: context graphs, evidence-based verdicts, and human-in-the-loop remediation. The safety architecture is genuinely impressive.

But it's early. The full capability is in gated preview. Pricing is unknown. Multi-cloud support is unclear. And the biggest question, "does this actually reduce Mean Time to Remediate at enterprise scale?", doesn't have a public answer yet.

If you're AWS-native and drowning in findings: Get on the gated preview waitlist. The GA capabilities (pen testing, PR scanning) are worth trying today.

If you're multi-cloud or need proven scale: Watch this space. Wait for the public case studies and pricing.

I'll update this post as more information becomes available.

---

Questions? Disagree with my assessment? Let me know in the comments or find me at the next community event and let's do a chai pe charcha!

---

#security, #generative-ai, #ai-agents, #aws-continuum, #application-security, #developer-tools, #aws #cloudcomputing