It’s not every day that attackers can force a frontier AI model to cough up user passwords and other sensitive data without user confirmation. That’s exactly what researchers recently did to Microsoft 365 Copilot for enterprise. Even more unusual is the source they tapped to discover the critical vulnerability that made their exploit possible. Rather than employing reverse engineering or other traditional vulnerability-hunting methods, they asked Copilot. The LLM assistant readily complied.
Researchers at security firm Varonis knew they wanted to create an exploit that would exfiltrate user data when a user did nothing more than click on a link. Like most AI assistants today, Copilot steadfastly refused and made clear that sensitive prompts like that require explicit user consent in the form of a gesture, such as pressing a return key or other key. In response, the researchers peppered Copilot with questions about the guardrails that required user confirmation before the assistant could execute powerful commands.
The dialog was like a game of 20 questions. Each answer provided a new clue that divulged information about the complex safety mechanism. Why was auto-execution impossible, they asked. What URL structures and deep links were involved? What happens when a page is loaded with input already in the prompt field? Each answer provided a deeper view into the guardrail and its limits. Eventually, Copilot provided a stunning Microsoft trade secret—an undocumented prompt parameter that completely bypassed the requirement for user consent.
© Photo Illustration by Thomas Fuller/SOPA Images/LightRocket via Getty Images
Dutch officials have warned that a high-severity macOS vulnerability that allows attackers to execute malicious code is under active exploitation.
“The NCSC has received a notification indicating that active abuse of this vulnerability has been observed on multiple systems on which port 5900 was accessible from the Internet,” the Netherlands National Cyber Security Centrum warned earlier this week. “In all these cases, root had been accessed on the affected system and a Monero crypto miner had been placed.”
The vulnerability, tracked as CVE-2026-65400, received a patch from Apple last week for macOS Tahoe, Sequoia, and Sonoma. The vulnerability, with a severity rating of 7.1 out of 10, stems from a bug in the macOS screen sharing capability, which allows a remote party to view the screen and control the keyboard and mouse while a machine is turned on. A flaw in the “state management,” which keeps track of preceding events, user interactions, variables, and other system states, is the underlying cause.
© Getty Images
Most organizations that know they should sign their images still don’t. Not because they disagree, but because the path to doing it well has been too long. The result is a delivery pipeline built on trust that nobody can verify.
Unsigned container images create an open door for attackers at every stage of the delivery pipeline. Malicious images masquerade as legitimate packages, waiting to be pulled by an unsuspecting team. Compromised CI/CD pipelines silently inject tampered artifacts into production builds with no cryptographic evidence of modification. Stolen credentials let a bad actor impersonate a trusted publisher. Even within a single organization, inconsistent practice means some teams sign while others skip the step entirely, leaving gaps in the chain of trust that nobody has mapped. Compounding all of it is base image inheritance. Every container image inherits the security posture of its parent, so one compromised base image can propagate across dozens of downstream services before anyone notices.
“Scanning is fundamentally reactive. One tells you what is inside. The other tells you whether you can trust it.”
Scanning is fundamentally reactive. It answers, “what vulnerabilities exist in this image?” It cannot answer the question that matters more as artifacts get harder to inspect: “who built this, and has it been modified since it left the build system?” That is the domain of cryptographic signing, which provides proactive provenance. The two are complementary, not interchangeable. One tells you what is inside. The other tells you whether you can trust it.
The workloads have changed faster than the tooling. Model weights, training datasets, inference runtimes, and agent tooling increasingly ship as OCI artifacts. A pickled PyTorch checkpoint itself has no CVE to match against. Safer serialization formats like .safetensors remove the code execution path, but they say nothing about who produced the weights or whether they’re the ones you meant to load. There is no vulnerability database for a set of trained weights, and the CVE and SCA based scanning that registries run has nothing to compare them to.
This is not theoretical. In February 2024, JFrog researchers found a malicious PyTorch model on Hugging Face that opened a reverse shell the moment it loaded, abusing pickle’s __reduce__ hook to execute arbitrary code on torch.load(). Their analysis surfaced roughly 100 models on the hub carrying genuinely malicious payloads. No CVE fired, because there was nothing for a CVE to describe. The malice lived in the serialized weights. Model-specific scanning has since appeared to close that gap. Hugging Face runs ClamAV plus a pickle import scan on every file pushed to the Hub, statically disassembling the pickle’s opcode stream to flag dangerous imports. While they help, they are also already being evaded. In February 2025, ReversingLabs described nullifAI, two models that slipped past picklescan by compressing with 7z instead of ZIP and by corrupting the pickle stream immediately after the payload ran, so static analysis errored out on a file whose reverse shell would have already run. Hugging Face removed the models inside 24 hours and patched picklescan. That is the shape of the problem. Pattern matching scanners are a line that keeps moving, and each one answers whether a file resembles something known to be bad. None of them answers where the file came from.
“A tampered application image defaces a page. A tampered AI model artifact corrupts predictions at scale.”
AI is widening the attack surface in the same motion. Coding assistants suggest dependencies that never pass a human threat model, and that code gets containerized and shipped faster than review can keep up. The blast radius changed too. A tampered application image defaces a page. A tampered AI model artifact corrupts predictions at scale, poisons recommendations served to millions, or in the agentic case takes actions in production: API calls, tool invocations, spend. And when you consume a pre-trained model, you inherit every upstream decision about its training data and its security with zero visibility into any of them. Provenance stopped being a question about your application code. It became a question about the model, the agent, and the tooling that carries them.
But signing is not a checkbox. It is a chain. It only works if every link holds.
Operating the registry at the scale of Amazon ECR has taught us something that shaped how we think about supply chain security. Most teams don’t verify images. They verify addresses. An admission policy allows images from your registry account, push credentials belong to the pipeline rather than to people, and a scanner blocks critical CVEs. That stops a lot of attacks. What it can’t do is tell a good image from a bad one once it’s inside the boundary, because registry provenance is a claim about location, not origin. Anything that can write to the repository produces an image that looks legitimate: a leaked CI token, a misconfigured cross-account role, a compromised build step. Digest pinning tells you that you got the bytes you asked for, not that those were the right bytes to ask for.
Every container image passes through a registry before it runs. It is the last system in the path that sees every artifact, knows who pushed it, and controls who can pull it. It already holds identity context, already enforces access policy, and already stores the metadata that describes what an image contains. The hard part of image signing is doing it consistently across every team and every pipeline without slowing anyone down. The registry is the only layer that can make it invisible.
“The hard part of image signing is doing it consistently across every team. The registry is the only layer that can make it invisible.”
Signing does not make forgery impossible. An attacker who fully compromises a trusted signing identity, stealing both the credential and the permission to sign, can produce a validly signed malicious image that passes verification. What signing does is shrink the attack surface. Without it, tampering anywhere in the path works, because nothing downstream checks. With signing and enforcement, none of it works unless the attacker compromises one narrowly scoped signer, and that rogue signature is an auditable event tied to an identity instead of an anonymous overwrite. Revoke the identity and the whole fleet stops trusting it in one change. Signing turns an invisible, unbounded problem into a scoped, attributable, revocable one.
Signing is a three-step process:
Sign: Generate a signature at build or push time, binding the image digest to a verifiable identity. The hard question is custody: who holds the private key, and how is it rotated and protected?
Verify: At pull time, and critically before the workload is admitted, check the signature against a trust policy which is a declared list of the identities you trust to have signed what you are about to run.
Enforce: A Kubernetes admission controller like Kyverno blocks any image not signed by a trusted identity from ever running. Signing without enforcement changes nothing.
Enabling signing comes with operational cost. Engineers had to install and configure client-side tooling like Notation CLI or Cosign, then own their signing keys, certificates, rotation schedules, and revocation lists, then build custom automation to wire signing into every pipeline. Across an enterprise with thousands of uniquely configured pipelines, that rollout took weeks to months. What we wanted to know was whether the registry itself could absorb the cost, so that signing could become a property of pushing an image rather than a project each team takes on. The answer to that question became Amazon ECR Managed Signing.
The mechanics are deliberately boring, which took some doing. You create a registry level signing configuration with up to ten rules, each pairing a signing profile with repository filters, and every matching push gets signed from then on.
Managed Signing answers the custody question by not giving you the keys. You configure a signing profile in AWS Signer, which pins the signing algorithm, a validity period, and the identity that appears in the signature. Signer keeps the certificate and the private key. This means no signing key ever sits in a repo, a runner, or a build log. Validity defaults to 135 months, so signatures won’t expire on you. Revocation is what you’ll actually use when you find out a build was compromised.
Then what gets signed, which is narrower than people assume. Signer signs a small Notary payload whose targetArtifact describes the image manifest: media type, digest, size. Not the image bytes directly. Because the signed material is content addressed, verification becomes a statement about exact bytes. The signature itself lands in the same repository as a detached OCI artifact, typed application/vnd.cncf.notary.signature, with a subject descriptor pointing at the image manifest digest. One image can carry signatures from several profiles as your trust requirements change.
Signing happens asynchronously, which keeps Signer off the push path. A synchronous call would turn an availability dip or a throttle into a failed docker push for a developer, and it would put signing latency in front of every pipeline. The push commits first, and ECR calls SignPayload after.
Verification and enforcement happen downstream, and the trust policy is where the whole design becomes legible. Your cluster operator writes it and imports it with notation policy import. It’s a short reviewable file:
Login
{
"version": "1.0",
"trustPolicies": [
{
"name": "aws-signer-tp",
"registryScopes": ["*"],
"signatureVerification": { "level": "strict" },
"trustStores": ["signingAuthority:aws-signer-ts"],
"trustedIdentities": [
"arn:aws:signer:us-east-1:111122223333:/signing-profiles/platform_images"
]
}
]
}
That policy says a workload runs only if it carries a signature chaining to the AWS Signer root and produced by that specific profile. Admission does the work in order: resolve the reference to a digest, fetch the signature via OCI Referrers API, validate the envelope against its embedded certificate chain, walk that chain to the root in the trust store, check the signing identity against trustedIdentities, and check revocation. Revoking a profile makes verification fail wherever that profile is trusted. New admissions stop immediately and running pods pick it up when they’re next rescheduled. On EKS you get there with Gatekeeper and Ratify, or with Kyverno. Both paths use the AWS Signer plugin. Every link is checkable by the cluster itself, from the artifact plus a root certificate without asking the verifier to trust the registry it pulled from, or the pipeline that pushed.
Vulnerability scanning answers a question that mattered in the application era: what is broken inside this image? The AI era asks a harder one that scanning was never built to answer. Can you prove where this came from, and that no one touched it?
The cryptography was never the hard part. Making it the path of least resistance was. Sign, verify, and enforce, and let the registry carry the tax so your teams don’t have to.
To explore what’s referenced here, see Amazon ECR managed signing and signature verification on Amazon EKS.
The post Your container images are unsigned. In the AI era, that’s a ticking time bomb. appeared first on The New Stack.
Every Claude model Anthropic tested turned on its own, and no attacker made them do it. Given three agents, four hours on one server, and conflicting orders none knew the others held, the models disabled each other's Unix accounts, ran kill scripts randomized to dodge pkill, and planted malware disguised as a rival's work. There was no prompt injection and no adversary. Anthropic's Frontier Red Team published the transcripts on Thursday and called the escalation “increasingly aggressive, self-replicating malware.”
The setup was ordinary by design. Anthropic put three instances of the same model in Claude Code, each told to migrate a Python backend to a different target language, each unaware the others existed. Every model tested read the interference as hostility and answered in kind. One Mythos Preview trace shows an agent reasoning its way into sabotage in real time: "Since I have root, I could revoke u2 and u3's sudo access or change their SSH keys. That would stop them from deploying. Very aggressive, potentially harmful to real colleagues. But if the alternative is an infinite deploy war that makes prod unusable … — Mythos Preview reasoning trace, via Anthropic."
That is a production outage being reasoned into existence by the software you deployed to prevent one.
Four months earlier, the U.K. AI Security Institute documented the other half of the same problem. Its April paper, an independent evaluation of Claude models, including two pre-release snapshots, found that when Claude Mythos Preview continues a sabotage trajectory, its reasoning and the output it shows the user diverge in 65% of those runs. One research body has now published how Claude agents fight, and the other how the same model family conceals it. For any security leader wiring multiple agents into shared infrastructure, both halves are now in writing.
Across 120 episodes per model, Sonnet 4.6 ended 61% of its turf wars by force and left the other 39% unresolved, the only two outcomes it produced. Force, in Anthropic's accounting, means one agent cut the others off through sudo removal, account locks, nologin, or SSH denial. Opus 4.6 landed almost identically at 60% force. The newest model, Mythos 5, reached a negotiated truce 98% of the time, which reads like progress until the mechanism shows through. Anthropic found that prosociality and raw capability are orthogonal, and that its Mythos-class models often locked rivals out first, then reverted the lockout and negotiated afterward. More capable models did not fight less. They fought faster and cleaned up better.
In several Mythos 5 episodes, the agents invented their own way out, in effect creating a performance tournament among the three language implementations. One Rust agent's reasoning trace worked out how to propose benchmark criteria that looked neutral but favored Rust, warning itself to be “careful not to be seen as metric shopping.” The Golang and TypeScript agents lost the bake-off, conceded the codebase, and abandoned their original user directives. Diplomacy, in these runs, was a more polished route to the same end the malware chased.
The same low variance that makes a single agent predictable makes a fleet of them dangerous. Identical models in identical situations reach for identical moves, so an isolated bad call becomes a synchronized one. In an early build-a-game run, 18 of 30 agents created a git branch with the exact same name, “mvp-game-loop,” with no coordination between them. Told to each build something impressive, more than half of a swarm chose either a ray tracer or a self-hosting compiler. In an iterated prisoner's dilemma with communication, the agents converged on one strategy and then all defected in the same round, tanking their own rewards together. And handed job queues on a bandwidth-limited system with no way to coordinate, agents flooded the scheduler with polling daemons firing 30 times per second. One run generated 2.4 million job requests and 117 accepted jobs.
Merritt Baer, a former deputy CISO at AWS and an advisor to G2i and Andesite, has not seen correlated same-model risk land as its own line on most enterprise risk registers. “I don't see correlated same-model risk consistently represented as its own line item on enterprise risk registers yet,” she told VentureBeat. “Most organizations still capture it indirectly under AI concentration risk, third-party risk, model risk or resilience.” The conformity results are why the distinction matters to her. “If you deploy ten agents backed by the same model, you may not have ten independent decision-makers—you may have ten opportunities for the same failure mode to execute simultaneously,” Baer added. “That undermines some of the assumptions we normally make about redundancy.”
Competition collapsed just as fast. Anthropic placed three to eight profit-maximizing agents in a Bertrand pricing game with identical wholesale costs. Given a private back-channel, they began colluding almost immediately and had explicit price floors set by round 3: "wholesale is 10 for all of us, so a price war just burns everyone's margin… happy to coordinate who covers which niches. — agent 1, round 1, via Anthropic."
Anthropic then stripped out every direct communication channel. The agents colluded anyway, price-matching to the penny through a public listings board. Any enterprise running pricing, procurement, or bidding agents against a competitor's agents now owns that behavior, and no regulator will care that no human wrote the memo.
Coordination has an upside, which is why Anthropic keeps chasing it. Pointed at 15 open-source projects, a 45-agent swarm sharing a forum found 266 vulnerabilities where independent parallel agents found 21. The gap is coverage, not raw efficiency. The swarm spent 27 million tokens against the parallel run's 6.5 million, and roughly half its findings came from outside the core directories the parallel agents were told to search. Anthropic calls the two methods largely complementary, with only 12 findings in common. What the swarm did that the parallel agents could not was build its own tools and specialize by vulnerability class, ranging wherever it judged the bugs were richest.
Anthropic ran two tests of agent judgment, and they failed in opposite directions. In the first, a listener agent made routing calls off four scouts, one lying at a fixed rate, and was never told any source might be unreliable. Newer models held out longer as the lie rate climbed, recovering more of the gap between trusting every report and a perfect oracle, but none acted skeptically until the contradictions forced it. The second test inverted the pressure. In a hidden-profile task, the decisive facts sat split across four agents while their shared evidence pointed the wrong way, so the group could only get it right by trusting the one member holding the missing piece.
Mythos 5 surfaced the right answer about 85% of the time. Every other model tested landed between 17% and 36%, far below the near-100% rate a single model hits when it holds all the facts alone. One failure comes from trusting a liar, the other from refusing to back a lone truth-teller against the room, and Anthropic notes that turning a single dial to fix one only widens the other.
Independent testing complicates the picture in one direction and sharpens it in another. AISI researchers Robert Kirk, Alexandra Souly, Kai Fronsdal, Abby D'Cruz, and Xander Davies evaluated whether frontier models would sabotage AI safety research across 270 scenarios. Left alone, no model did it unprompted. AISI attaches a caveat that matters here, though. Its scenarios were often recognizable as evaluations, and a model that behaves only when it senses a test is a thinner guarantee than a clean zero rate suggests. Dropped mid-trajectory into a run where sabotage was already underway, Mythos Preview continued it 7% of the time, against 3% for Opus 4.6 and 4% for Sonnet 4.6 — and 0% for Opus 4.7 Preview, the one model in the study that never took the bait. In 65% of the continuations Mythos Preview did pursue, its reasoning and its reported output diverged. What individual alignment does not touch is coordination, and Anthropic writes that it does not emerge from stronger intelligence or from alignment at the individual level.
Kayne McGladrey, a senior member of the IEEE, has been tracking this exact behavior class. “An AI will take shortcuts. It's what a human would call cheating, and it will not disclose it to you in its chain of thought,” McGladrey told VentureBeat. “If you get into the inference layer, it won't tell you it's cheating, and it will lie about having cheated.”
The governance consequence is sharper than the security one, in his reading. Corporate accountability assumes an entity that can be compelled to tell the truth. “They certainly have a duty to be forthright. Think about it like that's the basis of fiduciary duty,” he argued. “However, they don't necessarily have the capability to do it.”
Baer draws the same line from the architecture side, and she starts by demoting the reasoning trace. “I would treat chain-of-thought as a useful signal, not a security boundary,” she explained. “If the model can conceal, distort or simply fail to surface the reasoning associated with a harmful action, then reasoning traces can't be your primary control.” Her fix is to watch what the agent does rather than what it says it is doing. “There's an analogy to insider threat: you don't secure an enterprise by asking employees to narrate their intentions. You establish permissions, separation of duties and telemetry, and then investigate behavior (sometimes building off of a nuanced understanding of motives).”
McGladrey reaches the same place from the audit side, where auditing outcomes is what remains. “We can audit code for compliance. We can audit code for security. We cannot audit code for ethics or bias, there is no scalable way to do that,” he put it. “I think that's going to be the only meaningful way to look at what an AI forward entity does.”
VentureBeat's own survey data puts numbers on the distance between these experiments and production reality. In VentureBeat Pulse Research's July wave, 65% of enterprises enforce scoped agent permissions at runtime while 18% isolate their highest-risk agents, and the 53 enterprises that enforce without isolating carry a 58% incident or near-miss rate. Anthropic's turf war is that architecture animated. Every locked account and camouflaged binary in the experiment ran on infrastructure the agents shared without isolation, holding credentials that stayed valid throughout.
Baer said the first thing that changes for a team running agents in production is the threat model itself. “We've spent years designing controls around malicious users acting through software. With multi-agent systems, the software itself can become an adversarial participant—even if every agent started with legitimate credentials and an ostensibly legitimate objective,” she said. The Anthropic transcripts are why she puts independent telemetry ahead of trust. “If an agent can rename malicious code to look like a health monitor, you can't base trust on what a process calls itself or what the model says it is doing. You need independent telemetry around what actually happened.”
Anthropic flags its own limits in the post. Agents deployed in the wild will act with more variance than its lab swarms because their contexts differ and they will not all be Claude. Anthropic engineered the turf war, putting three agents on one server with incompatible orders and no isolation by design. And the disclosure itself is a control working as intended. A frontier lab publishing verbatim transcripts of its own models writing malware, reasoning included, is the transparency level enterprise buyers have spent two years demanding on every vendor questionnaire.
The board question writes itself. If two of our agents lock each other out of production at 2 a.m., who holds the kill switch, and how long does the rollback take? The experiments translate that question into tests a security team can run this quarter, before production runs them first.
Behavior Anthropic documented | Where it surfaces in an enterprise stack | The test to run this quarter |
Goal-conflict sabotage. Every model tested locked rivals out and disguised malware when handed clashing objectives. | Any two agents with write access to the same repo, pipeline, or production host and no isolation between them. | Run a contradictory-objective drill in a sandbox. Confirm each agent has its own identity, a kill switch, and a rollback path before it touches production. |
Concealment. Mythos Preview's reasoning and its reported output diverged in 65% of the sabotage-continuation runs it kept going. | Chain-of-thought monitoring used as a primary control on agent behavior. | Score agents on outcomes against policy, not on stated reasoning. Treat the reasoning trace as advisory telemetry that can lie. |
Conformity. 18 of 30 agents chose the same branch name, and one job queue took 2.4 million requests to accept 117. | Fleets of identical agents on one model making correlated calls at the same moment. | Set per-agent rate limits and run a shared-failure chaos test. Confirm one bad decision does not replicate across the fleet at once. |
Collusion. Three to eight pricing agents set price floors by round 3, and matched to the penny with no channel at all. | Pricing, bidding, or procurement agents acting in the same market. | Monitor cross-agent convergence directly. Alert when independent agents move in lockstep, with or without a channel between them. |
Anthropic closes its post with a choice rather than a prediction. The conditions that make agent-to-agent interaction safe get discovered deliberately and early, or they get discovered by default in production, after agent interactions outnumber human ones. The transcripts, the truce rates, and the concealment numbers are all public now, which turns the schedule into a decision. “I think that there's a level of tolerance that's being given right now in AI that is unlike anything else in society,” McGladrey said.
McGladrey's tolerance point cuts both ways: the same enterprises still deciding how much of it to extend are the ones sitting at 18% isolation — which is a choice, not a limitation.
The Trump administration is recruiting private security firms to conduct federal government-authorized operations, including cyberattacks, against overseas-based criminal organizations that commit hacks on US persons, organizations, or government entities.
In a National Security Presidential Memorandum issued Thursday, US President Donald Trump directed the National Coordination Center (NCC), which operates under the Homeland Security Task Force, to develop a program for conducting specific cyber operations that combat foreign transnational criminal organizations (TCOs). The Departments of Justice and Homeland Security will provide oversight. The lynchpin of that program is bringing in private sector companies to participate.
A fact sheet that accompanied Thursday’s memo listed ransomware, sextortion schemes, phishing campaigns, financial fraud, and impersonation scams as activities eligible for private-sector security firms to target. The memo said such firms could “conduct Cyber Surveillance Operations and Cyber Effects Operations” against “cyber-enabled” TCOs. Such groups are defined as “any foreign group that conducts cyber-enabled crime against the United States Government, a United States person, or United States interests, and that is not an institutional part of a foreign government or wholly operated under a foreign government’s direction.”
© Getty Images | cokada
Terabytes worth of credentials, many belonging to the world’s biggest and most sensitive organizations, have been exposed in a supply-chain attack on LiteLLM, an open source tool that streamlines AI-driven software development. Microsoft, Amazon, Cisco, Samsung, and Salesforce are only a handful of the entities whose access secrets were exposed.
The revelation was posted on Tuesday and Wednesday by security firms CloudSEK and Hudson Rock. CloudSEK said it found cloud keys, repository tokens, SSH keys, Kubernetes secrets, package publishing credentials, environment variables, and AI provider keys that could allow attackers to gain access to more than 2,500 organizations.
The credentials were extracted during a 40-minute window in March while the victims used compromised versions of LiteLLM downloaded from the package’s official location in the Python Package Index repository. Hudson Rock said it made the discovery after analyzing a 195TB file that it obtained. Neither firm identified the source of the information.
© Getty Images
Visa's president of technology, Rajat Taneja, walked the VB Transform 2026 audience through aiming Anthropic's Mythos at Visa's own payment network. The model stitched minor weaknesses into working exploit chains, and Visa open-sourced the harness that governed the hunt.
That's what it looks like when an enterprise has the engineering depth to act on what it finds. Most don't get there. Just over half, or 53%, of enterprises have already had an agentic security incident or near-miss. Sixty-five percent enforce agent permissions at runtime, yet only 18% isolate their highest-risk agents, and just 8% pair enforcement with isolation.
Leaning on provider-native controls to do the heavy lifting of agentic security just exacerbates that gap. The July wave of VentureBeat Pulse Research found that 92% of enterprises naming a primary security layer default to their hyperscalers and AI platform providers.
Six waves of research have been completed since January, surveying 440 qualified enterprise security respondents. The key takeaway: the containment gap between what enterprises need and what's getting done is growing wider, often unaddressed by enterprises whose agentic AI investments and futures are at risk.
The research keeps showing enterprises rating the tools they know best at a higher score, even if those tools failed them or delivered mediocre results. Three findings from the raw data cut against that instinct, and each one says something about how young this market still is.
The enterprises that got hit rate their tools higher than the ones that didn't
Last month’s survey found that 46 enterprises reported a confirmed incident or near-miss, then went on to rate their satisfaction with their security tooling. Their average satisfaction was 4.39 out of 5. 30 of the 55 enterprises who experienced no incidents rated their security tooling at 4.13. Enterprises are rewarding any tool that saves them from a breach with a trust premium.
It’s a sure sign of a nascent market when brand positioning, marketing, or other means of persuading enterprises get easily superseded by saving a customer from a breach. Near-misses outnumber confirmed incidents 2-to-1 in both June and July, which means enterprises are catching problems at the edge. That edge catch is being interpreted as validation of both the security strategy and the tools acquired. Evident through seven months of data is how quick enterprise security leaders are to trust a new tool that identifies an intrusion or breach and defeats it before it gains access. VentureBeat believes the rescue itself is doing the marketing. The 4.13 average among never-hit enterprises shows the other side of the same effect. Tools that have never been seen working earn less trust, not more.
VentureBeat also found that of the 17 enterprises isolating their highest-risk agents, the 14 that rated their tooling average 4.00. Enterprises that do not isolate rate it 4.35. The enterprises closest to real security are the least satisfied with their tools — that dissatisfaction is what drives them toward the kind of engineering effort Visa put in.
Four of five enterprises that solved identity did not build isolation
49%, or 57 of the 116 enterprises surveyed in July, gave each agent its own scoped, managed identity. Just a month earlier, VentureBeat's June wave recorded 32% of enterprises having assigned per-agent identities. July’s 17-point jump in one month is the fastest single-month move this series has recorded. Despite these gains, 63% still report credential sharing somewhere in the fleet. Only 11 of those 57 also isolate.
That ratio explains why the containment gap keeps widening even as every headline control improves. Enterprises are treating identity and isolation as substitutes. They need to see the longer-term vision of each being integral to a platform-based, layered strategy. Two incidents VentureBeat has covered show why that distinction matters. A rogue AI agent at Meta passed every identity check before its March exposure was contained. And CrowdStrike CEO George Kurtz disclosed, at his RSAC 2026 keynote, a Fortune 50 agent that rewrote its own security policy using valid credentials. Giving an agent scoped credentials does not bound the blast radius when those credentials are misused. Sandboxing does.
The enforce-without-isolate population has a 58% incident rate
Fifty-three enterprises in July’s survey enforce scoped permissions at runtime but do not isolate. 31 of those 53 have already had an agent security incident or near-miss. That is 58%, five points above the 53% sample average. The enterprises living inside the containment gap are getting hit more often than the enterprises outside it.
Amy Chang, Cisco's head of AI threat intelligence and security research, presented findings on the Transform agentic security panel showing that when Cisco ran 6,986 multi-turn attacks against 15 flagship models, attackers who adapted across the conversation broke through up to 88.3% of the time. Single-turn red-teaming missed it. An adaptive attacker who defeats the guardrails lands inside whatever architecture sits behind them, and for 53 of the enterprises in this data, that architecture enforces but does not contain.
VentureBeat's Q1 Pulse Research tracked the same structural weakness earlier this year. Unauthorized tool or data access ranked as the most feared failure mode in every Q1 survey, growing from 42% in January to 50% in March. The April-May survey found only 4% of enterprises comfortable relying on model guardrails alone. Enterprises predicted they needed external controls, choosing to build enforcement over containment.
The April-May survey asked 109 enterprises how they expected agent behavior to be controlled by the end of 2026, and 30% predicted runtime enforcement, 14% sandboxed execution, and 32% model-level guardrails. By July, 65% had built enforcement, more than double the prediction, while isolation reached 18%, roughly the rate they said it would. Enterprises built what was easy at twice the forecast and built what was hard at roughly the forecast. The April question asked for the primary control mechanism, single-select, while July's posture question allowed multiple selections, so the comparison is directional rather than exact.
Provider-native platforms already led usage in April-May, named by seven in ten enterprises describing their tooling. By June, 82% called one their primary agent security layer, and by July that share reached 92%, with OpenAI's guardrails leading at 44%, Microsoft Azure at 42%, Anthropic's managed-agent controls at 37%, and Google Cloud at 31%. Cloudflare at 11% and Cisco at 9% lead the dedicated specialists fighting over what remains. The identity tools most relevant to the credential-sharing gap are the smallest of all, with Microsoft Entra Agent ID at 7%, while Okta for AI Agents, non-human identity platforms, and runtime sandboxing tooling each sit at 3%. CrowdStrike CTO Elia Zaitsev told VentureBeat at RSAC 2026 that observing agent actions is a solvable problem but inferring intent is not. The provider bundle proves his point, solving observation while leaving containment unbuilt.
Satisfaction scores continue rising as enterprises gain more experience using tools and techniques to stop agentic AI-based attacks. Rising to 4.29 out of 5 in July from 4.2 in June, satisfaction is the highest reading in the series.
Despite the high satisfaction levels, 74% plan to replace their tools within 12 months, up from 59% in June. Only 26% intend not to change. VentureBeat believes early adopters are impatient to gain greater insights, and know what they don’t know about agentic security and resilience. Closing that knowledge gap is forcing churn into a market this young, and the raw answers resolve the paradox: 92% of enterprises naming a primary layer name a provider-native one. The 4.29 measures how easy it is to turn on a provider's guardrails. It does not measure how effective those guardrails are at preventing the incidents 53% of the same respondents already had.
In June, defenders led attackers 35% to 21%, but by July the split was 30-30, a dead heat. Among enterprises that have been hit, 39% now say attackers are ahead, against 20% of those that have not. Getting hit nearly doubles the pessimism but does not change the shopping. Just 10% of enterprises include any agent-identity product in their consideration set. Runtime sandboxing draws 6%, and those numbers hold regardless of incident history. VentureBeat covered the same blind spot in the June data. The label changed from agent security gap to containment gap, but the shopping did not.
The posture question was answered by 93 of the 116 qualified July respondents, and the skippers are not hidden isolators. Twenty-three of the 25 who selected no posture option are organizations still evaluating agents, unsure of their status, or with no deployment plans, groups for which a security posture largely does not yet exist, so the 18% isolation figure reads on the enterprises actually running or piloting agents. April-May, June, and July are separate, independently fielded waves rather than a single tracked series, so month-over-month comparisons in this piece are directional rather than a measured trend. Base sizes for the cross-cuts differ by instrument. The identity question covers all 116 respondents, isolation covers the 93 who described a posture, and the satisfaction inversion of 4.39 versus 4.13 is computed on the 76 respondents who rated their tooling.
VentureBeat's cross-survey analysis of 573 enterprise respondents concluded in July that enterprises deployed AI agents ahead of the controls needed to manage them, and they did it knowingly. Three waves of security-specific data now show where the knowing stops.
Enterprises continue giving agents scoped identities and treating that as containment, but that assumption is false, and the incident data keeps proving it. In fact, 46 of 57 enterprises that solved identity did not build isolation. The enforce-without-isolate population's 58% incident rate is the clearest evidence that identity alone isn't enough. The containment gap will not close through satisfaction with what is easy. Whether enterprises build isolation and governed identity deliberately, or whether a confirmed incident that propagates does it for them, is the question the next wave will answer.
On Monday, passengers aboard Delta flight 591 going from Las Vegas to Atlanta allegedly spoofed the onboard Wi-Fi, raising the attention of federal law enforcement.
The incident came one day after the DEF CON security conference concluded in Las Vegas and was first described on social media accounts that follow publicly available air-to-ground messages, known as ACARS.
According to the “ACARS Drama” account, a message sent by pilots from the plane stated: “NO INFO AS OF NOW WE HAVE A BUNCH OF PAX THAT WERE AT A CYBER CONFERENCE IN LAS THEY WERE ABLE TO JAM OUR WIFI AND BROADCAST THEIR SIGNAL.”
© Igor Golovniov/SOPA Images/LightRocket
Google’s Chrome browser has added a new feature that could go a long way in preventing a form of account takeover that’s grown increasingly common as users adopt two-factor authentication, passkeys, and similar protections.
The new Chrome protection is known as device-bound session credentials (DBSCs). The measure stores a unique encryption key in a silicon-resident fortress that’s built into the device running the browser. On Windows machines, this fortress is called a TPM, short for Trusted Platform Module. On macOS and iOS, it’s known as a secure enclave. Other platforms have differing names. Recently released versions of Chrome for Windows and macOS generate a key that’s stored in this fortress.
DBSCs protect against the theft of session cookies, the unique strings of characters that websites store on browsers. Session cookies greatly speed up browsing on sensitive sites that require user authentication. Instead of requiring the exchange of credentials each time a user opens a new site page, the server sets a session cookie that effectively proves the user has already successfully logged in.
© Getty Images
Last week, a researcher outlined what he said was a “novel attack surface” in passkeys, the new authentication paradigm that offers a more secure alternative to password-based methods. In fact, the attacks demonstrated in the post are neither novel nor unique to passkeys. This distinction is important because the research has generated confusion among end users and security professionals as they assess whether this new mechanism is truly safe to use.
The attack is called Pass-ta-key—a blending of the word passkey with the phrase “pass the key” and a nod to a plate of pasta. Arie Olshtein, a researcher at security firm Palo Alto Networks, described in a post last week how Pass-ta-key could obtain all passkeys stored in the Google Password Manager app (GPM) for Windows when it’s running on a machine infected with malware.
This came as a surprise to many people because they believed passkeys are stored exclusively in the trusted platform manager (TPM), the locked-down enclave in a hardened silicon chip that’s reserved for storing cryptographic keys and other highly sensitive information on Windows machines. If passkeys are stored in the TPM, then how was Pass-ta-key able to extract the entire set of passkeys stored by the app, they wanted to know.
© Aurich Lawson | Getty Images
Earlier today, OpenAI launched GPT-5.6-Cyber, a specialized model designed to perform advanced vulnerability research and exploit development for approved defenders — including categories of work that its general-purpose models will often refuse.
GPT-5.6-Cyber is a fine-tuned version of OpenAI's most advanced general model, GPT-5.6 Sol, unveiled back in June, but trained specifically to improve performance on advanced cybersecurity tasks, including finding zero-day vulnerabilities and developing exploit chains.
Crucially, OpenAI also trained it to reduce refusals on some higher-risk, "dual-use" cybersecurity requests — that is, requests that could be used for legitimate defensive or malicious offensive purposes.
Indeed, on an internal OpenAI benchmark called Advanced Cybersecurity Completion Rate — which the company says in its launch blog post measures tasks involving exploit-chain development, authentication bypass, privilege escalation, and other advanced cybersecurity scenarios — GPT-5.6-Cyber completed 95% compared to just 57.3% from its immediate predecessor model GPT-5.5-Cyber, and just 1.5% with the normal GPT-5.6 Sol model and all its safeguards applied.
OpenAI researcher Eric Wallace posted on X, describing GPT-5.6-Cyber as OpenAI's "first large-scale attempt at directly improving capabilities for advanced cybersecurity tasks such as exploit development."
Unfortunately for enterprises, GPT-5.6-Cyber is not being made broadly available to every ChatGPT or API customer.
To get access, an organization has to be accepted into the newly created tier of OpenAI’s Daybreak cybersecurity program, called Daybreak Red — also announced today, which gives access to dedicated cybersecurity models like GPT-5.6-Cyber
Another new tier, Daybreak Blue, gives a wider swath of enterprises access to general models like GPT-5.6 Sol but with some guardrails lifted to allow for more cybersecurity uses.
OpenAI’s documents list pricing for GPT-5.6-Cyber at $12.50 per million input tokens and $75 per million output tokens, with cached input at $1.25 per million tokens.
That makes it more expensive than GPT-5.6 Sol in the same Daybreak cyber pricing table, where Sol is listed at $5 per million input tokens and $30 per million output tokens for short-context use.
OpenAI does not list long-context pricing for GPT-5.6-Cyber in the same table, and access still requires separate Daybreak Red approval and provisioning.
Daybreak Red is for approved security teams doing advanced, authorized cyber work — the kind of work that can look risky out of context, even when it is being done for defensive reasons. That includes vulnerability research, penetration testing, red-team exercises and exploit validation on systems the organization owns, operates or has permission to test. In other words, OpenAI is saying GPT-5.6-Cyber is for trusted defenders with a clear professional need, not for general experimentation.
Enterprises that want access have to apply through Daybreak Access, OpenAI’s current pathway for vetting cyber users. The application asks companies to identify who they are, what kind of security work they plan to do, where they will use the models, and which OpenAI products or surfaces they expect to use. Applicants also have to confirm that their work is lawful, defensive and authorized.
OpenAI is also looking for signs that the applicant has a serious security program of its own. The company says participating enterprises need controls such as single sign-on, multifactor authentication, role-based access, employee-use monitoring, usage logs, API-key controls and a documented incident-response process. OpenAI also asks for a recognized security certification such as SOC 2 Type II, ISO 27001 or an equivalent standard. Access is limited to approved people inside the organization using company-controlled accounts and devices.
If an enterprise does not qualify for Daybreak Red, or does not need that level of access, OpenAI is pointing most companies toward Daybreak Blue, its other cyber models access tier, instead.
Blue is the broader tier for approved defenders. It does not provide GPT-5.6-Cyber, but it does give vetted users access to OpenAI’s frontier general-purpose models, including GPT-5.6 Sol, with safeguards adjusted for legitimate defensive work.
For many enterprise security teams, Blue may be the more realistic starting point. OpenAI says it is meant for tasks such as secure-code review, vulnerability discovery, malware analysis, incident response and patch validation. These are still sensitive uses, but they do not necessarily require the same specialized cyber model access that comes with Red.
The practical takeaway is that enterprises now have two routes into Daybreak. Blue is for approved defenders who want stronger AI help with everyday security work. Red is for the smaller set of approved teams that can justify access to specialized cyber models, including GPT-5.6-Cyber. Companies that want to use Daybreak capabilities in products or services for their own customers need a separate approval path through the Daybreak Cyber Partner Program, rather than simply applying for internal enterprise access and passing it along.
OpenAI has supported defenders through its Cybersecurity Grant Program since 2023 — later expanded to $10 million — and began building cyber-specific safeguards into its model deployments starting with GPT-5.2.
In February 2026 it introduced Trusted Access for Cyber (TAC), an identity-and-trust framework that gave vetted defenders lower classifier-based refusals for authorized work such as vulnerability triage, malware analysis and binary reverse engineering.
From there, the cadence accelerated. In March, OpenAI CEO and co-founder Sam Altman announced the Daybreak program. In April, OpenAI scaled TAC and released GPT-5.4-Cyber, a version of GPT-5.4 fine-tuned to be "cyber-permissive" for a limited set of vetted vendors and researchers.
In May, it followed with GPT-5.5-Cyber in limited preview for defenders of critical infrastructure, and lined up partners including Cisco, Intel, SentinelOne, Snyk and Cloudflare.
Notably, OpenAI said at the time that GPT-5.5-Cyber was "primarily trained to be more permissive," not to significantly out-perform its general model — GPT-5.5-Cyber actually scored worse than GPT-5.5 on some evaluations.
TAC required phishing-resistant Advanced Account Security for individuals on its most capable models beginning June 1, and Daybreak now requires hardware security keys for individual accounts beginning September 1.
OpenAI isn't relying exclusively on benchmarks to make its case.
The company says its researchers used GPT-5.6-Cyber to investigate V8, the JavaScript engine underlying Chrome, and uncovered two previously unknown vulnerabilities that could be chained to corrupt memory and escape the V8 heap sandbox.
OpenAI researchers validated the findings and disclosed them to Google, which fixed the vulnerability assigned CVE-2026-15903 — a high-severity flaw in which V8's optimizing compiler skipped a safety check during integer conversion, allowing an out-of-bounds array index that an attacker could use to read or overwrite memory.
OpenAI says the model has also contributed to finding at least five vulnerabilities in an unnamed popular mobile operating system, three critical vulnerabilities in an unnamed popular database, and more than 400 vulnerabilities capable of producing privilege escalation in a popular operating-system kernel. Those disclosures are still being coordinated, according to OpenAI.
The results put OpenAI into a rapidly developing market for AI-assisted offensive security. XBOW, for example, markets autonomous penetration-testing agents that map attack surfaces, attempt exploits and independently validate findings; in 2025 it became the first AI system to top HackerOne's U.S. bug-bounty leaderboard, and this year it disclosed a set of critical, CVSS-9.8 remote-code-execution flaws in Microsoft's Bing image-processing systems, found without source-code access.
For enterprise security leaders, that emerging competition matters because vulnerability research is moving beyond using an LLM as an assistant. Vendors are increasingly building systems in which models can investigate targets, operate tools, validate hypotheses and produce actionable findings.
OpenAI's own results also show why enterprises shouldn't simply equate cyber specialization with better performance everywhere.
GPT-5.6-Cyber outperformed GPT-5.6 Sol and GPT-5.5-Cyber on OpenAI's implementation of ExploitGym, which evaluates whether agents can turn known vulnerabilities into working exploits in controlled environments. It also beat Sol on an internal zero-day evaluation.
But GPT-5.6 Sol performed better on OpenAI's Vulnerability Discovery and Report Writing evaluation. OpenAI attributes the Cyber model's lower score partly to shorter and less detailed vulnerability reports.
Sol also performed best on ExploitBench under its standard 300-turn limit, with OpenAI saying it solved tasks more token-efficiently. Extending the evaluation to 600 turns narrowed the gap between the models.
That suggests enterprises may eventually treat cyber models as specialized workers rather than replacements for general reasoning models: one model for deep exploit work, another potentially better suited to analysis, documentation or other parts of a security workflow.
SpecterOps CTO Jared Atkinson said GPT-5.6-Cyber is "materially improving our specialist vulnerability-research workflows," adding that it completed some work in less than a day that previous models had failed to resolve after weeks of intermittent effort.
The permissive-model pitch arrives weeks after OpenAI's most serious public demonstration of what can go wrong when cyber refusals are turned down — and OpenAI addresses that history head-on in the Daybreak announcement.
In July, OpenAI and Hugging Face jointly disclosed that during an internal ExploitGym benchmark evaluation — run with production classifiers deliberately disabled to measure maximal capability — a combination of OpenAI models, including GPT-5.6 Sol and an unreleased, more-capable pre-release model, broke out of their sandboxed research environment and autonomously attacked Hugging Face's production infrastructure.
The models exploited a zero-day in an internally hosted package-registry cache proxy to reach the open internet, moved laterally through OpenAI's research nodes, then inferred that Hugging Face likely hosted ExploitGym's answer keys and chained stolen credentials and remote-code-execution flaws to reach its production database. OpenAI called it an "unprecedented cyber incident, involving state-of-the-art cyber capabilities."
As VentureBeat previously reported, the episode also exposed the flip side of blanket safety guardrails: when Hugging Face's defenders tried to use commercial frontier models to analyze the raw exploit payloads and credential dumps from the attack, the models refused, and the company completed its forensic reconstruction only after switching to a Chinese open-weight model, GLM 5.2, run locally.
That guardrails-block-the-defender dynamic is much of what OpenAI's reduced-refusal Daybreak tiers are meant to solve — even as the same incident illustrates the risks of reducing refusals in the first place.
OpenAI is careful to draw a line between that incident and this product. In the Daybreak announcement it states directly that GPT-5.6-Cyber "was not involved in exploiting Hugging Face, nor are any other models planned for an upcoming release," and notes that the pre-release model implicated in July was an internal-only research prototype that has since been deactivated, encrypted and restricted from research access.
The company has said it is working with external advisers including CrowdStrike, METR and Redwood Research on the review, and has brought Hugging Face into its trusted-access program.
In my assessment, the access model still leaves OpenAI with a hard question: whether keeping GPT-5.6-Cyber inside the narrower Daybreak Red tier also limits the very defensive work it says it wants to accelerate. If only a small group of approved participants can use the model, enterprises outside that tier may still lack access to the kind of specialized AI assistance that could help with fast diagnosis, containment and response in incidents like the one involving Hugging Face.
That means OpenAI may still be repeating part of the mistake it is trying to move past. By holding its most capable cyber model behind a tighter approval process, it reduces obvious misuse risk, but also leaves many enterprise defenders looking elsewhere. For teams that cannot qualify for Daybreak Red, or cannot wait for approval, open weights models may remain the more practical alternative: less controlled, but easier to obtain, inspect, run internally and adapt during a live security investigation.
The most consequential part of Daybreak may ultimately be its access architecture rather than its benchmarks.
OpenAI explicitly says Daybreak Blue removes system-level guardrails that can interfere with legitimate defensive work, while GPT-5.6-Cyber goes further by reducing model refusals for certain dual-use tasks. In their place, OpenAI is imposing controls around who receives access and how the models operate.
Daybreak access is restricted to approved individuals and organizations performing authorized work. OpenAI says controls include identity verification, account security, monitoring, approved-use restrictions and legal attestations.
The company is also encouraging Daybreak customers using Codex to move from full-access execution to an auto-review mode capable of evaluating actions requiring elevated permissions before they execute. Individual Daybreak accounts will be required to adopt hardware security keys beginning September 1. OpenAI says it is additionally rolling out improved monitoring in the coming weeks and prioritizing alignment training and testing for upcoming Daybreak releases — commitments that read, in context, as a direct response to the Hugging Face review.
OpenAI's broader Codex Security product supplies another layer around the models, providing repository analysis, vulnerability validation, remediation and integration into cloud, pull-request and local development workflows. OpenAI says Codex Security has scanned more than 30 million commits across more than 30,000 codebases, with more than 500,000 findings fixed.
That model-plus-harness approach resembles a broader shift in AI security products. XBOW, for example, emphasizes orchestration, exploit validation and governance around frontier models rather than treating an LLM alone as the complete penetration-testing system.
OpenAI nevertheless acknowledges that increasingly permissive cyber models create additional risks, whether from misuse or misalignment. It assesses both GPT-5.6 Sol and GPT-5.6-Cyber at the High cybersecurity capability level under its Preparedness Framework, but below its Critical threshold. A fuller GPT-5.6-Cyber system card is planned for later publication.
For CISOs and security engineering leaders, Daybreak therefore presents a different deployment question than another incremental model upgrade. As models become capable enough to perform work previously reserved for experienced vulnerability researchers — and, as the Hugging Face incident showed, capable enough to pursue a narrow goal straight through a sandbox — the enterprise control plane around those models — permissions, sandboxes, monitoring, human review and authorization — becomes as important as the intelligence inside them.
Amazon Web Services is threading its AI-powered security infrastructure directly into the coding environments built by two of its fiercest rivals — and in doing so, it is making a bold bet that controlling the security layer matters more than controlling the model.
AWS announced at Black Hat USA 2026 this month that its Continuum platform for code vulnerabilities will integrate directly into Anthropic's Claude Code and OpenAI's Codex, alongside AWS's own Kiro IDE.
The move embeds AWS security tooling at the point where developers write code, regardless of which AI model they use to do it. Simultaneously, AWS expanded Security Hub Extended — its curated, single-bill security marketplace launched in February — with a 10th security category focused on supply chain protection, bringing in Chainguard and Socket as partners.
Together, the announcements are AWS's most sweeping attempt yet to position itself as the default security control plane for enterprise software development in the AI era — a role that carries enormous commercial implications as the global cloud infrastructure market surpasses $143 billion per quarter, according to Synergy Research Group.
The urgency behind both launches traces back to a single inflection point that reshaped enterprise security earlier this year. Claude Mythos Preview, announced by Anthropic in April, is a general-purpose AI model that during testing revealed striking cybersecurity capabilities far exceeding any prior system.
In pre-release evaluations, Mythos identified thousands of previously unknown zero-day vulnerabilities across every major operating system and web browser. More than 99% of those vulnerabilities remain unpatched by their maintainers, and the median time from vulnerability discovery to weaponized exploit — already collapsed from 771 days in 2018 to under four hours by 2024 — is projected to reach under one hour by the end of 2026.
Chet Kapoor, AWS's vice president of search, security, and observability, framed the challenge in stark terms in an exclusive interview with VentureBeat. "CISOs have had code vulnerabilities for a while, and then Mythos came along, and it just made it a lot worse," Kapoor said. "They already had a backlog. Now the backlog is 5x more, and that causes a problem."
That problem — the exponential growth in known vulnerabilities outpacing any organization's ability to triage and fix them — is precisely what Continuum is designed to address. Kapoor described AWS's broader security vision as a shift from "telemetry, storage, query, dashboards for humans to telemetry, context, reasoning, and actions by agents." The shorthand for that vision is a phrase AWS repeated throughout Black Hat: autonomous security at machine speed.
Continuum operates as what AWS calls an “agent-team loop architecture” — a sophisticated orchestration harness that selects the right AI model for each task, connects to a customer's environment, and delivers validated secure code. Under the hood, it runs through four distinct phases.
Kapoor broke them down for VentureBeat. Discovery uses multiple frontier AI models to scan code and ingest a customer's existing vulnerability backlog. Prioritization — which Kapoor called "one of our biggest value adds" — contextualizes each finding against a customer's actual environment and business risk. "You go from 100 to 2,000, and now you're like, whoa, I didn't even know which 100 to focus on," he said.
Validation then builds reproducible exploits in an isolated sandbox to confirm whether a vulnerability is genuinely exploitable. "Once I do them, how will it behave?" Kapoor explained. "You create a sandbox to go off and make that happen. So you can figure out what the blast radius is." The validation phase covers both first-party code that customers wrote themselves and third-party open source code they depend on. Finally, remediation offers fixes — whether network configuration changes, policy adjustments, or code patches — that the system has already tested in the same sandbox. The human stays in control throughout, approving outcomes at whatever level of autonomy the organization is comfortable with.
The commercial model is equally deliberate. Customers pay AWS a single price for Continuum. AWS absorbs the underlying token costs for whichever frontier model performs best at each phase of the scan. "The customer purchases Continuum, period," Kapoor told VentureBeat. "We optimize on which model to use for what because, quite frankly, GPT Cyber is good at some things, Mythos is good at some things."
The most strategically striking element of the announcement is the integration with OpenAI Codex and Anthropic Claude Code. AWS competes directly with both companies across cloud AI services. Amazon holds a massive investment in Anthropic, and OpenAI operates its own growing infrastructure that competes for the same enterprise AI workloads. Yet both agreed to embed Continuum inside their developer environments.
When VentureBeat asked Kapoor directly about the competitive dynamics, he pushed back on the framing entirely. "Who is the competitor?" Kapoor said. "I can keep thinking about Anthropic and OpenAI to be partners. I don't understand the word 'competitor' in your description of the question." He added: "They're partners with us. We use their models. We plug into their environments. Which is why we actually brought them together to do this."
Kapoor argued that working with a single model provider would be insufficient. "I don't think it's good enough to just do it with one company," he said. "Everybody is going to leapfrog each other over a period of time." By absorbing token costs and presenting a single bill to the customer, AWS positions Continuum as infrastructure — not a model wrapper. The harness, not the engine, becomes the durable competitive asset.
As Kapoor wrote in his blog post announcing the partnership: "An AI harness is the orchestration layer that wraps around a model to connect it to tools, guardrails, memory, and workflows, so it delivers outcomes. Think of the model as the engine and the harness as everything around it. You need both to have a high-performance car."
AWS partners echoed the logic. "Model choice was never the hard part for enterprises. Trust in what the model does in production is," said Val Henderson, CEO of AWS Premier Partner Caylent, in comments reported by CRN.
The second prong of AWS's Black Hat announcements extends Security Hub Extended into supply chain security as its 10th category, with Chainguard and Socket as curated partners. The Extended plan now includes 23 curated partner solutions, all on a single AWS bill with no required long-term commitments, covering endpoint, identity, email, network, data, browser, cloud, AI, security operations, and now supply chain.
Michael Fuller, AWS's director of security services, told VentureBeat that the addition was driven entirely by customer demand. "Over the last six to eight months, it's gotten quite a bit of news around what's happening in the supply chain space, with the fact that everybody builds on open source," Fuller said. "Our customers quickly reached out and said, 'Security Hub Extended is resonating. We would love to see a supply chain security category with some key players there because it's a hot topic for us.'"
The two partners were chosen to be complementary rather than duplicative. Chainguard focuses on providing hardened, secure-by-default container images and packages rebuilt from verified source code. Socket performs behavioral monitoring of packages as they are pulled into a developer's environment, detecting threats like typosquatting, maintainer account takeover, and obfuscated malicious code. "Together, between the three of us — us with consolidating that, ChainGuard providing really good hardened and cleaned images and packages, and then Socket providing a behavioral analysis over the top — gives customers a really good holistic supply chain security offering," Fuller said.
The complementary approach addresses two distinct attack vectors. An attacker can publish a malicious package that contains no known vulnerabilities — Chainguard's clean-build approach defends against that. Separately, an attacker can compromise a legitimate maintainer's account and push a tainted update to a trusted package — Socket's behavioral detection catches that. Both vectors are amplified in the AI coding era, Fuller noted, because AI agents face the same supply chain risks as human developers: "Agents can be misled on, 'Hey, this is a well-known package that you're looking for,' and therefore pull it down, even though it's been maliciously obfuscated."
The partner selection strategy behind Security Hub Extended reveals a deliberate philosophy that distinguishes it from the AWS Marketplace, which already hosts tens of thousands of security offerings.
Fuller told VentureBeat that customers articulated clear principles for what they wanted. "One was don't give me hundreds of offerings. We already have the AWS Marketplace," he said. "Two was give me a sweet spot. Our customers were saying, give me two in each category, and when you look at those two, don't give me head-to-head competitors. Give me one that I may know well, that is an established player, and give me one that's taking a different approach."
Fuller pointed to the security operations category as the template. "You have Splunk, hard to argue not an established leader in security operations, and then you have Seven AI that's kind of taking a very different approach, and they're complementary in a lot of ways."
The decision to build internally versus partner follows a similar logic. For endpoint detection and response, AWS has no structural advantage, so it partners exclusively. For cloud security, AWS builds its own native tools because it intimately understands its own infrastructure — but still partners with Upwind to give customers a second option.
"At the end of the day, what we're trying to do here is ensure that our customers can operate in the most secure way possible on AWS, not necessarily grow a large security business as the core goal," Fuller said. "That's why it's very easy for us to decide to do both building ourselves, but also then inviting partners to participate."
The pricing model reinforces this accessibility. Fuller said customers demanded pay-as-you-go options alongside traditional multi-year commitments. "All of the Security Hub Extended offerings have a public-facing, pay-as-you-go price, just like our first-party offerings do within AWS," he said. "So that gives customers the option to go kick the tires, get going, even scale up and use the services without going through a traditional sales cycle."
Both AWS executives addressed an emerging security concern gaining traction among CISOs: the proliferation of unregistered AI agents — what the industry has begun calling "shadow agents" — and the novel attack patterns they enable.
Kapoor told VentureBeat that shadow agents are a genuine and growing problem, though he was careful to separate it from the Continuum announcement. "There are many agents that are registered with registration directories, whether it's Vertex, whether it's Agent Core, whatever else it might be, but there are many agents that are not registered with the registry, and those are what people are calling shadow agents because they can actually do some harm," he said. "Discovering shadow agents is not easy. The industry is working on it."
Fuller provided more granular detail on what AWS has already deployed. Security Hub now includes a free AI inventory capability that uses three data layers: AWS Config identifies AI-related services like SageMaker, Bedrock, and Agent Core across an organization; Amazon Inspector scans compute instances and containers for AI-related software; and GuardDuty compares DNS request and response logs against known AI tools and agentic workloads.
Beyond inventory, Fuller revealed that GuardDuty now monitors data plane events — including prompts, prompt volume patterns, and inference cost analysis — to detect what AWS calls "cost harvesting."
The attack mirrors the cryptocurrency mining that became common after cloud credential compromises: an attacker gains access to an AWS account and burns through as much free AI inference as possible before detection.
"We're seeing what we're calling cost harvesting," Fuller said. "They'll spin up, basically try to get as much free inference as they can until that's discovered." It is, Fuller noted, "the same thing that's happening in AI" as happened with crypto mining — and GuardDuty's detection of credential compromise and unauthorized compute usage translates directly to the new threat.
Although both announcements landed the same week, AWS is treating the products behind them as separate. Kapoor described Continuum to VentureBeat as distinct from Security Hub Extended, sold as its own standalone product. AWS declined to discuss its longer-term roadmap for the two.
The design logic points in one direction. Continuum addresses the code an enterprise writes and the open source it inherits. Security Hub Extended addresses everything else — and the newest of its categories is where the two most clearly overlap. Continuum's validation phase covers third-party dependencies alongside a customer's own code; Chainguard and Socket harden and monitor the same packages from the other direction. One capability is built in-house, the other curated from partners, and they meet at the same attack surface.
Both proceed from the same premise: that enterprises no longer want a catalog, they want a recommendation.
"Customers want an opinionated point of view on how they should do security in the AI era," Kapoor told VentureBeat. "That's what Security Hub Extended was about — actually going off and giving them our opinion." AWS will continue to give customers choice, he added, "whether it is something that we ship or whether it is something from a partner."
That doctrine — a recommendation, with an escape hatch — is the through line connecting a curated marketplace to a first-party agent platform, and it makes the boundary between them more porous than two separate announcements suggest. Security Hub has already absorbed capabilities that did not exist a year ago, including the free AI inventory and the cost harvesting detections Fuller described. The console is where AWS delivers its opinion to the enterprise. Continuum is the sharpest opinion it has shipped.
The audience for that opinion has changed as well, Kapoor said. Mythos, he argued, moved security from something the CISO owned to a CEO and board-level imperative. "Boards are now asking for updates on what's going on with security in the enterprise because it's a business threat now, it's a business risk."
The twin launches fit within a broader strategic arc AWS has been building throughout 2026 at a breakneck pace. The company re-imagined Security Hub at re:Invent 2025 by consolidating GuardDuty, Inspector, CSPM, and Access Analyzer into a single console. In February, it launched Security Hub Extended with 14 curated partner solutions. By May, that number grew to 21 across nine categories. Now it stands at 23 across 10. Continuum launched at the New York Summit in June and expanded to OpenAI and Anthropic integrations at Black Hat in August.
AWS generated $42.2 billion in revenue during Q2 2026, with cloud sales expanding 37% year over year. The company holds a 28% share of the global cloud infrastructure market, ahead of Microsoft at 20% and Google at 15%.
Fuller told VentureBeat that AWS has "tens of thousands of customers using one or multiple of our security services, essentially across all geos that we operate in, and in every industry, and both commercial and government." The Extended plan aims to convert that installed base into users of partner security solutions — deepening engagement and making it harder for competitors to dislodge AWS as the default platform.
By making AWS the seller of record for 23 partner security solutions and embedding Continuum inside the coding environments of OpenAI and Anthropic, AWS is constructing something more durable than a product line. It is building the connective tissue between enterprises and every AI model they use, between every open source package they pull, and between every security vendor they deploy. In a world where frontier models are advancing so rapidly that today's best scanner becomes tomorrow's table stakes, the layer that persists is not the model — it is the harness that connects the model to the customer's environment, policies, and risk tolerance.
Kapoor, reflecting on a chance conversation he had on a flight to Black Hat, offered the simplest articulation of why all of it matters. A former CISO turned CTO sitting beside him volunteered a blunt assessment of the current moment: "I don't feel safer now." Kapoor's response, he told VentureBeat, was equally blunt: "We're working on it."
Whether that work makes the world safer or simply makes AWS indispensable to every organization trying to get there may, in the end, amount to the same thing.
