I Built the Ambulance.AWS Continuum Is the Road Safety System.

🔗

Part 2 of a series — AI in SecurityPart 1: AI Forensic Investigator — the ambulance. AI that reconstructs a breach after it happens. This is Part 2: AWS Continuum — what you build before you need the ambulance.

A few weeks ago I spent a weekend building an AI forensic investigator — Protocol SIFT — on top of the SANS SIFT Workstation. It reasons over process trees, memory dumps, and login histories simultaneously to reconstruct a breach that already happened. I called it the ambulance of security work. By the time it arrives, something has already gone wrong.

Building it kept making me ask one question: what if the AI had been running on the other end of the timeline? Not investigating the breach after the fact — but finding and closing the vulnerability before the attacker ever got in?

That question got answered with AWS Continuum, this is that other end of the timeline. It's not a scanner, not a dashboard, not another tool that produces a PDF for someone to ignore. It's a continuous, agentic security loop — running at the speed of your CI/CD pipeline — that finds, proves, prioritises, and fixes vulnerabilities before the breach happens.

I've been running the Security Agent capabilities since the March GA. Here's everything you need to understand what Continuum is, why it matters, and exactly how to test all four capabilities yourself.

The Gap That Continuum Was Built to Close

Picture two timelines running in parallel right now, in your environment.

That gap isn't a people problem. It's structural. Development teams ship hundreds of times a day. Security reviews happen quarterly, if budget allows. The average organisation runs a 12-week window of unvalidated attack surface between each pen test cycle — multiplied across every application in the portfolio.

"The floor has been lowered for attackers. The goal is to raise that floor up again."— Neha Rungta, AWS Director of Applied Science, who led the work on Continuum

What AWS Continuum Actually Is

Think of it as a security team that never sleeps, never misses a PR, and already understands your entire codebase — running alongside your developers every single day, not six weeks behind them.

It works in two connected layers. The first layer runs proactive security checks throughout your development lifecycle — catching issues at the earliest, cheapest moment to fix them. The second layer is the continuous remediation engine that takes everything the first layer finds, enriches it with business context, proves what's genuinely exploitable, and drives fixes through your existing process.

The AWS Continuum Security Lifecycle Loop

Layer 1 · AWS Security Agent — Design to Deploy

Design Review

Architecture & docs before code is written

Code Review

Every PR scanned automatically

Threat Model

STRIDE from docs or source

Pen Testing

Real attack chains, on demand

↓

All findings — plus your existing GuardDuty and Security Hub signals — flow into the loop

Layer 2 · Continuum for Code Vulnerabilities — Gated Preview

01 DISCOVER

Ingest everything. Existing backlog from GuardDuty, Security Hub, third-party tools — plus its own fresh scan. One unified picture.

02 PRIORITISE

Score by actual impact. Not CVSS alone. Deployed? Reachable? In a payment flow? It knows the difference.

03 VALIDATE

Prove it before surfacing it. Working exploit built in sandbox. Can't prove it? You don't see it. False positives gone.

04 REMEDIATE

Fix it with a safety net. Fast policy change now. Validated code patch via PR. Blast radius mapped first.

↩ Loops back to the top — every deploy, not quarterly

Every decision explainable. Every action auditable. Every outcome feeds the next cycle.

Inside the Console: What You Actually See

Here's the full setup flow — from first screen to live Agent Space — using screenshots from my own environment.

AWS Security Agent — Proactively secure your applications throughout the development lifecycle

The entry point. AWS Security Agent is now part of AWS Continuum. Find it under Security in your AWS console. This is the agentic layer that covers design-time, development-time, and deployment-time security in one unified platform.

console.aws.amazon.com/securityagent — Set up AWS Security Agent

First screen after opening the console. Create your Agent Space — the container that holds your configuration, users, and test targets. One Agent Space per application you want to test.

AWS Security Agent — Agent Space Configuration

Agent Space setup. Name it after the application you're testing — this is what users see in the web app. The description gives your team scope at a glance without opening settings.

AWS Security Agent — User Access Configuration

Choose your access model. SSO via IAM Identity Center is recommended for teams — users sign in without needing AWS Console access. IAM-only is simpler for a solo POC or quick evaluation.

Agent Spaces — RomAgentSpace

Your Agent Space is live. Created June 23, 2026. From here you launch the web application where all four capabilities are available. Setup to this point took under 10 minutes.

RomAgentSpace — Four capability dashboard

The capability dashboard — your security control plane. Design Review is ready immediately (green tick). Pen Testing needs domain verification. Threat Model and Code Review need repository integration. The status indicators show exactly what's active.

The Four Capabilities: Step-by-Step Testing Guide

Once your Agent Space is live, here is exactly how to activate and run each capability.

1. Penetration Testing

GA — March 31, 2026

Real, multi-step attack chains against your running application. Not a scanner — an agent that executes exploit scenarios, validates every finding through actual exploitation in a sandbox, and delivers reproducible proof with ready-to-implement fixes.

1

Enable and verify your domain

Click Enable penetration test from the dashboard. Enter your target URL and select DNS_TXT (recommended) or HTTP_ROUTE verification. For Route 53 domains in the same AWS account, one-click verification handles it automatically. For other DNS providers: copy the TXT token, add it to your registrar, return to the console and click Verify.

2

Configure scope, authentication, and accessible URLs

Add all target URLs. Add third-party services your app touches — Okta, Auth0, Cognito, Stripe — to Accessible URLs. The agent needs these for authentication flows but will not pen test them. If using Cognito, explicitly add https://cognito-idp.<region>.amazonaws.com. Provide login credentials for authenticated testing — this is where the real signal comes from.

3

Connect GitHub for source code context

Optional but strongly recommended. Source code gives the agent application context that improves attack chain depth and enables automatic fix PRs. GitHub app → select repositories → enable Pentest remediation enabled for auto-raised fix PRs.

4

Create and run the test

From the web application: Penetration Tests → Create → select verified domain → optionally upload context docs (design docs, API specs) → enable automatic code remediation → Create and execute. Tests run for several hours. Monitor progress in the logs tab.

5

Review findings and remediate

Each finding includes: severity rating, reproducible attack path, business impact analysis, and a ready-to-implement code fix. Every finding is sandbox-validated — no unsubstantiated alerts. In Kiro IDE: "help me remediate my findings" pulls findings into your workspace and opens a bugfix session.

⚠️ Worth knowing: Public marketing sites return minimal findings. The real value is against authenticated applications with user roles, session management, and API CRUD operations. Plan your first meaningful test accordingly.

2. Design Review

Preview

Upload your architecture documents, ADRs, or Confluence pages. Get security gaps back before a line of production code is written — where fixing costs the least and matters the most.

1

No domain verification needed — ready immediately

Design Review shows "Ready" by default. If it shows "Needs setup", simply click Add users to grant team access. That's the only prerequisite — the fastest capability to activate.

2

Upload your design documentation

Accepted: architecture diagrams (PNG, PDF), system design docs (DOCX), Confluence pages via integration, ADRs, and data flow diagrams. The more specific you are about data flows, trust boundaries, and external integrations, the more actionable the output. Vague documentation produces vague findings.

3

Set your security requirements baseline

Define your organisation's standards in plain English, or use AWS defaults. These become the policy the agent reviews every design against — consistently, every time, without relying on individual reviewer knowledge.

4

Review and act on findings

Output: security gaps mapped to specific design elements, recommended mitigations, references to relevant requirements, and priority ranking by risk impact. At this stage a finding costs a design conversation to fix. At production it costs a pen test finding, a fix PR, and a deployment cycle.

3. Threat Modeling

Preview — New at Summit NYC

Automated STRIDE analysis from your design documents or source code. What used to require a specialist and a workshop now runs on every significant architecture change — output in industry-standard STRIDE format.

1

Enable and connect your source

Click Enable threat model. Connect your GitHub, GitLab, or Bitbucket repository via the integration picker, or prepare design documents for upload. You can run from source code, design documents, or both.

2

Choose your input — docs, source, or both

Source code alone may miss trust boundaries not yet reflected in implementation. Design documents alone may miss what the code actually does. For the most grounded output, provide both. Set your security requirements before running the first model.

3

Review the STRIDE output

The agent returns: a component map with trust boundaries and data flows; threats per STRIDE category — Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege; recommended mitigations per threat; and open assumptions flagged for human validation.

4. Code Review

Preview

Deep, context-aware security analysis of your entire codebase or individual PRs — automatically, as they're raised. Analysis against your specific security requirements, OWASP standards, and organisation-defined policies, with findings surfaced inline in the developer's workflow.

1

Enable and connect your repository

Click Enable code review. Select your integration from the picker — GitHub, GitLab, Bitbucket, or Confluence for documentation context. For PR scanning with automatic fix PRs, write access is required so the agent can raise pull requests.

2

Add a filtering.md to reduce noise

Create a filtering.md file in your repository root. Exclude /test/, /mocks/, /fixtures/. Add context hints: "Payment handling in /payments/ — PCI-DSS scope." This dramatically reduces false positives without any other configuration change.

3

Run a full repository scan first

Code Review → Full Repository Scan → select repository and branch → Start Scan. This establishes a baseline of your accumulated security risk. The first full scan is your discovery moment — you'll see things that built up over time that incremental PR reviews would have caught earlier.

4

Enable PR scanning for continuous coverage

Code Review → Settings → Pull Request Scanning → ON. Start with Comment only mode — findings appear inline without the agent changing any code. Move to Auto-raise fix PR once you've validated the output quality and updated your PR review process accordingly.

5

Remediate from your IDE

In Kiro IDE: "help me remediate my findings". Downloads findings, prioritises the most critical, opens a bugfix spec session without leaving your development environment. Claude Code plugin surfaces findings and fix suggestions inline as you work.

AWS Security Agent — Select integration to add

The integration picker. GitHub and GitLab for source repositories, Bitbucket for Atlassian-native teams, Confluence for design documentation. Each integration adds more context to the agent's security reasoning — and creates more touchpoints where security runs automatically rather than by human discipline alone.

The Trust Model: Learn Mode → Enforce Mode

Autonomy earned, not assumed

The most important design decision in Continuum is how it handles the question every security team asks before deploying automated remediation: how much can it do without asking?

The answer is deliberate and incremental. Continuum starts fully supervised and earns the right to act alone — category by category, as your confidence in its judgement grows.

Learn Mode (default)

Every recommendation surfaces with full reasoning and a rollback path. You review it. You approve or dismiss it. The agent executes what you approve. This is always where you start.

→

Enforce Mode (when you're ready)

Remediation becomes increasingly automated within the risk categories and guardrails you define. Graduate categories one at a time. Your payment service patches might stay in learn mode permanently — that's a valid call.

Every decision Continuum makes is explainable — you can see why it recommended a specific action. Every action is auditable — a log of what ran, when, and what changed. Every outcome feeds back into the next cycle so the system improves continuously.

Honest Caveats

The full Continuum loop is gated preview. The four Security Agent capabilities are available now with a 2-month free trial. The Discovery → Prioritisation → Validation → Remediation engine requires applying for gated preview access via AWS.

Public websites are low-value pen testing targets. Use a public site to learn the workflow. The test that matters is against an authenticated app with user roles and business logic.

Continuum does not replace human red teams. Social engineering, physical security, insider threat, and compliance sign-off still require human practitioners. Continuum handles continuous application-layer coverage — the volume work no human team can sustain at scale.

Least privilege on the Agent Space service role from day one. Apply it before you run your first test. An over-permissioned role expands the blast radius of any misconfiguration.

Code review and pen testing have non-overlapping coverage. Code review finds what static context reveals. Pen testing finds what only runtime attack execution exposes. You need both — they're complementary, not redundant.

Where to Start

1

Today — no application required

AWS Security Agent console → Create Agent Space → configure IAM Identity Center SSO or IAM-only access → connect your repository → enable Design Review (ready immediately) → verify your domain via DNS TXT for Pen Testing → launch the web application. Two-month free trial for new customers.

2

Apply for the Continuum gated preview

Visit aws.amazon.com/security-agent and apply. Start in learn mode against a codebase with existing GuardDuty findings — the Discovery phase will have the most to work from on day one.

3

Test against an authenticated application

The signal that matters comes from apps with login flows, user roles, session management, and API CRUD operations. That's where the attack chain capability surfaces findings no single-dimension scanner would catch.

The ambulance will always matter.The goal is fewer emergencies.

I built the reactive end — AI that investigates after a breach. Continuum is the proactive end — AI that prevents one. Every deploy. Not quarterly.

Try AWS Continuum — 2 Month Free Trial →

AWS ContinuumAWS Security AgentDevSecOpsApplication SecurityPenetration TestingCloud SecurityThreat ModelingSTRIDEAWS Summit NYC 2026Code ReviewRGI Consulting