The system combines quantum dots and an OLED display, translating infrared light into a range of visible colors.
Night-vision technology has changed little for decades, producing grainy green images that make it difficult to distinguish objects and depth. Now, researchers have developed a system that converts infrared light into color images.
Standard night-vision goggles amplify the scant light available and convert it into monochrome green images that only vary by brightness. This is not a good match for our eyes, which are much better at picking out different shades than gradations of brightness.
But now a device built by researchers at the Beijing Institute of Technology translates infrared wavelengths into a color night-vision system. To demonstrate the system’s potential, the team built it into a pair of eyeglasses and even showed it could be bound to light-sensitive cells, making them responsive to infrared.
“We redefine infrared vision by transcending the monochrome paradigm, translating infrared spectral and intensity signatures into discernible color variations rather than mere brightness changes,” the authors write in a paper in Science Advances.
The prototype device, known as an upconverter, consists of a stack of thin films on a glass slide that is only a few hundred nanometers thick. The key component is a film of mercury telluride quantum dots. These semiconductor crystals, which are under four nanometers across and exhibit novel quantum mechanical effects, can detect tiny amount of infrared radiation.
Directly above this layer sits an OLED display, much like those used in phones and televisions. But where a standard display has one light-emitting layer, this one has two. A lower layer that glows red responds to relatively low levels of charge from the detector, while an upper layer that glows cyan needs a much stronger flow before it responds.
The upshot is that a weak infrared signal produces only red, but as the signal strengthens it bleeds into cyan, brightening the image and shifting its color as the two mix. The signal is supplied by the quantum dots, which release more charge when the infrared falling on them is brighter. But they also release more when the wavelength is shorter because shorter wavelength photons carry more energy.
This means the color on the display tracks how strong the infrared signal is and also roughly what wavelength it is. The team calculates a person could register infrared power differences of 0.11 milliwatts per square centimeter using color and brightness together, against 23.71 for brightness alone—a roughly 200-fold improvement.
To demonstrate the idea’s real-world potential, the researchers built the device into a spectacle frame. Exposed to infrared light, the lens shifted from deep red through orange to yellow as the illumination grew stronger. It could also render patterns like letters and track targets as they moved and rotated.
The team also tested the approach’s ability to augment natural vision. In one experiment, they engineered neurons to produce channelrhodopsin-2—a protein that makes a nerve cell fire when hit by blue light—and bound the upconverter to them.
When they hit the system with infrared, their device gave off blue light strong enough to trigger the proteins and stimulate the neurons. Electrical recordings also showed the currents inside those cells grew stronger as the strength of the infrared signal was turned up.
Finally, the team tried taping an upconverter over the eyes of mice and humans and recording the electrical responses in their brains and retinas respectively. Infrared pulses alone produced no reaction, but when the device was in place both reacted strongly.
The device is still a long way from practical use. All the demonstrations took place in highly controlled lab settings, the OLED display needs a power source, and the device also requires an infrared illuminator to generate reflections for the detector to pick up.
Nonetheless, it’s a first step towards far more powerful night-vision technology.
The enterprise marketing team at Zapier uses ChatGPT Work to reduce the number of drop-offs in its lead funnel, build campaign assets, and automate reporting.
Virgin Atlantic is accelerating research, product planning, and decision-making with ChatGPT Work, helping teams connect signals across the customer journey.
This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here.
Last week, I headed 30 miles south of San Francisco to a hotel in Mountain View, California, to join some of the most accomplished, and some of the most promising, AI researchers in the world. I was hosting roundtable interviews and speaking at a media training for a convening of the Schmidt Sciences AI2050 program, an initiative funded by Eric and Wendy Schmidt that supports academics whose work involves AI. The fellows list is a who’s who of AI luminaries, and though not all of them made it out to the Bay, every time I turned a corner I saw a scientist whom I’d interviewed previously or whose research I admired. (Full disclosure: I received a science communication award funded by Schmidt Sciences in 2024.)
It’s a weird time for university AI researchers, who make up most of the AI2050 group. In the past four years, AI research has reoriented around large language models, and its cutting edge has moved from academic institutions to private companies. Universities simply can’t afford the GPUs required to train and run frontier models, and even if they could, Anthropic and OpenAI aren’t letting anyone else see the inner details of Claude or ChatGPT.
In a conversation over lunch, Nika Haghtalab, a computer science professor at UC Berkeley, said that being an AI academic these days was like being a biologist in a world in which private companies had exclusive control over the gene-editing tool CRISPR. Experts outside the frontier labs can study how ChatGPT and Claude behave, but they can’t do any detailed research on the design and training of those tools, nor can they steer that design or training themselves.
The AI2050 program does offer fellows some funding that they can use to buy GPUs, which some researchers I spoke with said was a major benefit of participating in the program. But money remains a pressing concern, especially given the reduction of federal scientific funding in the United States. Even for researchers who don’t run local models themselves, the cost of repeatedly querying OpenAI’s, Anthropic’s, and Google’s models in order to study them rigorously can be prohibitive.
Rather than focusing on advancing capabilities, many fellows aim their attention at questions that are unlikely to be addressed by Anthropic or OpenAI. “I try not to work on problems that I think are gonna be solved by a tech company,” says Anjalie Field, a computer science professor at Johns Hopkins. Companies need to make money, and research questions that have little promise of profit might not be worth investing in—especially if their answers might make the companies look bad. Recently, for example, Field conducted a study in which she found that language models give less sophisticated responses to prompts that are phrased in ways more commonly used by women than by men. It’s difficult to imagine that kind of research coming out of Anthropic or OpenAI.
There’s also a huge group of AI academics who don’t work with LLMs at all. Many of them are scientists who build specialized AI models that can analyze data, make useful predictions, or even simulate entire physical systems. Those researchers aren’t necessarily competing with the frontier labs—Google DeepMind’s AlphaFold team, which built a Nobel Prize–winning model that predicts the structures of proteins, was disbanded last month. But they face plenty of their own challenges. At the convening, several voiced concerns about how the widespread ignorance of non-LLM AI was affecting their work. Researchers who build specialized AI tools to help address climate change, for example, sometimes struggle to advocate for their work when so many people believe that “AI” means “energy-guzzling LLMs.”
All these challenges are changing the landscape of academia: Several prominent academics have recently taken leave from their universities to join frontier labs, and many AI2050 fellows hold industry positions alongside their academic jobs. And in the past six months, yet another threat has emerged. OpenAI’s models have solved a number of real research problems in mathematics, and some experts are worried that humans might not have a future in pure math. One fellow I spoke with said that she was concerned about the mental health of her mathematician peers.
But it’s not all doom and gloom. For one thing, empirical science may prove much more difficult to automate than mathematics, because collecting data is an intrinsically slow process. And some researchers see AI mathematicians and scientists as a boon rather than a threat—including Tim Dettmers, a computer scientist at Carnegie Mellon who works to make AI models faster and cheaper to run. AI scientists won’t replace humans, Dettmers says. On the contrary, they could make human scientists far more efficient, so that he and his peers have the chance to pursue all the wild and inspired ideas they might otherwise never have gotten around to.
And scientists are a resilient sort. The very resource constraints that prevent them from training frontier models also push them to discover new ways to make models smaller and more efficient, or to explore completely new architectures. If the next big AI breakthrough comes not from a major company but from a scrappy academic lab, I won’t be shocked.
Modern LLM architectures have co-evolved within a single hardware family. The shapes of our attention mechanisms, the structure of our multilayer perceptrons (MLPs), the choice of numerical formats, and even the granularity of parallelism strategies have all been shaped by hardware constraints: warp sizes, tensor core geometries, memory hierarchies, and the kernel abstractions those chips expose. When the hardware changes, the efficient frontier of model architectures changes with it. Here we present an opportunity for academic and industry labs to explore this frontier in detail on AWS Trainium. Purpose-built accelerators like AWS Trainium present a genuinely different design surface. More on-chip SRAM (SBUF), explicit software control over data movement and acceleration at the lowest levels, energy-efficient systolic matrix multiplication (matmuls), and a memory hierarchy designed for training and inference-scale data flows. The resulting TFLOPs-to-memory-bandwidth ratio shifts the performance bottleneck profile: key operations that are memory-bound on conventional accelerators may become compute-bound on Trainium, opening design space for architectures that trade additional computation for reduced memory traffic. These hardware differences mean the optimal attention patterns, MLP structures, and parallelism strategies may be fundamentally different. The research question is open: What does an optimal model look like when the hardware constraints are fundamentally different? The AWS Trainium Frontier is a competition designed to answer this question empirically: participants train language models from scratch on Trainium, exploring the full design space from model architecture to custom kernels. The core task is training a language model from scratch, starting from a provided ~50M parameter baseline (nanochat-derived, GPT-style dense LLM with RMSNorm, rotary embeddings, and ReLU² MLP). Participants modify everything: architecture, optimizer, training loop, and optionally custom NKI kernels. The baseline is a starting point, not a ceiling. The AWS Trainium Frontier competition rewards full-stack thinking under a fixed time and compute budget. Participants optimize the model architecture, the optimizer, the training loop, and, if they choose, custom hardware kernels. This enables innovation on a combination of objectives: within the allotted training budget, how low can you drive validation bits-per-byte, and how high can you drive downstream in-context learning capability? The fixed budget creates a direct tradeoff between model capacity (better architecture = fewer steps needed) and training throughput (faster kernels = more steps in the same time). The winning solution finds the balance: the most intelligent model trained most efficiently within the time constraint. Final submissions find the optimal point on that frontier, and because Trainium's hardware benefits differ from those of existing accelerators, the optimal architectures will differ as well. Be among the first to discover what model architectures look like when designed for a purpose-built AI chip, contributing to a genuinely new area of machine learning research. The Neuron Kernel Interface (NKI), native PyTorch support, and AI-assisted tooling (including Amazon Bedrock access) give you direct access to Trainium's unique hardware features: the SBUF scratchpad, TensorEngine tiling, and explicit DMA control that standard framework abstractions cannot expose. This is what enables genuinely hardware-native model designs. The entire NKI API surface fits in a weekend, making it equally accessible to both a human writing kernels by hand and an AI agent generating them under human direction. The challenge: Exploring the full design space Phase 1 gives every team a single Trainium2 chip and a 30-minute training budget, fast enough to test dozens of hypotheses in a single day. Phase 1 scores on a single number: validation bits-per-byte (val_bpb) after exactly 30 minutes of training on a single Trn2 chip. Lower is better. Any improvement that fits within that wall-clock budget counts, whether it comes from architecture, optimizer, kernel, or all three. Phase 2 promotes the top 10 teams to a full Trainium2 server with a four-hour budget, opening the door to distributed parallelism and communication-aware model shaping. Phase 2 adds a second axis — inference performance on CORE, an aggregate score across in-context learning tasks spanning reasoning, comprehension, and world knowledge. Your final score is a 50/50 composite: you need a model that trains efficiently and learns to reason. It's a research arc from, "Does my idea work?" to, "Does my idea scale?”. Participants have flexibility in how they improve the model. A better learning rate schedule matters as much as a faster kernel. This rewards the full stack: a novel attention mechanism is only as fast as the kernel that runs it, and the fastest kernel only matters if the architecture knows how to use it. Model size is uncapped: the constraint isn't parameters, it's time on the chip. You choose the model architecture that maximizes capability within a fixed training window. This inversion of the usual scaling paradigm is what makes this a more challenging research question, not just an engineering exercise, and it's where the most publishable insights will emerge. What you get A complete nanochat-derived training pipeline with Muon +AdamW optimizer, ready to run on all NeuronCores A Trainium-optimized autoresearch framework for AI-assisted experimentation Full NKI documentation: programming guide, ISA reference, architecture docs, and example kernels Neuron Explorer for comprehensive profiling and performance debugging of NKI kernels The CORE evaluation harness for inference self-scoring during Phase 2 Eligible academic teams can obtain AWS Promotional Credits covering Trainium compute and Amazon Bedrock access Native PyTorch for Neuron with no additional package installation required Who should compete ML architecture and training researchers exploring model designs, optimizers, and training recipes. Familiarity with PyTorch and transformer training is expected; no hardware kernel experience is required to be competitive at the ML layer. ML systems researchers and performance engineers interested in hardware-aware optimization, custom kernels, and the interplay between model design and hardware. Familiarity with CUDA, Triton, or similar kernel programming transfers directly to NKI; no prior Trainium experience is required. Teams building with AI research agents, using LLMs and automation to run more experiments, write more kernels, and explore more architectures than any single person could. This competition rewards breadth of exploration, making agentic approaches a natural fit. Teams of one to four members are welcome. Strong submissions will likely combine multiple of these perspectives, either within a single team or via AI-assisted workflows that extend a team’s reach across the stack. What's at stake Top three finalists present their work at an exclusive Annapurna Labs research event during NeurIPS 2026 in Sydney, Australia, sharing findings with the ML community and AWS AI Chips leadership. Travel and expenses are the finalists’ responsibility Top 10 team members receive exclusive Neuron team jackets and finalist swag packs. Top three finalists have the opportunity to co-publish findings with Annapurna Labs researchers, contributing to a seminal paper on hardware-native model design. Prize pool: $25,000 (first), $10,000 (second), $5,000 (third). Key dates Aug. 31, 2026: Phase 1 opens; leaderboard goes live Sept. 30, 2026: Phase 1 closes; top 10 announced Oct. 7, 2026: Phase 2 opens on full Trn2 servers for top 10 Nov. 4, 2026: Phase 2 closes Nov. 11, 2026: Finalists selected December 6–12, 2026: Finalist presentations at competition workshop in Sydney Register by Sept 30, 2026. Other eligibility restrictions apply. See terms and conditions. The competition is open to the first 100 teams to register. Participants must be 18 or older. AWS employees, interns, and scholars (2025–2026) and their immediate family members are ineligible. Residents of certain countries are excluded; see full competition terms for details. Team sizes can be one to four participants.Register today to secure your team’s spot and start building on genuinely new silicon. The frontier is open — come find out what’s on the other side.
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.
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.
Why frontier AI models turned the vulnerability backlog into a five-alarm fire
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.
Inside Continuum's four-phase system for finding and fixing code flaws automatically
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."
How AWS convinced OpenAI and Anthropic to open their coding tools to a rival's security layer
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.
AWS adds supply chain security to its curated marketplace as open source threats intensify
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."
Why AWS chose two partners per category instead of building a security marketplace
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."
Shadow agents and AI cost harvesting emerge as the next frontier of cloud security threats
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.
How Continuum and Security Hub Extended fit together in AWS's enterprise security strategy
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."
AWS's security ambitions reflect a calculated bet on owning the orchestration layer
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.
June's AI Executive Order promotes voluntary engagement between AI developers and the federal government, emphasizing vendor management and advanced cybersecurity standards.
Executives need AI knowledge to lead transformations effectively. These leading programs vary in depth and cost, and focus on strategy, governance and practical implementation.
Brex CEO Pedro Franceschi offered a blueprint for one of the pressing challenges facing the enterprise today at VB Transform 2026: securely deploying AI agents, like the open-source OpenClaw, into production environments.
Unlocking this enterprise value requires a mindset shift. The industry needs to move past vague terminology and focus on concrete enterprise roles.
“People talk a lot about agents, but I think 'agents' is a terrible name. It's this Silicon Valley concept that doesn't really mean much,” Franceschi said.
Instead, the goal should be creating entities that can genuinely collaborate with human workers. "The concept we always had in mind was the idea of a virtual employee — someone on Slack, an entity, it has an email address, it can join meetings, you can email it, and that you can work with," Franceschi said.
Realizing this vision demands a new security paradigm. Franceschi’s presentation detailed how Brex pointed OpenClaw at internal roles, realized traditional security models failed, and built a novel network-level security layer called CrabTrap.
The OpenClaw security dilemma
The journey began following a breakthrough in December, when coding models reached a level of maturity that enabled the January release of OpenClaw. This marked the moment agents could finally self-bootstrap and maintain their own codebases instead of relying on hard-coded, static tools.
However, when Franceschi proposed deploying this to automate internal functions, the Brex security team firmly rejected the idea. “They said, 'Hell no. How could we trust an agent doing these things? This thing has code execution capabilities. There's no way to control it,'” Franceschi said. That caution isn't unique to Brex — enterprises broadly have been wary of granting agents uncontrolled code execution on corporate networks.
To solve this, Brex had to shift the security perimeter. Franceschi contrasted this with approaches like Nvidia's NemoClaw, which he said secure agents by limiting their tool usage — a model he believes neutralizes the coding capabilities that give agents their value.
“… the premise we had was that the coding capabilities were critical to the model having the ability to do a variety of tasks,” he said.
Brex's fix was to shift the security boundary to the network layer instead. Instead of policing the ever-changing code inside the container, the focus must shift to monitoring what the code actually attempts to send or receive from the outside world.
CrabTrap and the LLM-as-a-judge solution
This network-centric approach led to the creation of CrabTrap, an open-source HTTP proxy built by Brex. The mechanism operates on the assumption that OpenClaw can do anything and might already be compromised. Therefore, CrabTrap monitors all outbound network traffic between the container and the internet, using an LLM to judge whether that traffic aligns with the agent's approved policy.
“Instead of trying to control the code running in the container, assume the thing can do anything and monitor the network traffic between that container and the internet,” Franceschi said.
Using a large language model (LLM) to judge every single network request introduces unacceptable latency, often adding thousands of milliseconds to response times. Brex solved this by passing traffic through a bifurcated system.
Routine, low-risk actions pass through static, pre-approved rules instantly. If a recruiting agent tries to view a LinkedIn profile, the static rule allows it. However, high-risk actions such as sending emails are flagged and routed to the LLM judge for evaluation. Franceschi said that architecture ensures only about 2% of complex requests actually face LLM latency.
A surprising finding from the project was how effectively the LLM judge performs this role. Franceschi attributed this to the models' training: LLMs are exposed to billions of web pages and HTTP requests, giving them what he described as an inherent semantic understanding of network traffic patterns.
“[Models] are very good at discerning what is within the policy and what is not,” Franceschi said, adding that this capability emerges naturally through pre-training without needing heavy prompting.
Brex put this infrastructure to the test with “Jim,” a virtual recruiter built on OpenClaw. Jim handles various tasks, including sourcing candidates, scoring inbound applicants, and sending emails.
When Jim attempts an action that falls outside the established policy, CrabTrap relies on a human-in-the-loop workflow. If the LLM judge flags an unapproved outbound email, CrabTrap pings a human manager on Slack.
The Slack notification explains the agent's underlying intent and suggests a policy change that would allow the action. The human manager can then review the context and click "yes" or "no" to update the rules dynamically.
"I like the virtual employee analogy because a lot of these things were solved already in a company, in the context of humans," Franceschi said. "When an employee hits a wall, they escalate to their manager."
The cost of the frontier
Brex is a fintech company, not a cybersecurity vendor. The decision to build CrabTrap in-house was driven by a lack of mature commercial solutions that could satisfy their security team.
Franceschi acknowledged the inherent cost of operating at the bleeding edge, admitting that commercial vendor solutions will likely catch up.
“When we built this, it was clear to me there was a 70% chance we would throw it away in six months... But what we learned by being six months ahead was worth it in shaping our AI adoption strategy,” he said.
The investment in building internal tools provided Brex with the experience needed to safely deploy agents months ahead of the broader market. For enterprise leaders navigating the AI landscape, the core takeaway is the necessity of building the cultural and technical muscle to operate in an agentic world today.
“We don't have all the answers, but the answer is not to do nothing,” Franceschi said.
Meet GPT-5.6-Cyber, OpenAI’s cybersecurity-specific model available through Daybreak Red for authorized vulnerability research, exploit validation, and security testing.
AI tools can enhance sustainability with optimized energy use, improved predictive maintenance and streamlined supply chains while managing their own environmental impact.
While generative AI has dominated much of the technology debate in recent years, the next major phase of development may increasingly involve AI systems that can perceive, interact with and act in the physical world. The IEEE’s new Technology Megatrends 2030 report identifies physical AI and robotics as one of the areas with the greatest […]
While much of the current discussion around physical AI focuses on technologies still moving from prototype to commercial deployment, AES has already put robots to work on utility-scale solar construction sites. The global energy company developed Maximo, an AI-powered robotic system designed to automate one of the most physically demanding stages of solar construction: lifting […]
Hanyang University ERICA researchers have developed a vertically integrated dual-gate transistor design, which could give robots ‘reliable touch sensing and high density, large-area integration’. Conventional tribotronic devices, that convert mechanical stimuli like touch into electrical signals, offer fixed sensitivity and pose challenges in large-area integration. In a new study, researchers have developed a new vertically […]
PlusAI says it has reached 93.4 percent “Safety Case Readiness” as the autonomous trucking company moves toward the planned commercial launch of factory-built driverless trucks in 2027. The company has published updated performance figures for the first half of 2026, showing improvements in safety validation, autonomous driving and the number of journeys completed without assistance […]
Just as notable as what the model does is how it's licensed. Glimmer arrives under the permissive, industry-standard Apache 2.0 open source license — the company's first fully open release since it succeeded its open-weight Llama family in April with the proprietary Muse Spark.
In fact, Muse Glimmer launches today with a more permissive license than Llama ever carried. Llama's bespoke community license drew years of criticism for restrictions like its 700-million-monthly-user cutoff; Apache 2.0 has no such strings, permitting unrestricted commercial use, modification and redistribution.
The weights are available on Hugging Face now. Wang said support is rolling out this week through Ollama, LM Studio, vLLM, SGLang, Together AI, Fireworks AI and OpenRouter, with optimized llama.cpp, MLX and ExecuTorch integrations landing in the coming days; Meta's blog post also names Unsloth as a local-runtime partner and points to PyTorch's TorchTitan for fine-tuning. The company says it is working with AMD, Arm, Dell, Intel and Nvidia to optimize performance across devices, and has published developer documentation covering custom agent scaffolds.
"Today we're also opening the weights for Muse Glimmer, a great 30B parameter dense model that can run locally," Meta co-founder and CEO Mark Zuckerberg wrote in a post on X (under his longtime handle @finkd). "Soon we'll also release the weights for Muse Spark 1.2, our latest foundation model. Meta is a strong supporter of open source and I'm proud of these releases."
That promised Muse Spark 1.2 release would be an even bigger shift: it's the frontier model behind Muse Code, the terminal coding agent Meta shipped just five days ago, and until today the entire Muse family was proprietary. Zuckerberg had teased at that launch that he'd "have more to share soon" on open source. Now we know what he meant.
For developers and enterprises, the practical stakes of local inference go beyond where computation happens. An agent working with files, screenshots, development environments and other sensitive context can execute those workflows without continuously sending that information to a remote inference service. Local deployment also removes network availability and per-token API charges from the inference loop — although organizations still bear hardware, electricity, deployment and management costs.
A 30B model built around the agent loop
Rather than positioning Glimmer primarily as a general chatbot, Meta trained it around the sequence of operations an autonomous agent performs: formulate a plan, call tools, interpret the results, continue working, and recover when something goes wrong.
"Just like much larger models, muse glimmer can operate as a fully capable agent via planning, tool calls, checking its own results, and failure recovery," Alexandr Wang, Meta's chief AI officer, wrote in a thread on X announcing the release, adding that the model "can run on 24GB of VRAM without losing agentic reliability."
According to the model card on Hugging Face, Glimmer is a dense causal transformer with approximately 29.6 billion total parameters across 52 layers, including a dedicated ~1.8B-parameter ViT-G/14 perception encoder. It accepts interleaved text and images, produces text, supports more than 100 languages and has a stated context length of 131,072 tokens or more, with a knowledge cutoff of January 4, 2026.
That combination is intended to let an agent interpret screenshots, charts and documents while simultaneously reasoning about text and invoking external tools. Glimmer offers low, medium, high and xhigh reasoning settings — set via the system prompt — so applications can dial reasoning effort up or down per task, and Meta says it works across agentic scaffolds including OpenClaw and Hermes Agent.
The model is a distillation of Meta's larger flagship: per the company's technical blog post, Glimmer was pre-trained on Muse Spark's outputs using logit distillation, mid-trained on longer-context, agent-heavy data with richer reasoning traces, then post-trained with supervised fine-tuning, on-policy distillation and reinforcement learning across general, reasoning, coding and agentic domains.
Meta demonstrated the result with a local Home Assistant workflow: in a demo video, Glimmer autonomously discovers a Home Assistant instance on the network via tool calls, queries device APIs, writes a responsive HTML/CSS/JavaScript dashboard from scratch and deploys a local server to verify its own work. That's closer to the operational reality of enterprise agent deployments than a standalone question-answering benchmark — the model has to maintain a plan while interacting with external systems, then inspect whether its actions produced the expected result.
Compressing an agent into 24GB
The hardware story is central to the release.
At full precision, Meta says the 30B model requires more than 55GB of memory — beyond any single consumer GPU.
The company therefore developed approximately 4-bit quantized versions that shrink the language-model weights to under 20GB, leaving headroom for the pieces an operational agent also needs in memory: the KV cache, the perception encoder and a companion speculative-decoding model, all fitting within a 24GB or 32GB envelope.
In practical terms, that means the quantized builds run on consumer machines — though the upper end of them. The 24GB-targeted K-Quant-17GB configuration fits on a single high-end consumer graphics card, such as Nvidia's RTX 3090 or RTX 4090 (both with 24GB of VRAM), while the 32GB-targeted K-Quant-Dynamic version lines up with the newer RTX 5090's 32GB. On the Mac side, Apple Silicon's unified memory plays the role of VRAM, so a MacBook Pro or Mac Studio with 32GB or more of memory can hold the full stack — Meta ran its own speed tests on M4 Max and M5 Max MacBook Pros. A typical 8GB or 16GB laptop, however, remains out of reach, and the full-precision BF16 release — which Meta pegs at 64GB — stays in the territory of data-center GPUs and top-spec Mac Studio configurations.
Meta reports average accuracy degradation of just 0.2% across 15 benchmarks for its K-Quant-Dynamic version targeting 32GB hardware, and 1% for the K-Quant-17GB configuration targeting 24GB hardware. Those figures are Meta's own measurements, not independent evaluations.
Meta is also using DFlash speculative decoding to attack the other big problem with local agents: latency. Instead of generating every token sequentially, a smaller DFlash "drafter" model proposes blocks of 16 tokens that the primary model verifies in parallel, producing identical output faster.
Meta reports this raises average generation speed on an Nvidia RTX 5090 from 74.9 tokens per second to 233.4 — a 3.1x increase. An Apple M5 Max rises from 26.6 to 50.2 tokens per second (1.8x), and an M4 Max from 23.7 to 37.8 (1.5x). The tests used batch size one and greedy decoding, with Apple systems measured via ExecuTorch and the RTX 5090 via llama.cpp.
For agent applications, those multipliers matter more than they would for chat: a single user request can trigger many model turns, tool calls and verification steps, and latency accumulated at every stage can quickly make an otherwise capable agent impractical.
Glimmer enters an increasingly competitive local-model market
Meta is not entering an empty field. Developers already have capable open-weight models in this size class, most prominently Google's Gemma 4 family and Alibaba's Qwen3.6-27B — both of which position themselves around reasoning, multimodal understanding and agentic workloads. Meta's own benchmark table compares directly against both.
Glimmer leads that three-way comparison on several agentic tests, including MCP Atlas at 75.5, DeepSearch QA at 74.6, τ³-Banking at 23.5, WildClawBench at 47.6 and GAIA2 at 43.3. It scores 51.2 on SWE-Bench Pro, versus 36.9 for Gemma4-31B and 50.2 for Qwen3.6-27B in Meta's evaluation.
But Glimmer does not sweep the field. Qwen leads Meta's own comparison on OSWorld-Verified (75.6 vs. Glimmer's 65.9), TerminalBench 2.1 (60.7 vs. 51.7), SkillsBench, GDPval-AA (1141 vs. 953) and most of the multimodal benchmarks. On SWE-Bench Verified, Glimmer's 76.0 lands just below Qwen's 77.2. Gemma leads on GPQA Diamond and Humanity's Last Exam.
Read honestly, the numbers make Glimmer more interesting as a specialized local-agent model than as evidence of a universal performance lead. For enterprise developers, the practical question is whether its combination of agent reliability, quantization quality, tool compatibility and decoding speed translates from benchmarks into sustained real-world workflows.
The usage data reflects it: by May 2026, Chinese open-weight models accounted for roughly 61% of all tokens consumed on OpenRouter, with four of the five most-used models coming from Chinese labs — while Meta's Llama, the prior open-weight leader, fell off the rankings entirely.
The U.S. counterexamples remain countable on one hand: OpenAI's gpt-oss-120b and gpt-oss-20b, released under Apache 2.0 in August 2025 as the company's first open weights since GPT-2; Google's Gemma family, which is open-weight but ships under Google's own more restrictive custom license rather than an OSI-approved one; and Thinking Machines' Inkling.
Glimmer invites the most direct comparison to gpt-oss: both are Apache 2.0, both offer adjustable reasoning effort, and both target self-hosted deployment.
But the gpt-oss models are text-only, sparse mixture-of-experts designs built primarily for reasoning and tool use — gpt-oss-20b fits in about 16GB of memory while gpt-oss-120b targets a single 80GB data center GPU.
Glimmer stakes out different ground: a dense model with native vision input, trained end-to-end around the agent loop, shipping with its own quantized variants and speculative-decoding drafter tuned for 24GB consumer machines.
And if Zuckerberg follows through on opening Muse Spark 1.2's weights, Meta would put an actual U.S. flagship frontier model into open circulation — something no American lab has done at that tier.
Safety remains part of the deployment architecture
Giving a local model access to tools creates a different security problem from deploying a local chatbot — and Meta's own safety numbers show Glimmer is not uniformly stronger than its peers.
On CI Memories, a privacy benchmark where lower violation rates are better, Glimmer records 26.4 against Gemma's 12.1 and Qwen's 53.4. On Siren AgentDojo, a prompt-injection test, Glimmer shows a 28.4% attack-success rate versus 25.6% for Gemma and 40.3% for Qwen — while posting the highest utility score of the three at 94.2.
Meta says it evaluated Glimmer under its Advanced AI Scaling Framework and determined the model does not meet the framework's definition of "Frontier AI" because it is generally less capable than Muse Spark. Its Preparedness Team assessed Glimmer at Moderate or lower risk across chemical/biological, cyber and loss-of-control categories — the latter two inferred from the fact that Glimmer is broadly weaker than Muse Spark 1.0, which received the same designations.
The company nevertheless recommends deploying Glimmer as part of a broader system with guardrails, including human-in-the-loop confirmation for irreversible actions. That caveat matters especially for local agents: keeping data on-device reduces exposure to cloud infrastructure, but local execution does not by itself solve prompt injection, excessive permissions or an agent taking an unintended action.
Apache 2.0 weights and a fast-growing runtime ecosystem
Meta is releasing full-precision BF16 weights, both 4-bit quantized variants, the DFlash drafter and the perception encoder — all under Apache 2.0. There is no Meta API price attached to the downloadable model, leaving total cost dependent on local hardware or whatever third-party hosting developers choose. One nuance worth noting for procurement teams: as with most "open source" model releases, it is the weights that are open — Meta has not released the training data or training code.
The broader implication is that Meta is treating the developer workstation as a credible deployment target for autonomous agents, rather than merely a place to experiment with smaller language models. Glimmer's 30B size and 24GB target put that proposition within reach of high-end consumer hardware, while the Apache 2.0 license gives developers — and their legal departments — unusual freedom to modify and deploy it.
The next test is whether its benchmark advantages survive the messier conditions of real software repositories, enterprise tools and long-running agent sessions. If they do, the most consequential part of Glimmer may not be another set of benchmark scores — it may be that a class of agent previously expected to live behind a cloud API can increasingly live, and work, on the machine sitting under a developer's desk.
Login
