AWS Wires Continuum Security Into Claude Code, Codex, and Kiro — While Models Still Do the Writing

What Continuum Actually Does

Continuum is not a traditional static scanner. It is an agent-team loop architecture — an orchestration layer that selects different frontier models for different stages of the security process. AWS describes this orchestration as the hard part. The models advance rapidly on their own. The problem is the machinery connecting them to a customer's real environment.

When a finding comes in, Continuum prioritizes it against the customer's AWS environment: account configurations, AWS Identity and Access Management (IAM) policies, network topology, and exposure surfaces. A vulnerability in code that never reaches a public path ranks below one sitting on an internet-facing endpoint.

Continuum then validates exploitability in a sandbox to confirm the flaw is real, which cuts down on false positives before anything reaches a developer's screen. SiliconANGLE reported that the service builds a working exploit in that sandbox as part of that confirmation step.

The service addresses the full software lifecycle. For code already deployed, it works through existing findings across the environment.

For new code being written, the planned IDE integrations will feed security-validated suggestions back to the coding assistant in real time.

The full Continuum suite also includes penetration testing, code scanning, and threat modeling capabilities, each in various preview states. The code vulnerability feature is the one gaining the Anthropic and OpenAI integrations.

Why the IDE Integration Changes the Security Model

Enterprise security has historically run on a relay: developers write code, a scanner flags issues, a security team triages the list, someone prioritizes against business context, another team validates, and eventually a fix goes back to the developer. That cycle can stretch across days or weeks in complex environments. The traditional process — write, scan, triage, prioritize, fix, rescan — collapses into a single outcome: the code suggestion itself. That is the architectural shift AWS is describing.

The risk this addresses is real. Frontier models can now identify vulnerabilities and reason through multi-step attack paths that would take a human security team weeks to trace. That capability surfaces more findings, faster. Without orchestration that understands your environment, those findings risk becoming noise — more complexity, and the need to determine which ones matter most.

The risk this introduces is equally real. Continuum reads IAM policies, network topology, and account configurations to rank findings. That means the service needs access to sensitive environment data. Trust is graduated and set by the customer. Continuum starts by proposing actions; a human approves. Customers decide which actions it can take autonomously, within guardrails they define and can change at any time.

Mike Johnson, CISO at Rivian, described the result this way: "AWS Continuum connects source code with enterprise knowledge, allowing teams to accurately pinpoint security vulnerabilities and verify that flagged issues are truly meaningful. This shortens what really matters: timeline to fix serious vulnerabilities."

Current design partners include Capital One, MongoDB, Rivian, and Robinhood. Access remains gated and requires a request.

The Harness Problem Has Infrastructure Consequences

AWS is making a pointed argument with Continuum. It is not just selling a security tool. It is arguing that managing orchestration complexity is infrastructure work that AWS should absorb. Teams that build their own integration layers across models, agents, and developer environments face a maintenance problem every time the model landscape shifts. Security and governance controls break. Teams rebuild them. The cycle repeats.

AWS's own blog notes that customers are implementing "shadow infrastructure" to manage integration layers across models and tools — meaning unofficial, team-built plumbing that fills gaps the official stack does not cover. That framing is AWS's diagnosis of the problem Continuum is meant to solve.

That argument has a cost implication. Accepting it means consolidating vulnerability triage onto AWS-managed orchestration. Teams currently using point scanners, third-party SAST tools, or homegrown pipelines need to evaluate what they own, what overlaps, and what the access grants Continuum requires look like against their security baseline.

Third parties are already building on Continuum. Skyhawk Security said in late July it was feeding Continuum findings into simulated attacks against digital twins of customer cloud environments, testing whether an attacker could actually weaponize a given flaw.

What Security and Platform Leaders Should Do Now

The IDE integrations have no confirmed release date. What exists today is the gated preview of Continuum for code vulnerabilities, available by request at aws.amazon.com/continuum.

Three decisions are worth making before the integrations ship. First, map the current vulnerability workflow end to end — who receives findings, how they are prioritized, and how long the fix cycle actually takes. Continuum's value proposition depends on that cycle being slow and noisy. If it is not, the case weakens. If it is, the gap is measurable.

Second, assess the access scope Continuum would need. It reads IAM policies and network topology to contextualize findings. That access needs to align with your least-privilege standards before any production connection is made.

Third, if your teams are already writing code inside Claude Code or Codex, watch the integration timeline closely. If and when it ships, the security scan will happen inside the environment developers already trust. That is a governance change, not just a tooling addition. Deciding in advance what Continuum is allowed to act on autonomously — and what requires human approval — is the setup work that determines whether the guardrails hold.