AWS Continuum’s developer-tool integration is already real for Kiro and Claude Code, but the reported August 5 partnership with OpenAI and a native Codex connection does not appear in AWS’s current product documentation or launch record. SiliconANGLE reported that AWS would bring Continuum into Claude Code, OpenAI Codex and Kiro; AWS’s own material shows a narrower, earlier rollout announced on June 17, 2026, with Kiro and Claude Code named explicitly and a general Model Context Protocol route offered for other AI IDEs.
That distinction changes the practical takeaway. Organizations can deploy AWS Security Agent’s Continuum-era scanning workflow in Kiro or Claude Code today, subject to the service’s availability and preview status. They should not treat a dedicated Codex integration as released—or even formally announced by AWS—until AWS documents it.
AWS launched Continuum for code vulnerabilities in gated preview on June 17 at AWS Summit New York. The service is intended to take vulnerability findings through discovery, prioritization, validation, and remediation, using account configuration, permissions, network topology, deployed assets, and business context to decide whether a flaw is worth escalating.
The same day, AWS published a separate update for AWS Security Agent, which it says is now part of AWS Continuum. That announcement explicitly introduced a Kiro Power and a Claude Code plugin. AWS said developers could run code reviews and threat models from their IDE or command line, receive results inline, and bring validated findings back into the workspace for remediation.
AWS’s current documentation remains equally specific: “Run AWS Security Agent code security scans directly from your IDE using Kiro or Claude Code.” The supported-environment list names Kiro, using the AWS Security Agent Power, and Claude Code, using the AWS Security Agent plugin. It does not name OpenAI Codex.
This is more than a wording issue. AWS uses “integration” in the documentation to mean an installable Kiro Power or Claude Code plugin with prescribed setup, capabilities, and lifecycle behavior. A generic connection through MCP is a different level of support: technically useful, but not necessarily packaged, tested, or supported in the same way as a first-party plug-in.
It does not confirm that Codex can invoke AWS Continuum or AWS Security Agent through a dedicated connector. Bedrock model access, agent observability, and code-security tooling are separate AWS product surfaces, often managed by different permissions, billing constructs, and control planes.
Codex also supports MCP servers, according to OpenAI’s developer material. That makes a manual Continuum connection technically plausible because AWS publishes an MCP server for Security Agent. But plausibility is not a launch announcement. AWS has not added Codex to the Security Agent IDE integration page, published Codex-specific installation instructions, or described what functionality would work through Codex.
For IT teams, the safe reading is straightforward: Codex users may be able to configure the AWS MCP server themselves if Codex’s MCP environment supports the necessary local process, credentials, and permissions. They should plan that as a custom MCP deployment, validate it in a non-production AWS account, and avoid representing it internally as an AWS-supported Codex integration.
On first use, the setup can create or reuse an Agent Space, create an IAM service role, and create an S3 bucket following the naming pattern
That approach means the editor integration is not a lightweight local linting extension. It is an AWS-account integration that transmits source code to AWS services and provisions infrastructure. Security teams will need to decide which repositories are eligible, whether proprietary or regulated code can be copied into this processing path, and which AWS accounts and Regions are permitted.
The required local permissions are broad enough to deserve a dedicated review. AWS lists permissions to create IAM roles and inline policies, create and write to S3 buckets, create Agent Spaces, start code-review jobs, read findings, and start automated remediations. Giving those rights to a developer’s default workstation identity may conflict with least-privilege policies, particularly in accounts where developers can access production-adjacent resources.
A better rollout is to use a narrowly scoped developer role or AWS IAM Identity Center permission set, pre-provision the required resources where possible, and isolate scanning into a security tooling account. AWS’s automatic setup reduces friction, but it also makes it easier for an individual developer to create a new code-handling path before governance has caught up.
That is a useful direction for teams buried under static-analysis results. Traditional code scanners can identify a dangerous pattern without knowing whether the code is reachable, whether a compensating network control blocks it, or whether the vulnerable component even ships. Continuum proposes to rank findings using that operational context, rather than treating every CVE-like signal as equivalent.
AWS has also said Continuum begins in a human-in-the-loop “learn mode,” with each recommendation carrying reasoning. Customers can move toward enforcement as they define acceptable categories and risk profiles. The company says remediation can include code patches, policy changes, or network changes, with rollback information where feasible.
The operational caveat is substantial: a sandbox proof establishes that AWS’s constructed test environment can exploit a condition; it does not automatically prove the same outcome in every production dependency chain, identity boundary, or business workflow. Conversely, a failed automated validation can be caused by incomplete environmental context. The product may make triage much better, but it cannot safely replace change management, peer review, or production testing.
The result is that a security architect searching for “AWS Continuum IDE integration” lands in the AWS Security Agent documentation, configures
AWS also draws an important availability line. Continuum for code vulnerabilities remains in gated preview, while AWS Security Agent penetration testing is generally available and code review and threat modeling have differing preview states. A feature that looks like one unified agentic-security product is, in practice, a mix of maturity levels and access models.
For organizations evaluating the service, the immediate decision is therefore narrower than the headline suggests: use the documented Kiro or Claude Code path only after approving its IAM and source-code handling model; treat Codex as an MCP experiment unless AWS publishes a formal integration; and retain human approval for every remediation that can alter code, identity policy, or network exposure.
AWS shipped the Kiro and Claude Code path on June 17
AWS launched Continuum for code vulnerabilities in gated preview on June 17 at AWS Summit New York. The service is intended to take vulnerability findings through discovery, prioritization, validation, and remediation, using account configuration, permissions, network topology, deployed assets, and business context to decide whether a flaw is worth escalating.The same day, AWS published a separate update for AWS Security Agent, which it says is now part of AWS Continuum. That announcement explicitly introduced a Kiro Power and a Claude Code plugin. AWS said developers could run code reviews and threat models from their IDE or command line, receive results inline, and bring validated findings back into the workspace for remediation.
AWS’s current documentation remains equally specific: “Run AWS Security Agent code security scans directly from your IDE using Kiro or Claude Code.” The supported-environment list names Kiro, using the AWS Security Agent Power, and Claude Code, using the AWS Security Agent plugin. It does not name OpenAI Codex.
This is more than a wording issue. AWS uses “integration” in the documentation to mean an installable Kiro Power or Claude Code plugin with prescribed setup, capabilities, and lifecycle behavior. A generic connection through MCP is a different level of support: technically useful, but not necessarily packaged, tested, or supported in the same way as a first-party plug-in.
Codex can use Bedrock, but that is a separate AWS relationship
OpenAI does now document a way to configure Codex with Amazon Bedrock. Its help documentation describes using Amazon Bedrock credentials and AWS’s implementation of the Responses API, including support for the Codex desktop application and VS Code extension. That confirms an AWS–Codex deployment path exists.It does not confirm that Codex can invoke AWS Continuum or AWS Security Agent through a dedicated connector. Bedrock model access, agent observability, and code-security tooling are separate AWS product surfaces, often managed by different permissions, billing constructs, and control planes.
Codex also supports MCP servers, according to OpenAI’s developer material. That makes a manual Continuum connection technically plausible because AWS publishes an MCP server for Security Agent. But plausibility is not a launch announcement. AWS has not added Codex to the Security Agent IDE integration page, published Codex-specific installation instructions, or described what functionality would work through Codex.
For IT teams, the safe reading is straightforward: Codex users may be able to configure the AWS MCP server themselves if Codex’s MCP environment supports the necessary local process, credentials, and permissions. They should plan that as a custom MCP deployment, validate it in a non-production AWS account, and avoid representing it internally as an AWS-supported Codex integration.
The integration sends source archives into the customer’s AWS account
The mechanics deserve more scrutiny than the promotional language about scanning “without leaving the editor.” AWS’s IDE documentation says the Security Agent MCP server packages local source code into a ZIP archive and uploads it to an S3 bucket automatically provisioned in the customer’s AWS account. It then calls the Security Agent API, polls for results, and returns findings with code locations, severity ratings, and remediation suggestions to the IDE.On first use, the setup can create or reuse an Agent Space, create an IAM service role, and create an S3 bucket following the naming pattern
security-agent-scans-{account}-{region}. AWS says uploaded source archives have a 30-day automatic-expiry lifecycle.That approach means the editor integration is not a lightweight local linting extension. It is an AWS-account integration that transmits source code to AWS services and provisions infrastructure. Security teams will need to decide which repositories are eligible, whether proprietary or regulated code can be copied into this processing path, and which AWS accounts and Regions are permitted.
The required local permissions are broad enough to deserve a dedicated review. AWS lists permissions to create IAM roles and inline policies, create and write to S3 buckets, create Agent Spaces, start code-review jobs, read findings, and start automated remediations. Giving those rights to a developer’s default workstation identity may conflict with least-privilege policies, particularly in accounts where developers can access production-adjacent resources.
A better rollout is to use a narrowly scoped developer role or AWS IAM Identity Center permission set, pre-provision the required resources where possible, and isolate scanning into a security tooling account. AWS’s automatic setup reduces friction, but it also makes it easier for an individual developer to create a new code-handling path before governance has caught up.
“Validated” findings are AWS’s central claim—and still need human review
Continuum’s most consequential promise is not the IDE button. It is the assertion that the service can reduce false positives by building a reproducible exploit in an isolated sandbox before recommending a fix. AWS says it examines whether the affected component is deployed, reachable, on a production path, and meaningful in the customer’s specific environment.That is a useful direction for teams buried under static-analysis results. Traditional code scanners can identify a dangerous pattern without knowing whether the code is reachable, whether a compensating network control blocks it, or whether the vulnerable component even ships. Continuum proposes to rank findings using that operational context, rather than treating every CVE-like signal as equivalent.
AWS has also said Continuum begins in a human-in-the-loop “learn mode,” with each recommendation carrying reasoning. Customers can move toward enforcement as they define acceptable categories and risk profiles. The company says remediation can include code patches, policy changes, or network changes, with rollback information where feasible.
The operational caveat is substantial: a sandbox proof establishes that AWS’s constructed test environment can exploit a condition; it does not automatically prove the same outcome in every production dependency chain, identity boundary, or business workflow. Conversely, a failed automated validation can be caused by incomplete environmental context. The product may make triage much better, but it cannot safely replace change management, peer review, or production testing.
Continuum’s product naming is still doing customers no favors
Independent reporting from InfoQ has already flagged an avoidable source of confusion: AWS Security Agent is presented as part of AWS Continuum, while Security Agent keeps its own product page, documentation, console objects, prices, and named IDE integrations. AWS describes Security Agent penetration testing and code scanning as Continuum penetration testing and Continuum code scanning, while other functions remain framed in Security Agent terminology.The result is that a security architect searching for “AWS Continuum IDE integration” lands in the AWS Security Agent documentation, configures
securityagent API permissions, creates an Agent Space, and installs an MCP server named awslabs.security-agent-mcp-server. That may all be deliberate product consolidation, but it is not a clean rebrand.AWS also draws an important availability line. Continuum for code vulnerabilities remains in gated preview, while AWS Security Agent penetration testing is generally available and code review and threat modeling have differing preview states. A feature that looks like one unified agentic-security product is, in practice, a mix of maturity levels and access models.
For organizations evaluating the service, the immediate decision is therefore narrower than the headline suggests: use the documented Kiro or Claude Code path only after approving its IAM and source-code handling model; treat Codex as an MCP experiment unless AWS publishes a formal integration; and retain human approval for every remediation that can alter code, identity policy, or network exposure.
References
- Primary source: siliconangle.com
Published: 2026-08-05T23:06:26+00:00
AWS partners with Anthropic and OpenAI to bring Continuum into coding tools - SiliconANGLE
AWS partners with Anthropic and OpenAI to bring Continuum into coding tools - SiliconANGLE
siliconangle.com
- Related coverage: aws.amazon.com
Introducing AWS Continuum: Security at machine speed | AWS Security Blog
What we believe We’ve been thinking deeply about enterprise security. The operating model that served us for the past decade (collect telemetry, store it, query it, build dashboards to watch it) is no longer keeping pace. We need to shift to the new world: telemetry, context, reasoning, and...aws.amazon.com - Related coverage: infoq.com
AWS Continuum to Enable Agentic Code Security for Enterprises - InfoQ
Amazon Web Services has recently introduced AWS Continuum, a new integrated security platform to automate the discovery, enforcement, and remediation of security issues across codebases, dependencies,www.infoq.com
- Related coverage: aws.amazon.com
Introducing AWS Continuum for security at machine speed - AWS
Discover more about what's new at AWS with Introducing AWS Continuum for security at machine speedaws.amazon.com
- Related coverage: docs.aws.amazon.com
OpenAI - Amazon Bedrock
The following OpenAI models are available in Amazon Bedrock:docs.aws.amazon.com
- Related coverage: id.investing.com
Skyhawk Security integrates dengan AWS Continuum untuk keamanan cloud Oleh Investing.com
Skyhawk Security integrates dengan AWS Continuum untuk keamanan cloudid.investing.com - Related coverage: docs.aws.amazon.com
OpenAI Agents - Amazon Bedrock AgentCore
This page explains how to instrument an OpenAI Agents agent, how spans are identified, and how evaluation fields are extracted. - Related coverage: docs.anthropic.com
CLI reference - Claude Code Docs
Complete reference for Claude Code command-line interface, including commands and flags.docs.anthropic.com - Related coverage: docs.anthropic.com
What is the Model Context Protocol (MCP)? - Model Context Protocol
docs.anthropic.com
- Related coverage: developers.openai.com
OpenAI Developers
Docs and resources to help you build with, for, and on OpenAI.
developers.openai.com
- Related coverage: developers.openai.com
ChatGPT use cases
Explore example workflows, teams, and tasks you can take on with ChatGPT.
developers.openai.com
- Related coverage: help.openai.com
Configure Codex with Amazon Bedrock | OpenAI Help Center
help.openai.com
