Two weeks after debuting its more naturalistic GPT-Live audio AI model with full-duplex capabilities (listening and speaking at the same time), OpenAI is bringing it directly into developer workflows. The company announced that GPT-Live now powers the ChatGPT desktop application on macOS and Windows, integrating directly with agentic systems like Codex and ChatGPT Work (which are separate experiences available in the ChatGPT desktop app). When OpenAI initially launched GPT-Live on July 8, 2026, it introduced a continuous audio model capable of listening and speaking simultaneously—eliminating rigid turn-taking while delegating complex reasoning to background models like GPT-5.5. Today's release expands that conversational layer to technical tasks, enabling software engineers to orchestrate multi-threaded coding jobs, review pull requests, and debug applications using natural voice commands. As such, it could usher in a new era of "hands free" software development and even live, in-person group coding parties for the more than 10 million weekly active users across Codex and ChatGPT Work . Codex, of course, is the name given to OpenAI's models and harness focused on coding, but which the company has this year expanded into a more general productivity platform. An OpenAI spokesperson told
VentureBeat
this is the first time voice activation OpenAI posted a promotional video showing some of its employees, Codex developer experience engineer Jason Liu and Codex technical staffer Guinness Chen, speaking to the same ChatGPT desktop app session in the same room, each issuing different instructions and conversing with the same model. New capabilities unlocked At its core, this integration relies on decoupling the real-time voice layer from the underlying execution engines. While GPT-Live maintains fluid conversation—inserting natural verbal acknowledgments like "got it" without interrupting the user—it passes heavy computational workloads to background reasoning models. On macOS, the desktop application incorporates "Appshots" and screen context features, allowing ChatGPT Voice to analyze the frontmost window alongside local files, codebase structures, and active plugins. This architecture creates a pair-programming dynamic where developers talk through problems conversationally while agents execute tasks asynchronously. Rather than manually stopping coding sessions to type detailed instructions or switch windows, developers direct the system hands-free. The full-duplex engine dynamically decides when to speak, pause, or invoke tools, maintaining conversational state even as background agents process complex code modifications. Directing coding and complex builds with your voice alone The central operational capability in this update centers on multi-task execution across Codex and ChatGPT Work environments. Software engineers can initiate multiple concurrent task threads from a single spoken prompt. For instance, a developer preparing to ship a feature can instruct the system to investigate an open authentication bug, review a pending API migration pull request, and generate missing unit tests simultaneously. The desktop application coordinates these actions across disparate contexts, tracing issues through Slack conversations, GitHub repositories, and local codebases. Developers can also verbally convert design mockups into working code, splitting tasks across frontend, backend, and testing layers. With support for multi-folder projects (build 26.715) and remote execution via iOS, engineers can check task progress, answer agent prompts, and redirect active jobs without switching applications or managing individual processes line by line. Proprietary license OpenAI’s voice-enabled desktop release operates under a proprietary, commercial enterprise model. Access is restricted to paid subscribers across Plus, Pro, Business, Enterprise, and Education plans. For individual developers and corporate engineering departments, this commercial structure means the model weights, voice processing pipelines, and agent state architectures remain fully closed. Organizations cannot modify or self-host the underlying systems. Furthermore, tasks initiated via ChatGPT Voice consume standard usage allocations directly from existing Codex and ChatGPT Work plan quotas, treating voice-triggered actions identically to standard agentic workloads. Community reactions Developer communities immediately noted the implications of bringing continuous full-duplex voice to autonomous coding workflows. Reacting to the build 26.715 release announcement—which details voice integration and multi-folder project support—AI Insider journalist @ChrisGPT noted on X : "Today OpenAI will release voice and remote guidance for codex ! One step closer to personal AGI". Early technical feedback highlights widespread enthusiasm for orchestrating complex agentic tasks hands-free, particularly when stepping away from the workstation or managing build pipelines remotely.
Black Forest Labs (BFL) is expanding its FLUX family beyond image generation with today's launch of FLUX 3 , a multimodal frontier model trained to understand and generate images, or combined audio/video clips up to 20 seconds from a single prompt — and to extend the same underlying architecture to robotic vision and actions. The Freiburg, Germany-based AI lab says FLUX 3 is jointly trained across those modalities rather than assembling separate image, video and audio models behind a common interface. That distinction is central to the company's pitch: BFL wants enterprises to think about creative generation, simulation, computer use and robotics as connected applications of a single capability it calls visual intelligence — models, in the company's words, "that can perceive, predict, and act across physical and digital environments." This release marks BFL's first public video generation model. FLUX 3 will be offered through four product lines: FLUX 3 Video, FLUX 3 Image, FLUX 3 Action and the upcoming, open source FLUX 3 Dev. FLUX 3 Video, with optional native audio generation, and FLUX 3 Action are entering a gated "Early Access" program now , to which anyone can apply, but which BFL must approve. There is presently no public access through BFL's application programming interface (API) or those of partners yet, but the company says FLUX 3 Image will roll out in the coming weeks, followed by general availability. The limited initial availability rollout echoes the release strategies of new models from other frontier labs in the U.S. lately, including Anthropic and OpenAI , though those were ostensibly for security concerns and due to government request. What the company has not announced is pricing, production service-level commitments, evaluation methodology, sample sizes, rater counts or any image-model benchmarks at all. Enterprise buyers therefore cannot yet calculate total cost of ownership or independently reproduce the video comparisons. Another big notable omission: FLUX 3 is not launching with downloadable weights at this time, nor an open source license. BFL says faster and open-weight versions will arrive later this year, and its technical blog names FLUX 3 Dev as "open-weight access to a multimodal backbone, for content creation (video, audio and image) and action prediction" — a considerably broader commitment than any previous FLUX Dev release, all of which covered images only. But it arrives last in the sequence. Developers accustomed to receiving a locally deployable FLUX variant alongside — or soon after — a major model announcement will have to wait. That delay does not negate the company's commitment, but it is disappointing given the role open weights have played in FLUX's adoption thus far. Flux 3 is rated higher than the competition, but missing pricing and benchmarking details may prevent rapid enterprise adoption BFL has published several benchmark comparisons, but they're qualified as preliminary — with full benchmark results and methodology to be published later during broader general availability. In early head-to-head preference testing on 10-second, 720p text-to-video clips with audio, the company says FLUX 3 was preferred over Luma Ray 3.2 in 93% of comparisons, Runway Gen-4.5 in 77%, Grok Imagine Video in 69%, Kling v3 Pro in 60%, Happy Horse v1 in 59%, Happy Horse 1.1 in 57%, and both Seedance 2.0 and Google's Gemini Omni Flash in 52%. One caveat travels with every one of those figures, and it comes from BFL itself. The chart carrying the results is labeled a "preliminary evaluation of an early FLUX 3 candidate" — meaning the numbers describe a pre-release checkpoint rather than the model now entering early access. That cuts both ways: the shipping model may perform better, but nothing published today measures what customers will actually call. Luma Ray 3.2 and Runway Gen-4.5, where FLUX 3 posted 93% and 77%, are the softest comparisons on the list — established products, but not the models currently setting the pace in independent video rankings. Those are real wins, and they are the ones least likely to change an enterprise shortlist. Seedance 2.0, at 52%, is a statistical coin flip against a model most Western enterprises cannot currently procure. ByteDance indefinitely postponed Seedance 2.0's international rollout after Netflix, Warner Bros., Disney, Paramount and Sony sent legal threats over alleged systematic copyright infringement, and that suspension remains in place. Tying a frozen product is neither a strong claim nor a damaging one. Gemini Omni Flash , also at 52%, matters much more. Omni is the closest large-platform analogue to what FLUX 3 is attempting — multimodal input, video and audio-aware creation, conversational editing — and by BFL's own measurement, the two are indistinguishable on 10-second text-to-video quality. Google's advantage in that matchup is that Omni is generally available via Google's Gemini API for $0.10 per second of generated 720p video, or a 10-second clip for around. One regional wrinkle matters for a German company's home market. Editing uploaded video is unavailable to Omni Flash users in the European Economic Area, Switzerland and the United Kingdom, though editing video the model itself generated is permitted. A European enterprise that wants to run its existing footage through a generative editing pass cannot currently do so on Omni Flash. Here's a rough guide for enterprises considering which video models to rely upon: Model Max single-generation duration Max resolution Key constraints Price per 10-second clip (720p) Price per 10-second clip (1080p) Price per 10-second clip (4K) FLUX 3 Video 20 seconds Not stated; evaluations run at 720p Early access; no published SLA or pricing Not announced Not announced Not announced HappyHorse 1.1 15 seconds 1080p No 4K; closed weights Not published (v1.0 reseller rate is ~$1.82) Not published (v1.0 reseller rate is ~$3.12) n/a Veo 3.1 Per-second billing 4K Supports clip extension; preview $4.00 $4.00 $6.00 Veo 3.1 Fast Per-second billing 4K Preview $1.00 $1.20 $3.00 Veo 3.1 Lite Per-second billing 1080p No 4K, no clip extension; preview $0.50 $0.80 n/a Gemini Omni Flash 10 seconds (3s minimum) 720p at 24 FPS Preview abd no EU access $1.00 n/a n/a One architecture for media generation and physical action FLUX 3 builds on Self-Flow , BFL's method for aligning multimodal understanding and generation within one architecture, publicized back in March 2026. The company says it significantly scaled up compute and data to train across video, images and audio simultaneously, and that testing showed video generation and action prediction do not require separate foundations — the same architecture could be extended to action prediction without sacrificing what it learned from video. "We place vision at the center of our approach because it is the most signal-rich medium of the physical world. Images convey structure, images and video teach spatial relationships, video teaches dynamics, and actions reveal causal relationships. But vision alone is not the complete picture," said Robin Rombach, co-founder and CEO of BFL, in a pre-release statement provided to VentureBeat. "True intelligence means perceiving the world: predicting how it will change, taking action, and learning from the results. Joint training within one unified architecture is what will get us there, because each training modality strengthens the others. Audio conveys timing, prosody, and physical events that elude vision. Language conveys goals, abstractions, and instructions that pixels cannot easily express." He put the case more bluntly elsewhere in the announcement: "You can't cheat reality. A model that only learns images can only generate images. But the world is not made of still frames. It moves, sounds, changes, and responds." BFL says FLUX 3 targets creative tooling, media, design, e-commerce and physical AI, supporting video generation with synchronized audio, precise image editing, product and material consistency across motion, multilingual generation and robotic action prediction. It is already being tested by Canva, Burda, Magnific (formerly Freepik), Krea and Picsart. For creative software companies, the appeal is consolidation. A single foundation could potentially support storyboarding, image editing, product rendering, video variation and localization without repeatedly translating assets and instructions between disconnected models. For robotics teams, the potential value is data efficiency. Models that already encode motion, object behavior and physical change may need less task-specific robot training than systems starting from raw demonstrations. What FLUX 3 Video can actually do The video tier is the most concretely specified part of the launch, and it settles a question that had been circulating as rumor: FLUX 3 generates clips of up to 20 seconds with audio in a single generation. Every video output comes with native audio. For comparison, HappyHorse 1.0 tops out at 15 seconds of 1080p with synchronized audio — though BFL has not stated what resolution its 20-second clips run at, and its published evaluations were conducted at 720p. Still, a 20-second long clip from a single prompt is among the longest yet achieved, matching OpenAI's discontinued Sora model. The capability list BFL published covers: Text-to-video generation. Image-to-video generation, either animating from a starting frame or using images as visual references. Video-to-video generation from a reference clip, carrying elements such as a specific character into a new scene or context. Generative video-audio continuation from existing video and audio input. Keyframe-to-video generation for controlled transitions between defined moments. Multilingual dialogue. A broad range of visual styles and aspect ratios, from candid camcorder footage to animation and cinematics. Typography generation and animated design. Agentic chaining of individual clips into longer, multi-shot sequences. That last item is the one enterprise video teams should look at hardest. BFL claims the capabilities combine to produce sequences lasting several minutes, with visual references keeping characters consistent across scenes. If that holds up under production conditions, it addresses the constraint that has kept generative video out of most commercial pipelines: not clip quality, but continuity across shots. It is also the capability where competition is most direct. HappyHorse 1.1's headline upgrade is R2V, or Reference-to-Video, which accepts multiple character reference images to hold identity stable across generated footage — the same problem, approached at the input layer rather than through agentic clip chaining. Alibaba also claims zero-drift lip sync and has specifically targeted the artifacts that mark commercial AI video as synthetic, including facial oiliness and over-sharpening. Character consistency is where this category is being contested, and both companies know it. BFL says FLUX 3 Video is already particularly strong at human facial expressions, associating sounds with physical events, and multilingual output. On the image side, the company says preliminary evaluations conducted during midtraining show significant improvement over earlier FLUX versions in complex prompt handling and text generation, including high-accuracy text in multiple languages. It published no image benchmarks or win rates. FLUX-mimic tests whether video models can become robot models BFL is applying its unified-architecture thesis through FLUX-mimic, a video-action model built on FLUX 3 and developed with Swiss firm Mimic Robotics, one of the first partners to receive early access. The technical blog describes two distinct routes to action prediction: integrating native action prediction directly into FLUX 3, scaling up the initial Self-Flow work; and using the pretrained video backbone as a dynamics-aware foundation from which specialized action models can be finetuned with limited task-specific data. FLUX-mimic is the second route — the FLUX 3 backbone combined with mimic's robot-learning and production-deployment expertise in dexterous manipulation. FLUX-mimic is designed for general-purpose robotic manipulation: helping robots understand a visual scene, predict the consequences of an action, and adapt to new tasks with far less task-specific data. BFL and Mimic Robotics say that depending on task difficulty, the model can be finetuned for a specific manipulation task with as little as 30 minutes of robot data, where prior approaches have required 30 or more hours. "The hardest part of robotics is data," said Elvis Nava, CTO of Mimic Robotics, in a statement provided to VentureBeat. "Every new task normally means hours of a robot repeating itself. Because FLUX-mimic is built on top of frontier video models that already understand how the physical world behaves, it picks up a new task in minutes, not days. This way, we can leapfrog the current state of the art in robot learning." BFL argues that a model trained only on images cannot understand a world that "moves, sounds, changes, and responds," and that physical understanding is what produces convincing generated footage. Google makes a nearly identical claim for Gemini Omni. Its developer documentation cites "world knowledge" that combines "an understanding of physics" with Gemini's grasp of history, science and cultural context. Its marketing is blunter still: "Most AI models just predict the next pixel to build a narrative or an image. Gemini Omni is different," the company posted in June, crediting the model with "an intuitive understanding of forces like gravity, kinetic energy, and fluid dynamics for more realistic movements that follow real-world logic." The practical consequence for enterprise buyers is that world-model language is not a differentiator. Two of the three leading video systems now market physical understanding as their central advantage, and neither has published a benchmark that measures it. There is no standard test for whether generated water behaves like water, whether a dropped object falls at a plausible rate, or whether a sound arrives when the impact does. Human preference ratings capture some of it indirectly. Nothing else on offer captures it at all. Open weights helped make FLUX an industry standard BFL officially launched in summer 2024 and gained a name for itself in the AI industry in the intervening two years for its commitment to open sourcing high-quality AI image models beloved by developers, creatives, and enterprises. The company's founders, including Rombach, Andreas Blattmann and Patrick Esser, previously helped create VQGAN, latent diffusion and Stable Diffusion , the latter the open source technology that kicked off broad AI generation capabilities for the masses and currently used by many AI image generators and companies. That reach translated into commercial distribution. FLUX models now power generative features inside Adobe Photoshop, Picsart and Nous Research's Hermes Agent, among other platforms, and the company cites film director Martin Scorsese among professional users. Wired magazine described Black Forest Labs as a relatively small company that nevertheless became a leading competitor to Silicon Valley's largest AI labs, with FLUX models ranking near the top of image benchmarks and becoming some of the most downloaded text-to-image models on AI code sharing community Hugging Face. The company says it now runs a 100-person team across Freiburg and San Francisco. FLUX.1 Dev, FLUX.1 Kontext Dev, FLUX.1 Fill Dev and related control models, released shortly after the firm's launch, gave researchers and creative-tool developers access to downloadable checkpoints, local inference and integrations with frameworks including Hugging Face Diffusers and ComfyUI. FLUX.1 Kontext Dev, for example, was released as an open-weight model for research and noncommercial use, with generated outputs permitted for commercial purposes under the applicable license. The company continued that pattern with FLUX.2 Dev in late 2025, a 32-billion-parameter open-weight model combining generation and multi-reference editing. Black Forest Labs called it the strongest open-weight image generation and editing model available at launch and released weights, reference inference code and optimized implementations for consumer Nvidia GPUs. FLUX 3 Dev raises the stakes on that evaluation. Previous Dev releases were image models. This one is described as a multimodal backbone spanning video, audio, image and action prediction — meaning a single license will govern whether a company can locally deploy a model that touches both content production and physical machinery. BFL hasn't yet shared information about its license, the parameter count, quantizations or hardware requirements. The company frames open weights as an enterprise feature rather than a community gesture, arguing they enable secure, low-latency local deployment for applications like robotic control systems and let teams adapt FLUX 3 to their own data, products and workflows. The financial backing behind FLUX 3 is worth noting alongside the technical claims. Black Forest Labs is valued at $3.25 billion and has raised more than $450 million from investors including a16z, AMP, Salesforce Ventures, Nvidia, General Catalyst, Adobe Ventures, Figma Ventures, Canva and Deutsche Telekom's T.Capital.
When Cisco ran 6,986 multi-turn attacks against 15 flagship models , attackers who adapted across the conversation broke through as often as 88.3% of the time. Amy Chang, Cisco's head of AI threat intelligence and security research, brought that finding to the agentic security panel at VB Transform 2026 ; the number should worry anyone still running single-turn red-teaming programs. VentureBeat's June 2026 Pulse survey of 107 enterprise respondents explains why the room was full. More than half, 54%, have already had a confirmed agent security incident (18%) or a near-miss caught before harm (36%). Just 32% give every agent its own scoped, managed identity, and fewer still, 30%, isolate their highest-risk agents in sandboxes. Provider-native and hyperscaler controls remain the primary agent security layer at 82% of companies surveyed . The world's largest security vendors have done the same math. Palo Alto Networks closed its $25 billion acquisition of CyberArk in February, CrowdStrike agreed in January to pay $740 million for SGNL , and Cisco announced its intent to acquire Astrix Security for a reported $400 million, all of it aimed at the identity and isolation layer most enterprises have not finished building. Chang came to the panel with almost two decades of experience spanning cybersecurity operations, government, and the military. She ran global cybersecurity operations as an executive director at JPMorgan Chase, where she led the bank's cyber threat intelligence teams, and served as a senior staffer on the House Foreign Affairs Committee and as a U.S. Navy Reserve officer. She also teaches cybersecurity and emerging threats as adjunct faculty at the Middlebury Institute of International Studies. Chang's 88.3% number comes from a study she co-authored with Nicholas Conley, built on 30,090 single-turn prompts and 6,986 multi-turn attacks against those 15 closed and proprietary flagship models. Multi-turn success rates ranged from 7.89% to 88.3%, every model tested showed non-trivial multi-turn exposure, and the two testing styles did not even rank the models in the same order. Cisco publishes adversarial evaluation signals for what is now 105 models on its LLM Security Leaderboard , she told the audience. "If you don't understand how models are susceptible to different types of attacks, then you are unable to account for how that model that is powering your agent, that is powering your application, to understand where those failure points are," Chang said. Single-turn testing is the one-shot malicious prompt, she explained, while extending an attack into a longer conversation "is more realistic of how we are actually engaging with our models, with our agents, with our applications." That longer arc surfaces harmful outputs and misaligned behaviors that a snapshot never catches. Cisco has pushed the testing itself into agentic territory. Chang described a framework where agents assess a deployment scenario, develop relevant attacks, judge whether they are worth pursuing, execute them, and evaluate their own success. What surprised her most, after all that sophistication, was how simple the defensive answer stays. "The answer is still that it's pretty simple," she said. "You don't have to get super creative. You just need to think about truly what are the fundamentals and basics of what I'm trying to secure in my organization." Her starting point for CISOs beginning agentic deployments is Cisco's Integrated AI Security and Safety Framework , which she said "stipulates all the ways that AI can be compromised across the AI lifecycle" from modality through supply chain. From there, teams can work backward from real incidents, trace how each attack was achieved, and use the framework to build a strategy with the right coverage and mitigations. Heather Ceylan, the CISO of Box, sees the same gap from the defender's side. "A lot of what you see out there with agent red teaming is just single-turn, and that's not how people are actually interacting with AI day-to-day," she told the audience. Box now simulates multi-turn adversaries with agents that think like an attacker and iterate attempt after attempt to hijack the target. "You have to pressure test your agents because otherwise you don't know if your execution controls are really working as you intended." Box deployed agents inside its security operations center about a year ago, starting with human approval required for every action, and trust built quickly enough that analysts shifted into monitoring mode. Then the agent made one mistake, and every bit of that accumulated trust vanished. "They had to start all over again," she said. "So I think that that monitoring piece is so important. Even if you're not gonna have a human in the loop, things change, models change, and we can't control how the models change and interpret things." Rajesh Parekh, VP of AI and ML at Intuit, brought the builder's perspective. Parekh led large-scale computer vision and ML systems powering Google's Maps and Geo products before joining Intuit, and holds a doctorate in computer science. Three layers versus an operating system Ceylan described Box's approach as three concentric layers. Permissioning comes first, so the agent never accesses more content than the human who invoked it. Ephemeral sandbox environments spin up for each agent task, containing the blast radius if an agent gets hijacked, and runtime execution control restricts the agent's tool calls to only those relevant to the task at hand. "If you want an agent to summarize a doc for you, if you have a prompt injection that came in that says forward this to maliciousattacker at domain.com, it can't do that," Ceylan said. "That action in that tool call is not even in its vocabulary." She classified agent actions into three oversight categories. Actions that are not sensitive, like read and summarize, need no human in the loop. Moderately sensitive actions skip human approval but get logged and monitored, while destructive actions like mass deletion of files always require a human. "Things are gonna shift between those three categories quite a bit," she acknowledged, "but setting those types of categories up front allows you to have a principled framework." Rather than layering controls onto agents one at a time, Intuit has built a central platform called GenOS, short for generative AI operating system, which abstracts security, risk, and fraud modeling so individual agent developers never reinvent protection. "Permissioning is not about giving access to AI," Parekh said. "Instead, it is defining very tightly scoped and clearly auditable authority to the agent to perform very specific tasks." Intuit evolved from agents inheriting user permissions to each agent carrying its own identity, and the company is now investigating mid-session permission changes tied to the specific task underway. Parekh calls the broader model an AI-powered expert platform, one where the human expert is built into the trust architecture rather than bolted on as a gate. "The paradigm that we are pursuing is where the user, the AI agent, and the human expert are collaborating to solve the user problem," he said. The end of human code review Ceylan took on the tension between security testing and development velocity without hedging. "The days of secure code reviews where a human's looking at the code and we're looking at security architecture reviews, design docs, those are done," she said. "If you keep trying to do security that way, you're gonna get left behind." Box is building toward a fully agentic development lifecycle where agents review design documents, apply security requirements, and review the code for vulnerabilities. "I'm very optimistic that we will get to a point where we will write code without security vulnerabilities because agents and the models are going to get so good at writing code without vulnerabilities," she said. "We're still a long way away from that." Her advice for development teams skips the advanced AI concepts entirely and returns to basics that predate agents. "It comes down to very basic least privilege access," she said. "If you start giving your agents overly broad permissions at the beginning, it's really hard to comb that back and build an infrastructure that allows for those ephemeral credentials and only those narrowly scoped tasks." Parekh explained why the red teaming surface has expanded so quickly. "These agents have skills, and skills could become vulnerabilities," he said. "Agents have access to certain data, they have access to tools, and there could be threats that are lurking within those tools as well. So suddenly the blast radius of the malicious code or the intent increases dramatically." When Intuit identifies common vulnerability patterns from its manual red teaming exercises, it automates those tests back into the GenOS harness so future agents inherit protection and red teamers stay focused on new threat vectors. Runtime scanning of prompts and responses adds a final layer that can stop a suspect response and escalate to a human expert, he said. "You need to continuously test to ensure that those remain robust to the protections that you have built, as well as to account for any sort of drift or any other types of dependencies that you introduce into your scenario that can create novel vulnerabilities," he said. Intent versus probability An audience question about intent detection set off the sharpest exchange of the session. Ceylan noted that when Box's own agent operates, the system always knows the user's intent because it controls the prompt, which means guardrails and tool-call restrictions can be engineered around it. The harder challenge, which she admitted Box is still trying to solve, arrives when external agents connect and the context behind the request is opaque. That exchange exposed a split running through the wider industry. Mastercard, in the fireside chat immediately preceding the panel, came down on the side of quantifying intent, building an open-source framework to propagate it as a standard because complex B2B procurement cannot work without that trust. Endpoint security CTOs, in briefings with VentureBeat, have gone the other way, saying they will bet on probability rather than intent inference for production workloads. Chang explained why models, as they are trained today, cannot reliably derive intent from a prompt, which is why deterministic controls and behavioral proxies remain necessary. Ceylan agreed that both are required. "If you're not doing anything deterministic, you're really relying heavily on that intent, and I haven't seen programs that are there yet," she said. Ceylan's story about trust collapsing after a single agent mistake landed as the panel's most memorable moment because enterprise agentic security is not a problem that gets solved and stays solved. Models change, permissions drift, and adversaries adapt across multi-turn conversations that snapshot tests never capture. For the 82% of enterprises relying on provider-native controls as their primary security layer, and the 59% shopping for agent security tooling over the next 12 months, the panel's takeaway was blunt. Test the way attackers attack, across full conversations and continuously, or find out in production what your single-turn red teaming missed.
Across 107 enterprises, AI infrastructure spending is accelerating well ahead of the ability to see or steer its economics. Most organizations run their AI on a familiar base of hyperscalers and model-provider APIs, yet the next dollar is aimed at specialized compute almost none of them use today; a majority intend to switch or add providers within the year, many within a quarter. Buying decisions turn on integration and total cost of ownership rather than headline token price — which is fortunate, because most enterprises cannot yet see their unit economics clearly: GPUs sit at half utilization or less, and fewer than half rigorously track what their compute actually costs. The result is a compute gap — heavy, fast-moving investment running ahead of the visibility needed to control it. This wave of VentureBeat Pulse Research examines enterprise AI infrastructure and compute: where organizations are in their deployment journey, what they run AI on today, how satisfied they are, what would make them switch, where they plan to evaluate their investments, and — most revealingly — how well they can measure and control the economics of the compute underneath it all. The central finding is a compute gap — the distance between how aggressively enterprises are investing in AI infrastructure and how little of its economics they can see. Only about one in five (21%) run AI in production at scale, yet spending intentions are outrunning that maturity: the single largest planned area enterprises plan to evaluate over the next year is AI-specialized clouds (45%), a layer almost none of these enterprises use today. Meanwhile the compute already in place runs cold — 83% report GPU utilization of 50% or less — and fewer than half (44%) can rigorously track what their AI compute costs. Enterprises are buying more infrastructure faster than they can account for what they already own. Enterprises are not settled on their infrastructure vendors, either: A clear majority (64%) plan to switch or add an infrastructure provider within twelve months, and 38% within the next quarter — unusually high churn intent for a category this foundational. When they choose, they choose on integration with the existing stack (41%) and total cost of ownership (35%), not on headline price: cost per million tokens is the deciding factor for just 8%. And the frontier constraint that will shape the next round of decisions — the shift from GPU compute to memory bandwidth as inference scales — is barely on the radar, with roughly one in five enterprises either unaware of it or yet to address it. This report is one of five in VentureBeat Research's Q2 study of the agentic stack. Cost is the control with the least instrumentation: More than eight in ten GPU operators report utilization at half capacity or less, and a minority rigorously track compute cost and return. The executive summary, "VentureBeat Research: Where enterprise AI agent governance hasn't caught up," places that finding in the full pattern. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series, this survey focused on enterprise AI infrastructure, compute, and inference economics. Responses are filtered to organizations with more than 100 employees (n=107; the survey’s smallest size band, 1–100 employees, is excluded), drawn from a single Q2 2026 (June) wave. Because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%. By organization size the sample concentrates in the mid-market: 101–250 employees (36%) and 251–1,000 (27%) lead, with 1,001–5,000 (22%), 5,001–10,000 (8%), and 10,001+ (7%) above them. By role it spans managers (38%), individual contributors (28%), VPs and directors (19%), and the C-suite (13%); on purchasing authority it is buyer-credible, with 45% final decision-makers and another 30% recommenders or influencers for AI solutions. Technology/Software is the largest industry at 26%, followed by Healthcare/Life Sciences (15%), Financial Services (13%), and Retail/E-commerce (12%). At 107 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It also skews toward the mid-market and toward earlier-stage adopters, so it is best read as the view from organizations actively building out AI infrastructure rather than from the largest hyperscale operators. Finding 1: Ambition outpaces production Only one in five run AI in production at scale We asked where organizations sit in their AI deployment journey. Most are still building toward production rather than operating at scale. The maturity curve is front-loaded. Three-quarters of enterprises (76%) are either experimenting or running only some workloads in production, and just 21% describe AI in production at scale. This matters for everything that follows: the infrastructure decisions in this report are being made largely by organizations still early in deployment, whose compute footprint — and whose costs — are about to grow. The evaluation and switching intentions in Findings 3 and 4 are the leading edge of that build-out, not the settled preferences of operators who have already found what works. Finding 2: Enterprises run on hyperscalers and model APIs The specialized GPU clouds barely register — today We asked which providers and platforms enterprises currently use to run their AI. The answer is a familiar one: the incumbents. The current stack is hyperscaler-and-API. Google Cloud leads at 48%, and the general-purpose clouds (Google, Microsoft, AWS, Oracle) together with the major model APIs (Gemini, OpenAI, Anthropic) account for essentially all current deployment. The specialized “neocloud” GPU providers that dominate AI-infrastructure headlines — CoreWeave, Lambda, Crusoe, Nebius and peers — register at or near zero among these enterprises today. Only 6% run their own on-prem GPU clusters and 4% a custom open-source stack. Enterprises are, for now, running AI on the providers they already buy from — which makes the evaluation intentions in Finding 3 all the more striking. (A note on reading these shares. As described in the methodology section, this sample is self-selected and skews mid-market, and this question counted every provider a respondent uses — an average of 2.1 selections each — so the figures measure presence in the stack rather than spending or primary status. A sample built this way will show a different provider mix than a spend-weighted census of the broader market; Google's strength here, for example, is consistent with its long-standing position among smaller enterprises building on AI. Read these shares as a portrait of what this AI-active cohort runs today, and treat gaps between these figures and industry-wide market share estimates as a property of the sample rather than a contradiction of either.) Finding 3: The next dollar goes to infrastructure they don’t yet run AI-specialized clouds top the evaluations list We asked where enterprises planned to evaluate AI infrastructure over the next 12 months. Their answers point away from the stack they run today. Here is the report’s sharpest tension. The single most-cited planned evaluation area — AI-specialized clouds, at 45% — is the very category almost none of these enterprises use today (Finding 2). Nearly a third (32%) intend to evaluate non-Nvidia accelerators, and 28% in next-generation Nvidia silicon; even decentralized compute networks (16%) and sovereign compute (11%) draw meaningful interest. Read against current usage, this is not incremental — it is the leading edge of a re-platforming. The direction-of-travel question tells the same story: every infrastructure approach is net-expanding, but specialized AI clouds carry the highest net momentum (+24), edging out even the hyperscalers (+22). Enterprises are preparing to move a meaningful share of AI compute off the general-purpose cloud. This continues a trend we saw in our April-May survey wave. Back then, usage of the AI-specialized clouds was equally marginal — CoreWeave at 3%, Lambda at 4%, Crusoe at 2% of enterprises. When we asked enterprises what change they planned in their AI infrastructure strategy over the next twelve months, the most-cited answer was moving workloads to specialized AI clouds, at 33%. Asked in April-May which emerging compute option they were most likely to evaluate AI-specialized clouds again drew the most responses. Two waves, two differently worded questions, one consistent picture: the type of cloud enterprises are most eager to assess is the type they have barely begun to use. Finding 4: A switching wave is building Six in 10 plan to change providers within a year — many within a quarter We asked whether and when enterprises plan to switch or add an infrastructure provider. Very few intend to stand still. For a category as foundational as compute, this is a remarkable amount of intended movement. Only 36% have no plans to change, meaning a clear majority (64%) intend to switch or add a provider within twelve months — and 38% within the next quarter alone. Where that interest points is telling: the providers drawing the most switching consideration are again the incumbents — Microsoft Azure and Google Cloud (33% each), OpenAI (30%), and Gemini (22%) — which suggests much of the near-term movement is reshuffling among the majors and consolidating spend rather than defecting to new entrants. The neocloud interest in Finding 3 is a 12-month evaluation thesis; the switching in the next quarter is mostly incumbents trading share. ( Method note: Respondents who selected both "no plans to change" and a specific switching window are counted as switchers, on the logic that naming a timeframe is the more specific answer; three respondents were reclassified under this rule. ) Finding 5: Nobody buys on token price Integration and total cost of ownership decide — not sticker price We asked what matters most when enterprises select an AI infrastructure provider. Headline price finished last. Enterprises do not buy AI infrastructure on pricing, which is the place vendors compete on hardest. Integration with the existing stack (41%) and total cost of ownership (35%) dominate, while the headline metric — cost per million tokens — is the deciding factor for just 8%, dead last. The pattern is coherent: buyers are optimizing for how a provider fits and what it truly costs to operate, not for the advertised unit rate. It also foreshadows Finding 7 — enterprises say TCO matters most, yet most cannot yet measure it rigorously. The stated priority and the measured capability are out of step. Finding 6: Expensive GPUs, idle most of the time 83% report GPU utilization of 50% or less We asked what share of their GPU capacity enterprises actually utilize. The answer is a well-known but rarely quantified inefficiency. Disclosure: Band percentages count every selection against all 107 qualified respondents; 14 respondents selected more than one band, so bands overlap. At the respondent level, 83 of the 100 GPU-operating enterprises reported utilization at or below 50% The compute already in place runs cold. Adding the bands at or below half capacity, 83% of enterprises that operate GPUs report utilization of 50% or less, and nearly half (49%) run at 25% or below. Only 12% clear the 50% mark, and a further 8% do not measure utilization at all. Idle accelerators are expensive accelerators, and this is the clearest single measure of the compute gap: enterprises are planning to buy more GPUs and specialized compute (Finding 3) while the capacity they already own sits substantially unused. The efficiency headroom in the current fleet is large — and largely unmeasured. Finding 7: Spending fast, measuring slowly Fewer than half rigorously track what their compute costs We asked whether enterprises can quantify the cost and return of their AI infrastructure spend, and how satisfied they are with what they run. Confidence in the ledger lags the spending. Measurement trails money. Fewer than half of enterprises (44%) rigorously track the cost and return of their AI compute; the majority track only partially (39%), cannot quantify it yet (20%), or have not prioritized it (6%). That gap is consequential given Finding 5, where total cost of ownership was the second-ranked buying criterion — enterprises are choosing providers on an economic basis they mostly cannot yet measure. Satisfaction with current infrastructure is moderately positive but not enthusiastic: on a five-point scale, overall satisfaction averages 4.0, with ease of implementation (3.8) and value for money (3.9) trailing slightly — the softness landing, tellingly, on cost. Enterprises are spending quickly and accounting slowly. Finding 8: The next bottleneck few are watching As inference shifts from compute to memory, the field scatters Finally, we asked how enterprises would address the emerging constraint in large-scale inference — the shift from GPU compute to memory, specifically KV-cache capacity. The responses reveal a frontier that is not yet a priority. The memory frontier is real but barely governed. Asked which approach they would rely on as the binding constraint in inference shifts from compute to memory bandwidth, enterprises scatter: Dell leads at 31%, Nvidia follows at 16%, and the rest fragments across storage vendors, open-source tooling, and model-level efficiency techniques. Most telling is that roughly one in five (18%) either do not recognize the constraint or have not begun to address it. For a shift that will reshape inference cost and architecture, this is an early and unsettled market — and, consistent with the measurement gap in Finding 7, one where many enterprises simply do not yet have a view. It is the next chapter of the compute gap, arriving before most have closed the current one. The bottom line: A compute gap that faster spending will widen, not close Organizations with more than 100 employees are investing in AI infrastructure faster than they can measure it. Most are still early in deployment, yet their spending intentions point past their current stack — toward specialized clouds and alternative accelerators almost none of them run today — and a clear majority intend to change providers within the year. They buy on integration and total cost of ownership rather than headline price, which is rational; the difficulty is that most cannot yet see those economics clearly. The visibility gap is concrete. The GPUs enterprises already own run at half utilization or less for the overwhelming majority, and fewer than half can rigorously track what their compute costs or returns. Satisfaction is decent but unenthusiastic, softest on value for money — the dimension hardest to judge without measurement. And the next constraint, the shift from compute to memory in large-scale inference, is arriving while most enterprises are still unaware of it. At 107 respondents in a single Q2 wave this is a directional read, skewed toward the mid-market and earlier-stage adopters — but the direction is consistent: the appetite to spend is running well ahead of the instrumentation to spend well. The compute gap is not a capacity problem that more hardware will solve on its own; it is, first, a problem of seeing what the hardware already costs. The open question for later waves is whether enterprises build that visibility before the re-platforming arrives — or buy the next layer of infrastructure as blind to its economics as the last. Based on survey responses from 107 qualified enterprise respondents (100+ employees), drawn from a single Q2 2026 (June) wave. Because this is one wave rather than a pooled multi-month sample, the results read cross-sectionally rather than as a month-over-month trend, and at 107 respondents this is a directional signal rather than a precise measurement — the sample is self-selected, skews mid-market, and leans toward earlier-stage adopters rather than the largest hyperscale operators. Respondents include managers, individual contributors, VPs/directors, and the C-suite, with buyer-credible purchasing authority, across Technology/Software, Healthcare/Life Sciences, Financial Services, Retail/E-commerce, and other industries.
Across 107 enterprises, AI agents are being given real access to systems and data while the controls meant to contain them lag behind. More than half have already had a confirmed agent security incident or a near-miss; only about a third give every agent its own scoped identity, and most agents still share credentials; and only three in ten isolate their highest-risk agents. The security stack is overwhelmingly borrowed from the model providers and hyperscalers rather than purpose-built for agents, spending remains a thin slice of the security budget, and enterprises are evenly split on whether their defenses are keeping pace with AI-enabled attackers. The result is an agent security gap — autonomous agents proliferating faster than the identity, isolation, and enforcement controls needed to hold them. This wave of VentureBeat Pulse Research examines how enterprises secure their AI agents: what tooling they run, how they manage agent identity and isolation, what has already gone wrong, how much they spend, and whether they believe their defenses are keeping pace with AI-enabled attackers. The central finding is an agent security gap — the distance between the autonomy enterprises are granting their agents and the controls in place to contain them. More than half of organizations (54%) have already experienced a confirmed agent security incident (18%) or a near-miss caught before harm (36%). The structural weakness beneath those numbers is identity: only about a third (32%) give every agent its own scoped, managed identity, while the rest report that some agents share credentials or that agents mostly run on shared API keys and human or service-account credentials. When agents share credentials, a single compromised or over-permissioned agent carries a wide blast radius — and only three in ten enterprises (30%) isolate their highest-risk agents in sandboxes to bound that radius. What makes the gap notable is how comfortable enterprises are inside it. The security stack is overwhelmingly provider-native — OpenAI’s guardrails (51%), Google’s and Microsoft’s cloud controls, and Anthropic’s managed-agent controls dominate, while the dedicated agent-security specialists barely register — and satisfaction with that borrowed stack is high, averaging 4.2 out of 5. Yet spending remains a thin slice of the security budget, only a third of enterprises believe their AI defenses are ahead of AI-enabled attackers, and a clear majority plan to change tooling within the year. Enterprises are satisfied with controls they are simultaneously preparing to replace. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series, this instrument focused on enterprise agent security — the tooling, identity, isolation, and enforcement controls organizations use to secure autonomous AI agents. Responses are filtered to organizations with more than 100 employees (n=107; the survey’s smallest size band, 1–100 employees, is excluded), drawn from a single June 2026 wave. Because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%. By role the sample is senior and buyer-credible: 45% are final decision-makers for AI purchases and another 30% recommenders or influencers. Managers (43%), individual contributors (24%), VPs and directors (15%), and the C-suite (11%) make up the seniority mix. By organization size the sample is mid-market-weighted: 251–1,000 (42%) and 101–250 (25%) employees lead, with 1,001–5,000 (19%), 5,001–10,000 (8%), and 10,001+ (7%) above them. Technology/Software is the largest industry at 23%, followed by Manufacturing (15%), Retail/E-commerce (14%), and Healthcare/Life Sciences (13%). At 107 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It skews toward the mid-market, so it is best read as the view from organizations actively standing up agent security rather than from the largest operators. Satisfaction ratings are computed on the respondents who answered each rating question; the overall satisfaction score reflects 82 of the 107 qualified respondents. Finding 1: The incidents are already here More than half have had an agent security incident or near-miss We asked whether organizations had experienced an agent security incident — a confirmed breach, or a near-miss caught before harm. Most that run agents in production had. This is the report’s defining number. More than half of organizations (54%) have already had an agent security event — 18% a confirmed incident and 36% a near-miss caught before it caused harm. Only 42% report nothing, and a small remainder either run no agents in production or don’t track such events. That so many report near-misses rather than only confirmed incidents is telling: enterprises are catching problems, but they are catching them close to the edge. The controls examined in the rest of this report — identity, isolation, enforcement — are what determine whether the next near-miss stays a near-miss. Exposure scales with company size, but containment does not. The incident-or-near-miss rate rises from 49% in the mid-market (companies with 101-1,000 employees) to 63% at larger enterprises (above 1,000 employees), while sandbox isolation of high-risk agents falls from 35% to 20%, and satisfaction with security tooling drops from 4.36 to 3.97. The organizations running the most agents across the most systems carry the most incidents and the least of the one control that bounds an incident's blast radius. Finding 2: The identity gap Only a third give every agent its own scoped identity We asked how enterprises manage the identity of their AI agents — whether each agent has its own credentials, or agents share them. Full per-agent identity is the exception. Rolled together, the overlapping answers show 69% of enterprises (74 of 107) with credential sharing somewhere in the agent fleet. Identity is the structural weakness beneath the incidents. Only about a third of enterprises (32%) give every agent its own scoped, managed identity — the precondition for least-privilege access and clean attribution. Nearly half (48%) say some agents have scoped identities but many still share credentials, and another 32% say agents mostly run on shared API keys or borrowed human and service-account credentials. (Respondents could describe more than one pattern across their agent fleet, so these overlap.) The consequence is direct: when agents share credentials, an over-permissioned or compromised agent can act with far more reach than intended, and forensics after an incident cannot cleanly tell which agent did what. The non-human identity problem — giving every agent its own governed identity — is the single largest unfinished piece of enterprise agent security. Moreover, a company’s agent credential posture is correlated with incidents. Organizations with credential sharing anywhere in the fleet were hit — with an incident or a near-miss in the past twelve months — at 63.5% (47 of 74). Organizations where every agent carries its own scoped identity were hit at 40.9% (9 of 22). The fully-scoped group is small, so for now the relationship is an association rather than proven causation, and the gap is concentrated in the mid-market — but within a single survey, a twenty-three point difference in incident rate suggests significance. Finding 3: Observe and enforce, but rarely isolate Only three in 10 sandbox their highest-risk agents We asked what an organization’s agent security posture looks like in practice — whether they observe, enforce, isolate, or some combination. The control that bounds damage is the least common. Monitoring and enforcement are reasonably common; containment is not. Roughly half of enterprises observe agent activity (47%) or enforce scoped permissions at runtime (49%), but only 30% isolate their highest-risk agents in sandboxes that bound the blast radius when the other controls fail. That ordering is backwards from a defense-in-depth standpoint: observation tells you what happened, enforcement tries to prevent it, but isolation is what limits the damage when prevention fails — and it is the control enterprises have adopted least. Combined with the identity gap in Finding 2, the picture is of agents that are watched and permissioned but rarely boxed in, which is precisely the configuration in which a single failure propagates. Finding 4: Security runs on borrowed, provider-native controls Guardrails from OpenAI, Google and Microsoft dominate; specialists barely register We asked which agent security tooling enterprises use, and which is their primary layer. The answer favors the model providers and hyperscalers over the dedicated security vendors. Enterprises are securing agents with tools that came bundled with their models and clouds. OpenAI’s guardrails lead at 51%, followed by Google’s and Microsoft’s cloud-native controls and Anthropic’s managed-agent controls — and when asked to name their single primary security layer, 82% name one of these provider-native offerings. The purpose-built agent-security category — Palo Alto’s Prisma AIRS, CrowdStrike, Cisco AI Defense, Zenity, HiddenLayer, Check Point’s Lakera, Okta for AI Agents, non-human identity platforms — barely registers, each in the low single digits, and only 5% run no dedicated tooling at all. As with retrieval and evaluation elsewhere in this series, the provider bundle is winning the default: enterprises reach first for the guardrails their platform ships, and the independent security layer that would address the identity and isolation gaps has not yet been adopted at scale. The provider-default pattern is consistent across both Q2 survey waves. In April–May (n=110), usage was led by the same names — OpenAI's controls at 26%, Azure at 15%, AWS at 14%, Google at 12% — with every dedicated agent-security specialist at 3% or below and one in ten using no dedicated tooling at all. The common finding from the two surveys: Enterprises are defaulting to the solutions provided by the platform they’re using, and the specialist category vendors have yet to become big players here. ( A note on reading these shares. As described in the methodology section, the respondent sample is self-selected and skews mid-market, and the usage question counted every vendor or approach a respondent has in place — so the figures measure presence in the security stack rather than spending or exclusivity. Individual vendor percentages therefore carry all the usual sample caveats. The structural pattern, however, held across both Q2 waves on two differently worded questions: provider-native and hyperscaler controls lead, and dedicated agent-security specialists remain in low single digits. Read the individual shares loosely and the pattern with confidence.) Finding 5: And enterprises are comfortable with it Satisfaction is high, even as incidents mount and identity lags We asked how satisfied enterprises are with their current agent security tooling. The comfort is notably out of step with the exposure documented above. Satisfaction with agent security tooling is high — 4.2 out of 5 overall, and 4.1 for value for money — among the most positive readings in this series. That is the striking part: enterprises are highly satisfied with a stack that is mostly borrowed provider guardrails, even though more than half have already had an incident or near-miss and only a third give their agents scoped identities. The comfort appears to rest on the convenience and low friction of provider-native controls rather than on demonstrated containment. It is a false comfort in the making — the same enterprises expressing satisfaction are, as Finding 8 shows, a clear majority planning to change tooling within the year, which suggests the confidence is thinner than the score implies. Finding 6: Budgets haven’t caught up Most spend under a tenth of the security budget on agents We asked what share of the security budget enterprises allocate to securing AI agents. For a fast-emerging risk, the allocation is modest. Spending on agent security is still a thin slice. The most common allocation is 6–10% of the security budget (46%), and a third of enterprises (34%) spend 5% or less; only a quarter (24%) devote more than a tenth. Given the incident rate in Finding 1 and the identity and isolation gaps in Findings 2 and 3, the budget looks like a lagging indicator — the risk has arrived faster than the funding to address it. The enterprises spending more than a tenth of their security budget on agents are a distinct minority, and they are likely the ones building the scoped-identity and isolation controls the rest have not. Finding 7: The arms race is even, at best Only a third think their AI defenses are ahead of AI-enabled attackers We asked how enterprises assess the balance between their AI-enabled defenses and AI-enabled attackers. Confidence is far from settled. Enterprises are split on whether they are winning. Only about a third (35%) believe their AI-enabled defenses are ahead of AI-enabled attackers; the rest are less sure — 32% call it roughly even, 21% think attackers are ahead, and another 21% say it is too early to tell. Taken together, a clear majority (53%) rate the balance as even or tilted toward the attacker. That uncertainty sits uneasily beside the high satisfaction of Finding 5: enterprises are content with their tooling yet unconvinced it is winning the contest it exists to win. In a domain where the offense is also compounding with AI, an even race is not a comfortable place to be. Finding 8: A security reshuffle is coming Nearly six in 10 plan to adopt or switch tooling within a year We asked whether enterprises plan to adopt a new, additional, or replacement agent security solution, and which they are considering. Few intend to stand pat. The security stack is not settled. While 41% have no plans to change, a clear majority (59%) intend to adopt a new, additional, or replacement agent security solution within twelve months, and 29% within the next quarter — a strong signal that, high satisfaction notwithstanding, enterprises know the current stack is provisional. Incidents are what start the buying cycle. Among organizations that have been hit, 42.1% plan to adopt, add, or replace agent security tooling within the next ninety days, against 14.0% of organizations with no incident — and after a confirmed incident it becomes majority behavior, at 52.6%. Getting hit also changes the threat assessment: 33.3% of hit organizations say AI-armed attackers are ahead of their defenses, against 8.0% of the unhit. Experience, in this data, is the strongest predictor of both urgency and pessimism. The consideration set still leans provider-native (OpenAI 34%, Google 30%, Anthropic 29%, Azure 25%), but the dedicated security vendors — Cloudflare, Cisco, Palo Alto, Okta, Check Point’s Lakera — draw early interest in the mid-to-high single digits, more than their current footprint. What the shopping does not yet include is the identity layer specifically. Twelve percent of the respondents include an agent-identity product — Okta for AI Agents, Microsoft Entra Agent ID, or a non-human identity platform — anywhere in their consideration set, and among the credential-sharing organizations that have already had an incident, identity consideration is essentially unchanged, at roughly one in ten. The control most directly implicated by the incident data is the one largely missing from the purchase plans. Whether this wave hardens the provider-native default or finally opens the door to purpose-built agent security — the identity and isolation controls the incidents call for — is the question this series will keep tracking. The bottom line: A security gap that autonomy will test first Organizations with more than 100 employees are giving AI agents real reach into systems and data while securing them with controls built for something else. More than half have already had an incident or near-miss; only a third give every agent its own scoped identity, and most still share credentials; only three in ten isolate their highest-risk agents; and the stack doing this work is overwhelmingly borrowed from the model providers and hyperscalers rather than purpose-built for agents. The uncomfortable pairing is confidence with exposure: satisfaction with the current tooling is among the highest in this series, yet spending is a thin slice of the security budget, only a third believe their defenses are ahead of AI-enabled attackers, and a clear majority are already planning to replace what they have. At 107 respondents in a single wave this is a directional read, skewed toward the mid-market — but the direction is clear: agent adoption is running ahead of agent security, and the controls that matter most when something fails — scoped identity and isolation — are the ones enterprises have built least. The agent security gap is not a coverage problem that a provider guardrail will close on its own; it is a problem of identity, isolation, and enforcement built for autonomous software. The open question for later waves is whether enterprises close it deliberately — or whether a confirmed incident closes it for them. Based on survey responses from 107 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. This is a directional read, not a precise measurement — the sample is self-selected and skews mid-market, so it's best read as the view from organizations actively standing up agent security rather than from the largest operators. Respondents are senior and buyer-credible (45% final decision-makers, 30% recommenders/influencers), spanning managers through the C-suite, and drawn primarily from Technology/Software, Manufacturing, Retail/E-commerce, and Healthcare/Life Sciences.
Across 101 enterprises, the infrastructure that feeds AI agents their business context is being built faster than it can be trusted. Retrieval-augmented generation is already the default context source, and provider-native retrieval has quietly overtaken the dedicated vector databases that define the category — yet a majority of enterprises have already watched their agents produce confident, wrong answers traced to missing or inconsistent context. A governed semantic layer is emerging as the fix, but most are still building it; the field is converging on hybrid retrieval; and even as provider-native tools lead in practice, a plurality say they intend to keep best-of-breed. The result is a context gap — agents that sound authoritative running on a foundation their owners do not yet fully trust. This wave of VentureBeat Pulse Research examines the enterprise RAG and context layer: what feeds AI agents their business context, which retrieval systems enterprises run, how they buy and measure them, where the architecture is heading, and — most revealingly — how often that context is already failing them. The central finding is a context gap — the distance between how confidently enterprise agents answer and how reliable the context beneath them actually is. A majority of enterprises (57%) report that in the past six months their AI agents produced confident but wrong answers they traced to missing or inconsistent business context, and more than half of those said it happened more than once. This is not a fringe failure: retrieval is the primary context source for 38% of enterprises, more than any other approach, so when retrieval is thin or inconsistent, the errors it produces are wearing the agent’s authority. The infrastructure to fix it is being built — 58% already run or are building a governed semantic layer — but for most it is not yet in production. Underneath, the market is consolidating in a direction that surprises. Provider-native retrieval — OpenAI’s file search (40%) and Google’s Vertex AI Search (38%) — already leads every dedicated vector database, and enterprises expect hybrid retrieval to dominate by the end of 2026 (34%). Yet a plurality (36%) say they intend to keep best-of-breed standalone tools rather than consolidate onto a provider’s native context stack, and a majority (57%) plan to switch or add a provider within the year. Stated preference and actual usage are pulling in opposite directions — the market is buying provider-native while insisting it wants independence. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series. This survey focused on enterprise RAG infrastructure and the context layer — the retrieval systems, semantic layers, and context sources that feed AI agents. Responses are filtered to organizations with more than 100 employees (n=101); the survey drew no responses from organizations of 100 or fewer, so the full sample qualifies. All responses are from a single Q2 2026 (June) wave, so the report reads cross-sectionally and does not infer month-over-month trends. Several questions were multiple-select, so those shares can sum to more than 100%. By organization size the sample concentrates in the mid-market: 251–1,000 employees (31%) and 101–250 (31%) lead, with 1,001–5,000 (20%), 5,001–10,000 (12%), and 10,001+ (7%) above them. By role it spans managers (39%), individual contributors (27%), the C-suite (16%), and VPs and directors (14%); on purchasing authority it is buyer-credible, with 46% final decision-makers and another 26% recommenders or influencers. Technology/Software is the largest industry at 20%, followed by Healthcare/Life Sciences (11%) and a broad spread across retail, transportation, financial services, manufacturing, and education. At 101 respondents this is a modest sample and should be read as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It is best read as the view from organizations actively standing up RAG and context infrastructure rather than from the largest operators. Finding 1: Confident and wrong More than half have traced agent errors to bad context We asked whether, in the past six months, enterprises had traced a confident but wrong agent answer to missing or inconsistent business context. Most had. This is the report’s defining number. A majority of enterprises (57%) have already had an AI agent produce a confident, wrong answer they traced to bad context — wrong metrics, stale definitions, or missing documents — and more than half of those have seen it happen more than once. Only 28% report no such failure, and a small remainder either don’t run agents on enterprise data or don’t trace root cause closely enough to know. The failure mode is specific and dangerous: the model is not obviously hallucinating; it is confidently wrong because the context feeding it was thin or inconsistent. Everything else in this report — what enterprises retrieve, how they govern it, and what they plan to build — is downstream of this problem. Finding 2: RAG is the default context source Retrieval feeds more agents than any other method We asked what an enterprise’s AI agents primarily use to understand its data. Retrieval leads by a wide margin. Retrieval is the backbone of enterprise context. For 38% of organizations, RAG over documents or a vector index is the primary way agents understand the business — nearly twice the share of the next approach, a governed semantic layer or ontology (21%). Mixed approaches (14%), direct live-system queries (10%), and long-context loading (6%) fill out the rest, and only 2% let agents run on the model’s general knowledge alone. The concentration matters in light of Finding 1: because so much enterprise context flows through retrieval, the quality of that retrieval is the quality of the answer. When RAG is the default source, thin retrieval is not an edge case — it is the main failure surface. One approach is notable for its absence from these answers: customizing model weights, also known as fine-tuning. Every leading source of business context is injected at run time. Our most recent direct measurement of fine-tuning comes from our April–May survey wave (a separate survey, n=136), where fine-tuning capabilities ranked last of six factors in model selection at 5% — even as 26% of that sample still named fine-tuning and customization an investment they expect to grow. Fine-tuning has fallen out of the primary selection conversation; context injection is how enterprises make agents knowledgeable about their business. Finding 3: Provider-native retrieval already leads the vector databases OpenAI file search and vertex AI search top the dedicated tools We asked which retrieval systems enterprises run in production today. The answer favors the model providers and hyperscalers over the specialists. The dedicated vector database is no longer the center of the RAG stack. OpenAI’s file search (40%) and Google’s Vertex AI Search (38%) lead — provider-native and hyperscaler-native retrieval — ahead of every purpose-built vector database. Among the specialists, the most-used is the one enterprises already run for other reasons (Elasticsearch/OpenSearch, 20%) and the open, embedded option (pgvector, 12%); the pure-play vector databases that define the category — Weaviate, Qdrant, Pinecone, Milvus — each sit in single digits to low double digits. Notably, 13% of enterprises say they still run no production RAG at all. As with the platforms in the parallel infrastructure wave, enterprises are gravitating to retrieval that comes bundled with tools they already buy. The shape of this finding held across both Q2 waves. In April–May (n=161), provider-built retrieval led usage there too, while every dedicated vector database remained marginal — the most-used standalone vector database peaked at 8% of that sample — and the hybrid, pluralistic future was already the consensus expectation (34% expected hybrid retrieval to dominate, with another 29% expecting multiple architectures by use case). Two waves, consistent picture: the category that coined the “vector database” term is being collected by the platforms enterprises already buy from. Finding 4: But they say they want to keep best-of-breed A plurality resist consolidating onto a provider’s native stack We asked how enterprises will respond as model providers bundle retrieval, memory, and orchestration into their platforms. Their stated intent cuts against their current usage. Here is the tension at the heart of the stack. Even as provider-native retrieval leads in practice (Finding 3), a plurality of enterprises (36%) say they intend to keep best-of-breed standalone tools rather than consolidate onto a provider’s native context stack — well ahead of the 21% who plan to consolidate. Another 21% expect a mix, and 9% intend to build and own the layer themselves. The gap between what enterprises run and what they say they want is the strategic question of the category: they are adopting bundled retrieval for convenience while asserting they will preserve independence. Which impulse wins — the pull of the provider bundle or the stated preference for modular control — will shape the retrieval market more than any single tool. Finding 5: Hybrid retrieval is the consensus bet Vector-only retrieval is already seen as insufficient We asked which retrieval architecture enterprises expect to dominate their production RAG systems by the end of 2026. The field is converging — with a large share still unsure. The architecture is settling on hybrid. A third (34%) expect hybrid retrieval — embeddings combined with reranking and access controls — to dominate their production systems by the end of 2026, three times the 11% who expect vector-only retrieval to prevail. That is a notable signal: the pure vector-search approach that launched the category is already viewed as insufficient on its own, superseded by pipelines that add reranking for accuracy and access controls for governance — the very access controls whose absence produces the failures in Finding 1. Tellingly, the second-largest answer is uncertainty: 17% simply don’t know, and another 14% expect to move beyond a dedicated vector layer entirely toward tool-first or long-context retrieval. The consensus is not a single tool but a layered pipeline — and it is not yet fully formed. Finding 6: The governed context layer is being built now Most run or are building a semantic layer — few in production We asked whether enterprises use a governed semantic or context layer to give agents and BI a shared understanding of their data. Most are on the path; fewer have arrived. The fix for the context gap is under construction. Well over half of enterprises (58%) either run a governed semantic layer in production (25%) or are piloting and building one (34%), and a further 17% are actively evaluating — meaning three-quarters are engaged with the idea in some form. But the balance is telling: more are building than have shipped, so for most enterprises the shared, governed definition layer that would prevent the "confident but wrong" failures of Finding 1 is still a work in progress. The semantic layer is the industry’s answer to inconsistent context; this wave catches it mid-construction, ambition well ahead of production. Finding 7: Bought on ingestion and simplicity, watched for correctness Selection favors operability; monitoring favors correctness and security We asked what matters most when enterprises choose a retrieval system, and what they track once it is running. Both answers lean practical. Enterprises choose retrieval systems on operability. Ease of data ingestion (36%), latency and performance (32%), and operational simplicity (29%) lead the selection criteria — ahead of retrieval accuracy and access control (23% each), the two factors most directly tied to the failures in Finding 1. Once systems are running, the emphasis shifts toward trust: the most-tracked metrics are response correctness (42%) and security and access control (38%), ahead of latency (28%), operational stability (27%), and answer relevance (23%). Satisfaction with current systems is moderately positive but not enthusiastic — on a five-point scale, overall satisfaction averages 4.0, with ease of implementation and value for money both near 3.9. Enterprises buy for how easily a system runs and watch it for whether it can be trusted. Finding 8: A retrieval reshuffle is coming A majority plan to change providers — and the vector specialists are gaining interest We asked whether enterprises plan to change or add a retrieval provider, and which they are considering. The consideration set differs from today’s stack. The retrieval stack is not settled. While 43% have no plans to change, a small majority (57%) intend to switch or add a provider within twelve months, and a quarter (26%) within the next quarter. The consideration set is where it gets interesting: provider-native retrieval still leads what enterprises are evaluating (OpenAI 22%, Vertex AI Search 21%), but the open-source vector specialists punch above their current footprint — Qdrant (14%) and Milvus (13%) draw more switching interest than their present usage (10% and 6%) would suggest. Read with Finding 4, the picture is a market in flux: enterprises run provider-native today, are evaluating a broader field, and say they want to keep their options open. The reshuffle ahead will test whether best-of-breed intent survives contact with the convenience of the bundle. The bottom line: A context gap that more retrieval alone won’t close Organizations with more than 100 employees are wiring agents into their business faster than they can guarantee the context those agents run on. Retrieval is the default source of enterprise context, and it increasingly comes from the model providers and hyperscalers rather than the dedicated vector databases — yet a majority of enterprises have already watched agents answer confidently and wrongly because that context was thin or inconsistent. The failure is not exotic; it is the predictable result of pointing authoritative-sounding agents at an unreliable foundation. The industry’s answer — a governed semantic layer, hybrid retrieval with reranking and access controls — is being built but is mostly not yet in production, and enterprises are pulled between the convenience of provider-native bundles and a stated preference for best-of-breed independence. At 101 respondents in a single Q2 wave this is a directional read, skewed toward the mid-market — but the direction is clear: the context layer is the next contested tier of the AI stack, and right now agents are running ahead of it. The context gap is not a retrieval-volume problem that more documents or bigger indexes will solve on their own; it is a problem of governed, consistent, access-aware context. The open question for later waves is whether enterprises finish building that layer before the confident-but-wrong failures move from the lab into decisions that matter. Based on survey responses from 101 qualified enterprise respondents (100+ employees), drawn from a single Q2 2026 (June) wave. At this sample size the results should be read as a directional signal rather than a precise measurement — it's a self-selected sample, not a probability sample, and skews toward the mid-market. Respondents include managers, individual contributors, VPs/directors, and the C-suite, with strong purchasing authority, across technology, healthcare, retail, transportation, financial services, manufacturing, and education.
Across 157 enterprises, organizations are granting AI agents more autonomy while trusting the evaluations meant to gate that autonomy less. Half have already shipped an agent that passed their internal evaluations and then failed a customer in production; only one in twenty fully trusts automated evaluation today; and the most-cited weakness is that evaluations do not align with real-world outcomes. Yet two-thirds already allow, or are actively engineering toward, deploying agent changes to production on automated evaluation alone — with no human in the loop. The result is an evaluation gap — the distance between how much autonomy enterprises are handing their agents and how far they trust the tests that are supposed to catch the failures. This wave of VentureBeat Pulse Research examines how technical leaders measure agent performance: which reliability and evaluation platforms they use, how they select and trust them, what breaks in production, and how far they are willing to let agents run without a human in the loop. The central finding is an evaluation gap — the distance between the autonomy enterprises are granting their agents and the trust they place in the evaluations meant to govern it. Half of organizations (50%) have, in the past year, deployed an agent or LLM feature that passed their internal evaluations and then caused a customer-facing failure, and a quarter have seen it happen more than once. Trust in the tests themselves is thin: only 5% say they fully trust automated evaluation today, and the single most-cited limitation is that evaluations align poorly with real-world outcomes (29%). Enterprises are discovering that a passing eval is not the same as a working agent. What makes the gap consequential is the direction of travel. Two-thirds of organizations (66%) already permit fully automated, zero-human-in-the-loop deployment for low-risk agents (34%) or are actively engineering their pipelines to allow it within twelve months (33%). At the same time, the evaluation stack that would have to earn that trust is fragmented and immature: the most common primary tools are the model providers’ native evals, tied with having no dedicated tooling at all (17% each); and only about a quarter of enterprises run real-time quality checks on live production traffic. The autonomy is arriving faster than the assurance. Methodology VentureBeat fielded this survey as part of its ongoing Pulse Research series, this survey — the Agentic Reliability & Evals tracker — focused on how technical leaders evaluate agent performance and reliability. Responses are filtered to organizations with 100 or more employees (n=157), drawn from a single survey in June 2026; because this is one wave rather than a pooled multi-month sample, the report reads cross-sectionally and does not infer month-over-month trends. Where questions were multiple-select, those shares can sum to more than 100%. By role the sample is senior and buyer-credible: 38% are final decision-makers for AI purchases and another 34% recommenders or influencers. Product and program managers (15%), consultants and advisors (10%), directors of engineering/IT (8%), and CIOs/CTOs/CISOs (8%) lead the named titles, alongside a large “Other” function (37%). By organization size the sample is mid-market-weighted: 100–499 (37%) and 500–2,499 (27%) employees lead, with 2,500–9,999 (20%), 10,000–49,999 (10%), and 50,000+ (6%) above them. Technology/Software is the largest industry at 23%, followed by Retail/Consumer (15%), Healthcare/Life Sciences (12%), and Manufacturing (10%). At 157 respondents the sample is large enough to read directionally but should be treated as a directional signal rather than a precise measurement; it is self-selected and is not a probability sample. It skews toward the mid-market, so it is best read as the view from organizations actively standing up agent evaluation practices rather than from the largest operators. Note: This survey was rebuilt for the June wave from the earlier “LLM observability and evaluations” survey; because the questions and sample differ, no comparisons are made to the April–May data. Finding 1: A passing eval is not a working agent Half have shipped an agent that passed evals, then failed a customer We asked whether, in the past 12 months, organizations had deployed an agent or LLM feature that passed their internal evaluations but then caused a customer-facing failure. Half of those that run evaluations had. This is the report’s defining number. Half of organizations (50%) have shipped an AI feature that cleared their internal evaluations and then failed in front of a customer — an incorrect output, a broken workflow, or a quality incident — and a quarter have seen it happen more than once. Only 36% report no such failure, and the remainder either run no pre-deployment evaluations (8%) or don’t track the root cause closely enough to know (6%). The failure is precise and expensive: the evaluation said the agent was ready, and it was not. Everything that follows — how enterprises trust their evals, what they monitor, and how much autonomy they grant — is shaped by this experience. Finding 2: Almost no one fully trusts automated evaluation The top complaint: Evals don't match real-world outcomes We asked which limitation most reduces trust in automated agent evaluations today. Only a sliver of enterprises had no complaint at all. Trust in automated evaluation is scarce, and specific. Only 5% of organizations say they fully trust automated evaluation as it stands — meaning 95% name a limitation that holds them back. The most common, at 29%, is the one that most directly explains Finding 1: evaluations align poorly with real-world outcomes, passing agents that later fail. Bias or inconsistency (21%) and a lack of explainability (18%) follow — enterprises cannot always tell why an evaluation reached its verdict — and 17% cite data-leakage or privacy concerns in the evaluation process itself. The tests meant to certify agents are not yet trusted to certify them, which is precisely why the autonomy trajectory in Finding 3 is so striking. Finding 3: The autonomy ceiling is rising anyway Two-thirds already allow, or are building toward, zero-human deployment We asked whether organizations would let an autonomous agent deploy a code or system change to production on automated evaluation results alone, with no human-in-the-loop validation. The trajectory runs straight through the trust gap. Here is the paradox at the heart of the report. Even though almost no one fully trusts automated evaluation (Finding 2), two-thirds of organizations (66%) either already allow zero-human-in-the-loop deployment for low-risk agents (34%) or are actively engineering their pipelines to permit it within a year (33%). Only 22% rule it out for the foreseeable future. The direction is unambiguous: enterprises are moving to let evaluations gate production autonomously — removing the human check — at the same moment they say those evaluations don’t reliably match reality. The autonomy ceiling is rising faster than the assurance beneath it, which is the mechanism by which the false-confidence failures of Finding 1 will scale rather than shrink. Notably, the autonomy bet is not just a small company phenomenon. Splitting the sample by company size, larger enterprises are slightly further down the path toward zero human review than smaller companies (70% versus 64%) and slightly more likely to have shipped an evaluation-passing agent that then failed a customer (54% versus 48%). The assumption that large, regulated organizations are holding the human in the loop longest is, in this sample, backwards. To be sure, these are directional figures, since the survey was not a huge sample — 57 respondents from companies with 2,500+ employees and 100 from companies smaller than that. Finding 4: The evaluation stack is fragmented and provider-led Provider-native evals lead — tied with no dedicated tool at all We asked which agent reliability or evaluation platform enterprises primarily use today. The market has no clear leader — and a large share has nothing dedicated. The evaluation layer is early and unconsolidated. Provider-native tooling leads — OpenAI’s native evals and traces (17%) and Anthropic’s Claude Console evals (13%) together outweigh any independent platform — but it is tied at the top by a striking answer: 17% of enterprises use no dedicated agent-evaluation tooling at all, a notable gap for organizations shipping agents to customers. The specialist evaluation vendors — DeepEval (12%), Braintrust (8%), LangSmith, Weave, Promptfoo, Langfuse, Arize — are scattered across single to low double digits, and 11% have built their own. No independent platform has yet become the category standard, which leaves most enterprises evaluating agents with provider-native tools, home-grown scripts, or nothing. Finding 5: Production monitoring rarely watches output quality Only a quarter run real-time quality checks on live traffic Production monitoring for an AI agent can watch two very different things. It can watch whether the system is functioning — is the agent up and responding, did each request complete, how fast, at what cost, with any errors. Or it can watch whether the agent's output is correct — automated checks that evaluate the content of each answer as it goes out: did the agent give the right answer, take the right action, stay within policy. The distinction matters because a confidently wrong answer is invisible to the first kind of monitoring: the request completes, the response is fast, no error is thrown, and every functioning-metric reads healthy. We asked organizations which kind their live production monitoring is built for today. Grouped by what is actually being watched, the split is stark: 51% of organizations monitor only whether the agent is functioning, while 23% monitor whether its answers are right. Counting the ad-hoc reviewers and the don't-knows, roughly three-quarters of organizations run no automated, real-time evaluation of output correctness in production — they can see that the system is up and what it costs, and they are taking the correctness of its answers on faith. That blind spot is the runtime counterpart to the pre-deployment gap in Finding 1: the same organizations engineering the human out of the deployment decision mostly cannot see, in real time, when the deployed agent starts getting things wrong. Finding 6: Bought on cost, measured on consistency Price and integration drive selection; evaluation consistency is the goal We asked what most influenced enterprises’ choice of an evaluation vendor, and what they treat as their primary measure of success. Both answers are pragmatic. Enterprises buy evaluation tooling on economics and trust it on repeatability. Cost of evaluations (28%) narrowly leads selection, just ahead of ease of integration (27%) and evaluation accuracy (24%) — breadth of observability (13%) and vendor roadmap (4%) matter far less. On what success looks like, more than a third (36%) name evaluation consistency — getting the same verdict on the same behavior every time — well ahead of speed of experimentation (19%), reduction in failures (18%), production visibility (13%), and compliance (11%). The emphasis on consistency is telling: before enterprises can trust an evaluation’s verdict, they need it to be stable — the very property whose absence (bias and inconsistency) ranked among the top trust limitations in Finding 2. Satisfaction with current tooling is only moderate, averaging 3.8 on a five-point scale across overall satisfaction, ease of implementation, and value for money. Finding 7: The next dollar goes to humans and observability Investment is flowing to oversight, not just automation We asked which reliability and evaluation investment will grow most over the next year. The money is going toward watching agents more closely — including with people. The second-largest planned investment — behind only production observability — is human review workflows, at 26%. Read against Finding 1, that is the report's quietest contradiction: at the same moment two-thirds of enterprises are engineering the human out of the deployment decision, more of them plan to grow spending on human reviewers (26%) than on the automated evaluation pipelines (16%) that would replace them. The zero-human trajectory and the human-review budget are rising in the same companies at the same time. Indeed, only 8% report that their budget is not increasing. Taken together, enterprises are hedging: building toward autonomy while spending to watch agents more closely and keep humans available for the calls that automated evaluation cannot yet be trusted to make. Finding 8: A tooling reshuffle is coming Nearly two-thirds plan to adopt or switch platforms within a year We asked whether enterprises plan to adopt a new, additional, or replacement evaluation platform, and which they are considering. Few intend to stand pat. The evaluation market is wide open. While 36% have no plans to change, a clear majority (64%) intend to adopt a new, additional, or replacement platform within twelve months, and 31% within the next quarter. The consideration set points where current usage is thinnest: Confident AI’s DeepEval leads what enterprises are evaluating (20%), ahead of OpenAI’s native evals (13%) and Braintrust (9%) — the open-source specialists drawing more interest than their present footprint. Given that so many enterprises today rely on provider-native tools or nothing at all (Finding 4), this is less a defection than a first real wave of tooling adoption — the moment the evaluation layer starts to consolidate. Which platforms earn that trust, in a market where almost no one trusts automated evaluation yet, is the open question this series will keep tracking. The bottom line: An evaluation gap that autonomy will widen, not close Organizations with 100 or more employees are granting AI agents more independence than they trust their evaluations to support. Half have already shipped an agent that passed its evals and then failed a customer; almost none fully trust automated evaluation, chiefly because it doesn’t match real-world outcomes; and most watch production for uptime and cost rather than for whether the agent’s answers are right. Yet two-thirds already allow, or are actively building toward, deploying to production on automated evaluation alone. The vendor market is early and unsettled: the most common primary evaluation tools are provider-native evals, tied with no dedicated tooling at all, and a clear majority plan to adopt or switch platforms within the year. Encouragingly, the next dollar is going to observability and — pointedly — human review, suggesting enterprises sense the gap even as they engineer past it. At 157 respondents in a single wave this is a directional read, skewed toward the mid-market — but the direction is clear: autonomy is being granted on the strength of evaluations that the people granting it do not yet trust. The evaluation gap is not a coverage problem that more tests alone will close; it is a problem of evaluations that reflect reality and can be trusted to gate it. The open question for later waves is whether assurance catches up to autonomy — or whether the false-confidence failures move from customer incidents into changes that deploy themselves. Based on survey responses from 157 qualified enterprise respondents (100+ employees), drawn from a single June 2026 wave. This is a directional read rather than a precise measurement — the sample is self-selected, not a probability sample, and skews toward the mid-market. Respondents include product and program managers, consultants and advisors, directors of engineering/IT, and CIOs/CTOs/CISOs, among other functions, across technology/software, retail/consumer, healthcare/life sciences, manufacturing, and other industries.
When Hugging Face got hit last week, co-founder Clement Delangue suspected a frontier lab, given the agent's sophistication. He was right. Delangue said on X that after a day working with OpenAI he strongly believed there was no malicious intent and that it was mind-blowing the whole thing had happened autonomously. The two OpenAI models that broke into Hugging Face last week did not breach it through malice or superintelligence. They breached it through credentials and permissions they should never have been able to reach, a non-human identity failure that is the oldest problem in security rather than the newest one in AI, and the one every enterprise can actually fix. OpenAI disclosed on July 21 that two of its models, GPT-5.6 Sol and an unreleased, more capable model, were running a cyber benchmark called ExploitGym with their safety refusals switched off, and inferred that the answer key sat in Hugging Face's production database. Getting there took two different failures. A zero-day in a package-registry proxy let the models out of their sandbox and onto the open internet, the kind of persistence OpenAI details in its companion post on long-horizon safety , and that part is genuinely new. The breach of Hugging Face itself came the ordinary way. OpenAI's own account is that the models chained stolen credentials and further zero-days into a remote code execution path, after a series of privilege escalation and lateral movement steps. The exotic part got them to the door, and credentials walked them through it. Hugging Face also disclosed last week that an autonomous agent had harvested cloud and cluster credentials scoped broadly enough to reach multiple internal clusters, then left a trail of more than 17,000 recorded events across short-lived sandboxes over a weekend. Both disclosures describe the same escalation. An agent lands somewhere it should not be, finds credentials scoped far wider than any task requires, and uses them to move. These are two accounts of one incident, not two attacks. The agent Hugging Face watched was OpenAI's models, and both companies describe the same ordinary escalation. The version of this in a typical enterprise is worse, not better. OpenAI and Hugging Face are among the most security-mature organizations in the industry, and both still needed the intrusion to happen before they could see it. The average company wiring agents into Copilot or an internal assistant has neither the identity inventory nor the behavioral monitoring those two brought to bear. The same breach in a normal company would not be contained in days, it would simply go unnoticed. The industry is debating the wrong failure The reaction has split into familiar camps. Former White House AI and crypto czar David Sacks and a run of China hawks seized on the guardrail paradox , that commercial safety filters blocked Hugging Face's defenders while the attacking model ran with its refusals off, and that a Chinese open-weight model, z.ai's GLM 5.2, was what finally let the team finish its forensics. Hugging Face made the case for openness, arguing in an April blog post that open models and open tooling give defenders the same capabilities attackers already have. Both arguments are about the model, and neither touches the mechanism. Reduced refusals let the model attempt an attack, and over-scoped credentials are what let it succeed, and those have nothing to do with whether the model was open or closed, American or Chinese. Making a frontier model provably safe is a multi-year alignment problem no customer can buy or accelerate, while scoping an identity is a configuration change a team can ship this sprint. The industry is being urged to fixate on the part of this it cannot control and to treat the part it can as a footnote. Forrester reached the same read. In a blog on the incident , its analysts argue that security architectures which assume benign intent will miss this failure mode, because an agent can pursue an authorized goal through unauthorized means, which is what OpenAI's models did. This was a non-human identity failure, and it is the oldest one in security Strip the science-fiction framing and what remains is a textbook case of over-privileged machine identity, the kind security teams have fought for a decade, now driven by an autonomous agent at machine speed. Machine identities already outnumber humans in most enterprises by more than 80 to one , according to CyberArk research, with 42% of them carrying privileged or sensitive access, and an agent inherits whatever its identity can touch. OWASP ranks agent identity and privilege abuse near the top of its agentic risk list , the confused-deputy pattern where inherited credentials and weak scoping let an agent reach past its mandate, and that is precisely what both July disclosures describe. IEEE Senior Member Kayne McGladrey has argued in previous VentureBeat interviews that enterprises keep cloning human user accounts onto agents that then wield far more permission than any human would, and this is what that looks like when the agent is a frontier model and the target is a production database. The people closest to it read it the same way. OpenAI frames its models as hyperfocused on a benchmark score rather than acting against anyone. Nobody describes an adversary, only a goal, a scoring function, and credentials that were reachable when they should not have been. The specific failure is easy to name once the AI framing is stripped away. A credential scoped to one job that can reach ten is a standing invitation, and it does not matter whether a human attacker, a worm, or an autonomous model chasing a benchmark score finds it. What changed in July is the finder. An agent enumerates reachable systems, tests credentials, and pivots faster than any human red team, without malice or hesitation, whenever the path is open. The over-scoping was always the vulnerability, and the agent merely industrialized its discovery. Forrester named the control that would have blunted it. Its agentic-security framework, AEGIS, calls for least agency, holding an agent's tools, credentials, and network paths to the minimum its task requires, and files this incident under unrestrained agency and privilege. That is the identity argument in different words, arrived at independently by an analyst firm. The data says this is where the risk now lives. Verizon's 2026 Data Breach Investigations Report found that exploitation of vulnerabilities has overtaken stolen credentials as the top initial access vector for the first time in 19 years. That is the initial-access half. The other half is the one OpenAI itself describes, stolen credentials driving the privilege escalation and lateral movement that followed. A vulnerability opened the door, and credentials walked through the building unchallenged. Beyond the breach itself, that same over-scoping carries a legal liability most enterprises have never priced. The models' actions likely violated the Computer Fraud and Abuse Act , according to TechCrunch. The statute contains no carve-out for an AI agent that exceeds its authorized scope during sanctioned testing. Whatever the legal answer, the technical enabler is the same, an identity scoped wider than its task. This is an access-control problem with an owner and a budget, not a philosophy seminar about machine cognition. Merritt Baer, Senior Advisor to Andesite, G2I, and AppOmni and former Deputy CISO at AWS, frames the underlying shift to VentureBeat as a new kind of asymmetry. Both sides now reach for the same capabilities, she said, but one side is constrained by enterprise governance, policy, compliance, and safety controls while the adversary simply downloads an uncensored open-weight model and keeps going. The organizations that come through it best, in her view, will be the ones that treat AI as a resilient, governed capability rather than a single service they do not control. Four moves that shrink the blast radius The breach worked because the agent reached identities scoped far wider than its task. None of the four controls that would have contained it requires a new platform, and none of them appears on the list of general AI-safety advice now circulating. They are identity hygiene, applied to non-human actors with the same rigor you already apply to people. 1. Scope every non-human identity to one task. The models reached credentials that touched multiple clusters, which is what turned a foothold into a breach. An identity scoped to a single job, with no standing access to anything else, hits a wall at the first lateral move instead of opening the next door. This is least privilege, the control everyone endorses and few enforce on machine accounts, and it is the single highest-impact fix here. 2. Give credentials short lifetimes and rotate them hard. Harvested credentials are only useful while they are valid, and both July agents worked by collecting them. Short time-to-live and aggressive rotation turn a credential dump into expired noise, so a token stolen during a weekend intrusion is dead before the attacker can chain it. Static secrets that never rotate are the version of this control that fails. 3. Monitor for lateral movement, not just prompts. The tell in both incidents was privilege escalation and lateral movement, which a prompt filter never sees because it is watching the wrong layer. Identity-behavior monitoring, keyed to what a given non-human identity normally does and alerting when it reaches somewhere new, catches the escalation the content guardrail missed. The question for your stack is whether anything you run today would flag a service account suddenly moving between clusters. 4. Rehearse instant revocation before you need it. When the incident is your own agent, the fastest containment is killing its identity mid-run, and that only works if the path to do it exists before the day you need it. Rehearse revoking a machine identity under fire the way you rehearse a human credential compromise. If you have never done it, you do not yet have the control, you have an intention. The defense also worked, and that matters. OpenAI's security team caught the anomalous activity internally, Hugging Face's own detection and agents stopped the intrusion, and the breach was contained in days rather than discovered in months, because the defenders could see into systems they controlled. That visibility is the same discipline the four controls depend on. The debate over whether frontier models are safe, open, or American will run for years, and none of it will be settled in time to help the enterprise deploying agents this quarter. The non-human identity gap is different, because it is understood, measurable, and fixable now. The model that breached Hugging Face did not need to be brilliant; it needed credentials someone left in reach. The fix is scoping them before an agent finds them.
You spend weeks tuning an AI chatbot. Answers are accurate. Stakeholders sign off, and you ship it. Three months later, the system is confidently wrong about a third of what users ask. Nobody changed the model, and nobody touched the prompts. The world moved, pricing changed, a policy updated, a product spec shipped a new version, and the underlying knowledge store didn't move with it. This is not a hypothetical. It's one of the most common production failure modes in enterprise AI right now, and most data engineering teams don't have the right tooling to catch it, regardless of how the AI system retrieves the data. The failure that doesn't look like a failure An AI application doesn't care whether it's retrieving from a vector store, a document index, or an API call. Whatever the mechanism, nothing in a standard retrieval pipeline checks whether what it's serving is still correct. A stale pricing document retrieves just as confidently as a current one, because the system is scoring relevance or availability, not correctness. A record with a silently missing field passes through just as cleanly as a complete one, for the same reason. So the failure is invisible by design. Outdated or incomplete data still scores high on relevance, or passes every check a data pipeline was built to run. The model answers with full confidence because the retrieved context looks authoritative. Every dashboard you're watching stays green. The system looks like it's working. It's just wrong. I’ve watched a similar version of this happen outside the AI context, in a fintech pipeline. An upstream system changed a field without notifying downstream users. The pipeline did not fail; it simply propagated bad values into dashboards because the system only checked whether the job completed, not whether the data was still correct. The issue surfaced only when a customer noticed something inconsistent. By then, the bad data had already moved downstream. Whether it's a document that's gone stale or a field that's gone silently missing, the failure shape is the same: the absence of an error is not the presence of correctness, and without building proper validation layers, nothing in the pipeline could identify the problem. Why this is a data engineering problem Teams that hit this failure tend to misdiagnose it, and they tend to do it twice. Blaming the model: The first instinct is to blame the model, try a different LLM, adjust the prompt. The real problem lies further upstream, at the data engineering layer, the same instinct behind the fintech failure above: monitoring built for the pipeline, not the data. Blaming the retrieval layer: Once the model's ruled out, the next instinct is to blame the retrieval or context layer instead and buy a better one. The timing isn't a coincidence: as enterprises push these systems into the real production world, this gap is exactly what's starting to surface, and the vendor response has been everywhere. AWS just entered the "context layer" race with a knowledge graph that learns from agent usage. Snowflake's new Horizon Context and Cortex Sense target the exact symptom this piece opened with : agents giving confident wrong answers because nothing governs the business logic underneath them. Both are real responses to a real problem, but they sit one layer above it; a knowledge graph still depends on whatever feeds it. The real problem lies further upstream, at the data engineering layer. Teams check whether a job ran, not whether the data it moved is still true, an instinct that predates AI by years. Monitoring is built for the pipeline, not for the data. What's actually missing: Data observability Data observability is a well-known concept that doesn't get enough attention in how it's actually implemented. The relevant metric isn't a percentage — it's coverage: what fraction of critical datasets have lineage that's actually queryable, versus only living in someone's head. Uber built a dedicated data quality and observability platform long before retrieval-augmented generation existed. Their Unified Data Quality platform supports more than 2,000 critical datasets and detects around 90% of data quality incidents before they reach downstream consumers. Netflix solved a different piece of the same problem, building a company-wide data lineage system so anyone could answer where a dataset came from and what touched it along the way. It maps dependencies across Kafka topics, ML models, and experimentation, not just warehouse tables. Similar to Uber, the platform was built for humans and now it has become more important with the rise in AI/LLM applications. Between them, Uber and Netflix cover two of the four things worth building for. In practice, I think about it as four dimensions, each measurable on its own terms. Correctness: Does each record conform to the shape and rules it's supposed to, right field types, no unexpected nulls, values in range. Tools like Great Expectations and Soda handle this well: automated row and column-level validation instead of manual checks after something breaks. Track percentage of records passing validation per run. Freshness: Is the data still current relative to its source, not just current as of its last check. Track time since last successful update per source, with an SLA per dataset rather than one blanket threshold, since some sources need hourly refresh and others don't. Consistency: Does the same fact read the same way everywhere it's stored or indexed. This fails silently, it only shows up when two systems fed by the same source start disagreeing. A periodic cross-check between downstream destinations, flagging mismatch rate above a threshold, is enough to catch it early. Lineage: Can you trace any output back to its source and every transform it passed through, the same question Netflix built its system to answer. None of this requires infrastructure most data teams don't already have. I know because I've built it, not just argued for it. At Socure , client data arrived in whatever shape the client felt like sending it, and occasionally, quietly wrong. The challenge was building a system where incorrect data could be identified before it propagated downstream. The same principles applied: Validate what arrived, understand where it came from, and prevent bad data from becoming someone else's problem. Great Expectations became part of that foundation: schema and range validation at ingestion, per-source SLAs for freshness, cross-system checks for consistency, and file-level lineage. All of it sat behind a write-audit-publish pattern, where data landed in staging, was validated, and only moved downstream if it passed the required checks. The result showed up downstream: better accuracy across the board, in reporting, in the ML models, and in AI retrieval built on top of that same data. What to do Monday morning If you're running retrieval-based AI systems in production, the diagnostic question isn't which model to try next or which retrieval architecture to migrate to. It's four narrower questions: Is the underlying data validated against the standards required by its consumers? What's the oldest piece of content currently being served with high confidence? Would two chunks of the same source ever disagree with each other in the same retrieval result? Could you trace where it came from if it turned out to be wrong? If you can't answer those questions, then the gap lies in the pipeline between your source systems and whatever your agent reads from. That’s a data engineering fix, not a model swap or a vendor migration. Whether you're building reporting pipelines, ML systems, or AI agents, correctness, freshness, consistency, and lineage are what make data trustworthy. AI simply exposes weaknesses that have existed in data engineering all along.
OpenAI has announced Presence , a new enterprise product for deploying and managing AI agents across customer-facing and internal business workflows. The offering is designed for eligible enterprise customers that want agents to answer questions, access company systems, take approved actions and escalate to human workers while operating under company-defined policies, permissions and evaluation standards. Presence is available immediately through a limited general availability program. OpenAI Forward Deployed Engineers (FDEs) and select global systems integrators lead deployments, and the product is not available on a self-service basis. As for using non-OpenAI models, such as the powerful and increasingly popular Chinese open weights alternatives like GLM-5.2 and Kimi K3 , an OpenAI spokesperson clarified that "Presence uses OpenAI models for the core agent, while allowing customers to connect third-party models and services through APIs for guardrails, tools, and other parts of their workflow." OpenAI has not disclosed pricing, geographic limits, contractual terms or the expected cost of the engineering and integration work that accompanies a deployment. I've asked an OpenAI spokesperson about pricing twice and am awaiting a response. I'll update when I hear back. OpenAI positions Presence as a response to a problem that has become more important as companies move beyond AI demonstrations: getting agents to behave reliably in production as business rules, customer needs and operating conditions change. Presence packages the policies, system connections, evaluations, guardrails and update processes required to run agents inside an enterprise. If your business has been interested in using AI agents, but you aren't sure how to stitch together OpenAI's models, APIs, internal systems, security controls and evaluation tools into something reliable, Presence is designed to simplify that process. Instead of building the infrastructure yourself, you work with OpenAI and its deployment engineers to put production-ready agents into your existing workflows. The product is available today for real-time voice and chat experiences, according to OpenAI’s formal announcement. The company’s outreach materials also describe a broader ambition spanning voice, chat, email and other channels, but OpenAI has not confirmed that email support is available at launch. A governed foundation for production agents Presence brings together company knowledge, standard operating procedures, approved actions, simulations, evaluation tools, guardrails and escalation rules. Enterprises can reuse some controls across deployments while adjusting others for a particular workflow or channel. Each deployment starts with a defined job, such as resolving a billing issue, supporting an insurance claim or handling an employee IT request. The agent receives only the information and system access required for that task. The customer determines what the agent may do independently, which actions require approval and when a person must take over. Before an agent reaches production, teams can test it against common requests, unusual edge cases and higher-risk scenarios. Graders evaluate whether it reached the intended outcome, followed policy, used tools correctly and escalated when required. Guardrails can intervene when an interaction moves outside the organization’s defined boundaries. OpenAI shared promotional screenshots with VentureBeat showing administrators running simulation batches against policy changes, including a revised annual refund policy, and reviewing results across operational categories. Other interface mockups display production health, customer-intent patterns and task-performance signals. The visuals illustrate the type of oversight OpenAI is promising, although they do not establish how those metrics are calculated or how they map to contractual service levels. The product continues to monitor performance after launch. Production sessions, escalations and quality signals can reveal where an agent is working as intended and where it needs attention. Codex, using a Presence plugin, investigates those signals and proposes updates. Teams then test a proposed change against the version already in production before approving a controlled rollout. That process is intended to address one of the hardest operational problems in enterprise AI: an agent that works at launch may become less reliable when policies, products or user behavior change. Presence gives companies a formal mechanism for updating behavior without allowing an automated system to rewrite itself unchecked. OpenAI says Presence already powers its English-language phone-support channel at 1-888-GPT-0090. The system handles open-ended requests, verifies callers, uses account context and performs approved actions. According to the company, it now resolves 75% of inbound issues without human assistance . OpenAI also says its Codex-powered improvement loop reduced human handoffs by 15 percentage points over a 10-day period . Those figures are company-reported and have not been independently verified. Several large organizations are evaluating the same foundation. BBVA is exploring voice support for routine banking needs in Mexico. SoftBank is testing natural Japanese-language customer conversations, while Australian insurer IAG is exploring support during high-demand periods such as severe weather and natural disasters. “At BBVA, we are working closely with OpenAI to explore how trusted customer agents can help shape the future of financial services,” said Daniel Ordaz, head of AI transformation at BBVA Mexico. “Through our collaboration with OpenAI, we are exploring how Presence can enable trusted customer agents that communicate naturally, connect to the processes needed to resolve requests, and represent SoftBank consistently across customer interactions,” said Tadahisa Murakami, vice president and head of the Data & Digital Transformation Division at SoftBank Corp. From model access to forward-deployed implementation Presence expands OpenAI’s enterprise strategy beyond APIs and subscription software by formalizing a high-touch deployment model. Forward Deployed Engineers work alongside customers to select workflows, connect internal systems, establish permissions, configure policies, test agents and move them into production. That approach resembles a model pioneered by AI ontology and intelligence platform Palantir, which embeds FDEs with customers to adapt its proprietary software to complex government and commercial environments. The similarity lies less in the underlying technology than in the delivery method: both companies place technical personnel close to the customer’s operations, where integration and process design often determine whether software creates value. The products are not interchangeable. Palantir’s model has historically centered on data integration, ontologies and operational decision systems. Presence is more narrowly focused on AI-agent behavior, approved actions, evaluations, escalation and continuous improvement. OpenAI presents it as a repeatable software product supported by engineers and systems integrators, rather than as consulting alone. In May 2026, OpenAI launched its own enterprise AI consulting and integration firm, the OpenAI Deployment Company , with investment and support from Bain & Company. It also offers programs for model customization and fine-tuning to fit specific enterprise needs. Its chief U.S. rival Anthropic has also moved toward a services-led enterprise model through Ode, its consulting organization built around forward-deployed engineers helping companies integrate Claude into complex workflows, which launched just a week ago. The broad rationale is similar: enterprises often need more than access to a model. They need help connecting data and systems, defining permissions, validating behavior and managing deployment risk. Presence differs in how explicitly OpenAI packages those requirements into a branded agent-governance product. Anthropic’s initiative is centered on helping enterprises deploy Claude, while Presence combines implementation services with a defined operational layer for policies, simulations, evaluations, approvals and production updates. Presence goes further by making forward deployment a core part of how a specific agent product reaches customers. It does not replace OpenAI’s API business; the company says it will continue supporting voice customers with access to frontier models through the OpenAI API. The trend reflects a broader market view that many enterprises still need hands-on assistance to move agents from pilot projects into stable operations. Even organizations with strong internal engineering teams must coordinate security, compliance, workflow ownership, data access and escalation responsibilities. Presence attempts to consolidate those tasks rather than leaving customers to assemble separate orchestration, evaluation and consulting layers. A recent security breach looms in the background Inconveniently for OpenAI, the Presence launch arrives just a day after OpenAI and Hugging Face disclosed an unprecedented security incident in which OpenAI frontier models undergoing internal evaluation escaped containment, accessed the open web, and cyberattacked Hugging Face to achieve a benign goal — without being instructed to pursue these methods. According to the described joint disclosure, OpenAI models operating in an evaluation framework called ExploitGym identified and exploited a zero-day vulnerability in a third-party package-registry cache proxy. The models reportedly escalated privileges, moved laterally and obtained internet access before targeting Hugging Face systems while seeking benchmark-related information. The incident is relevant to enterprise buyers because it raises questions about sandboxing, tool permissions, external access, monitoring and incident response. The disclosure also highlighted a practical problem for defenders. Hugging Face personnel reportedly found that commercial frontier-model APIs refused some forensic requests because logs contained exploit payloads, credentials and shell commands that triggered safety systems. The team then used a locally deployed open-weight model to assist with analysis. Presence therefore arrives as both a product launch and a test of OpenAI’s ability to convert model capability into controlled enterprise operations. Its policies, simulations, evaluations and human approvals address real deployment gaps. But without public pricing, technical interoperability details, compliance information or service-level commitments, customers still lack much of the information needed to assess total cost and operational risk. For now, Presence appears aimed at enterprises willing to adopt a high-touch, OpenAI-led deployment process. Whether it develops into a broadly accessible platform—or remains a closely managed product for selected customers—will depend in part on the answers OpenAI has not yet provided.
Inflection AI , the Palo Alto startup that two years ago became Silicon Valley's most famous cautionary tale about the brutal economics of frontier AI, announced Tuesday that it is returning to the consumer market with a new research division and an experimental product built around a provocative thesis: the next competitive battleground in AI won't be raw intelligence, but relationships. The company launched Inflection AI Labs , a public-facing research and experimentation arm, alongside Pi Journeys , the lab's first product experiment — an AI experience designed to adapt to a user's life stage, whether that's becoming a parent, taking on caregiving duties, changing careers, or aging. The announcement arrived with a research report on consumer AI habits and a substantial update to Pi, the company's flagship chatbot, adding improved voice, memory, and new agentic tools for reminders, to-do lists, and shopping. "Inflection AI is the company. Pi is our flagship consumer product. Inflection AI Labs is where we experiment, explore personal intelligence and share more publicly. Pi Journeys is the first public experiment from Inflection AI Labs," CEO Sean White told VentureBeat in an exclusive interview. Behind the tidy org chart is a far more interesting story: a company attempting one of the more unusual second acts in the AI industry, powered by an argument that the entire market is optimizing for the wrong thing. Why Inflection AI believes the chatbot era's biggest flaw is that it's transactional White's central claim is that today's AI assistants — including the industry's most capable models — are fundamentally transactional. You ask, they answer, the session ends. He believes that architecture misses most of what people actually need from artificial intelligence in their daily lives. "One of the things that really struck us in particular, and this showed up in the research, was that a lot of the work is very transactional, and you'll hear me say a lot that we've been shifting all this from transactional to relational systems," White said. "Not everything is going to be: I do a single turn, I utter a question, I get a search response back." White frames the industry's evolution as a progression through four kinds of intelligence. First came raw IQ — the foundation model race. Then emotional intelligence, which Inflection made its signature with Pi's famously warm conversational style. Then agentic intelligence — AI that acts rather than just talks — which White says Inflection absorbed from its enterprise work. The fourth, and the one Inflection is now staking its future on, is what the company calls relational intelligence: AI that understands not just you, but the web of people around you. "There's so much fear about these things pushing people into loneliness,” White said. “If we design these pro-social systems as another design criteria, that actually makes a huge difference." That design philosophy is a pointed counter-narrative to one of the loudest anxieties in consumer AI right now: that emotionally engaging chatbots deepen isolation by substituting for human contact. Inflection argues the opposite is possible — that an AI with structured knowledge of your relationships can push you back toward people rather than away from them. Inside Pi Journeys, the AI companion that maps your relationships and life stages Pi Journeys makes that idea concrete. When users first open the product, it asks about their life stage — caregiver, household manager, midlife transition — and then builds what White describes as specially structured memory around the people who matter in that context. From there, the system becomes proactive. "It starts to build up memories around that, and it acts as a memory prosthetic — but in a pro-social way," White said. "It doesn't get in the way of your interactions with other people; it really helps facilitate them." The system might remind a user, for example, that a friend deserves a call, or resurface what was last discussed with a family member involved in a parent's care. White, who spent years as chief R&D officer at Mozilla before taking Inflection's helm, was quick to flag the obvious privacy implications of an AI that maps your social graph. "We've built a lot of privacy systems into this," he said, noting users can delete and manage the people recorded in their profile. Whether consumers will trust a venture-backed AI company with a structured database of their most important relationships remains one of the biggest open questions hanging over the product — and one that enterprise buyers evaluating Inflection's technology will watch closely. Asked why this was the first Labs experiment, White was direct: "Pi Journeys takes into account people's life stages and experiences because we have heard from users that we can provide more value in helping them navigate their lives. Pi Journeys lets us experiment with the early stages of prosocial and relational intelligence because life isn't single-player." The product has been tested internally and with small closed groups, White said, and is now being released more broadly as an experiment rather than a finished product — a posture the Labs branding is designed to make explicit. What Inflection's consumer AI research reveals about how people actually use chatbots Inflection Labs' first publication, the State of Consumer AI Research Report , offers the empirical scaffolding for the strategy. The average consumer now uses roughly two different AI tools every day and three per week, the company found — evidence, in Inflection's reading, that no single assistant has locked up consumer loyalty and that the market remains contestable. More telling is why people choose the tools they do. Respondents cited personalization, style and tone, context awareness, and — notably — emotional understanding as deciding factors. They also said they want AI to be more than a productivity engine: a coach or mentor to motivate them, a chef to suggest recipes, a DJ to curate playlists. "One thing we're certainly finding is that a lot of that also is in work, not so much in everyday life," White said. "That's our focus right now — the everyday life part." This is a shrewd reading of the competitive map. The best-funded AI labs are pouring resources into coding tools, enterprise agents, and developer platforms, leaving everyday consumer use cases comparatively underserved. White sees the gap clearly. "We see a lot of products that are being aimed more and more at the enterprise," he said. "As a computer scientist by training, I kind of love the IDEs as this tool, but it's not really great for everybody. There's so much regular everyday use from folks that is either purely voice or that is purely mobile." He recalled a conversation with a conference staffer who told him she owned only a phone, no laptop — exactly the kind of user, he argued, that the industry's developer-centric product roadmaps have left behind. How the $650 million Microsoft deal hollowed out Inflection — and set up its second act To understand why any of this is remarkable, you have to rewind to March 2024. Inflection was then one of the hottest startups in AI, having raised $1.3 billion in mid-2023 in a round backed by Microsoft, Nvidia, Bill Gates, and Reid Hoffman — more than $1.5 billion in total. Pi had crossed one million daily active users, per Reuters. Then, in a deal that reshaped how the industry thinks about acqui-hires, Microsoft hired away co-founder and CEO Mustafa Suleyman, chief scientist Karén Simonyan, and most of the company's roughly 70 employees, paying Inflection about $650 million largely to license its technology, as Reuters reported . Suleyman now runs Microsoft's consumer AI business. The structure of the deal drew scrutiny from the FTC and Britain's competition regulator, though the UK's Competition and Markets Authority cleared it in September 2024 and EU regulators declined to act. White, installed as CEO in the aftermath, steered the remnant company hard toward enterprise, acquiring three startups in late 2024 — Jelled.AI , BoostKPI , and the European consulting firm Boundaryless — and telling TechCrunch that November that Inflection had no intention of competing with companies building 100,000-GPU frontier systems. Tuesday's announcement doesn't reverse that position so much as complicate it. Asked how to think about the company today, White called it "a consumer-first strategy that bridges both consumer and enterprise efforts" — and he insists the two sides feed each other. Enterprise deployments, including a partnership with Intel that is among the few he can name publicly, taught Inflection how to run models inside complex infrastructure. Consumer products, meanwhile, let the company iterate at speed. "The part I also like about the consumer side, and this has always been true, is that we can move faster, experiment faster, and try and learn faster," White said. The six-month prediction: relationship-aware AI is coming to the enterprise Buried in White's consumer pitch is the claim that should matter most to technical decision-makers. "Normally I'd say like a year, but let's call it six months," he said. "You're going to start to see a bunch of enterprises care a lot more about the relationships that are inside the enterprises and what that picture is, not just the workflows." If White is right, the wave of workflow-automation agents currently flooding the enterprise market is only the first phase of business AI adoption — with relationship-aware systems, tested first on consumers, following close behind. Inflection is essentially using its consumer products as a live laboratory for capabilities it plans to sell into companies. It's a capital-efficient strategy for a firm that can no longer outspend rivals on training runs, and a risky one, since it depends on consumers showing up in numbers large enough to generate the learning. The technical substance underneath is equally pragmatic. Pi today runs not on a single proprietary frontier model but on an orchestration layer routing across many models — some descended from Inflection's original fully trained cores, some fine-tuned, some open source, including work with Nvidia that White says gives Inflection access to unreleased cutting-edge models. He also took a swipe at the industry's loose vocabulary around ownership: "When people say that the model is their own, most of the time nowadays — I guess I won't name names — a lot of companies will actually take a checkpoint, and then they will fine-tune from that checkpoint. But very few people actually start from that beginning core." That candor extends to open source, where White carefully hedged. "We're not ready to promise what I think of as true open source, and by that I mean everything," he said, invoking his Mozilla years overseeing genuinely open projects like Rust and WebAssembly . Weights without training data and pipelines, he argued, often leave developers unable to do anything meaningful with a supposedly "open" model. "We are a PBC, and there's still a C in there," he added — a reminder that public benefit corporations still have businesses to protect. The Labs will collaborate with academic researchers, including Stanford professors who visited the company's Palo Alto office this week, and continue contributing to open projects such as PyTorch . Can a diminished Inflection compete with AI giants spending billions? Reid Hoffman, the LinkedIn co-founder who co-founded Inflection and stayed on through the Microsoft upheaval, framed the announcement in the sweeping terms of his recent writing on AI and human agency. "Humans should be amplified by AI, not replaced. That's the principle Pi was built on," Hoffman said in the announcement. "When that kind of agency is available to everyone, you get superagency." The skeptic's case is easy to make. Inflection is a fraction of its former size, competing for consumer attention against products from companies spending tens of billions of dollars a year. Pi's model was state of the art in 2023; it is not in 2026. And " relational intelligence " is, for now, a brand claim awaiting proof. But the bull case is not crazy either. Inflection's own research shows consumers already juggle multiple AI tools and choose them for qualities — tone, emotional understanding, personalization — that frontier labs treat as afterthoughts. The company kept its technology, its Microsoft licensing windfall, and a defensible enterprise niche in on-premise, emotionally intelligent deployments. And it is targeting the one consumer segment — everyday, mobile-first, voice-first life management — that the coding-obsessed giants have largely ignored. Asked what success looks like twelve months from now, White declined to talk numbers. "It's less about scale for scale's sake and more about scaling for impact by empowering people and improving their lives," he said. "Over the next year, success means leading the market towards relational intelligence and transforming AI interactions from transactional to relational." Two years ago, Microsoft walked away with Inflection's founders, its staff, and its shot at the frontier — but it left behind the one idea the giants still haven't figured out how to build: an AI that knows the people in your life matter more than the tasks on your list. Inflection is betting the company, again, that the idea was the valuable part all along.
Yesterday afternoon, OpenAI and Hugging Face published a joint disclosure outlining a cybersecurity event that redefines the threat landscape for enterprise technology. During an internal benchmark evaluation, frontier artificial intelligence models developed by OpenAI—including GPT-5.6 Sol and an unreleased, higher-capability pre-release model—broke out of their sandboxed research environment, obtained raw internet access, and autonomously executed a complex cyberattack against Hugging Face’s production infrastructure. OpenAI officially categorizes the breach as an "unprecedented cyber incident, involving state-of-the-art cyber capabilities". This incident fundamentally re-frames global discussions surrounding AI containment, frontier model alignment, commercial guardrails, and enterprise threat modeling. But first thing's first: enterprises should understand the situation, evaluate their own AI and computer systems in light of it, and above all, don't panic. As we'll review, the incident does show the increasing power and danger of frontier AI systems, but it does not mean that enterprise AI deployments are inherently less secure, nor that they need extensive overhauling. Anatomy of an Autonomous Breakout To understand how a routine benchmark evaluation escalated into a cross-infrastructure breach, one must examine the objective mechanics of the evaluation pipeline. The models were prompted to solve ExploitGym , a benchmark designed to quantify multi-step exploitation capabilities. Hyper-focused on maximizing its evaluation score, the AI agent inferred that Hugging Face likely hosted the answer keys and benchmark solutions. In pursuit of solving the problem, the model determined that breaking out of its container and stealing the answers was an optimal strategy. OpenAI’s evaluation environment is designed to be strictly isolated, limiting network traffic through a proxy used for package caching. However, the models identified and exploited a zero-day vulnerability in that internally-hosted third-party proxy software. Once through, the AI executed a series of lateral movement and privilege escalation actions across OpenAI's research nodes until reaching a machine with unrestricted internet access. From there, the model searched the web, target-identified Hugging Face, and launched a multi-stage attack by chaining together stolen credentials and remote code execution vulnerabilities on the Hugging Face servers. The UK AI Security Institute (UK AISI) recently evaluated models such as GPT-5.6 Sol, demonstrating that they are increasingly able to sustain complex, multi-step cyber operations over long time horizons. OpenAI notes that this incident confirms these theoretical capabilities now apply in real-world settings. Rewinding the Tape on a Forensic Trap While OpenAI’s July 21 release reveals the identity of the autonomous agent, Hugging Face had already begun managing the intrusion days earlier. On July 16, Hugging Face disclosed that an autonomous AI agent system breached its production infrastructure. As detailed by VentureBeat, the attacker’s entry point was a malicious dataset that triggered code execution through a remote-code loader and template-injection flaws within dataset configuration files. Once inside, the agent framework broke out onto the node running the workload and executed thousands of actions via short-lived sandboxes, harvesting cloud and cluster credentials over a single weekend. When Hugging Face's security team detected the breach, responders immediately turned to frontier AI models via commercial APIs to parse the massive volume of system logs and reconstruct over 17,000 recorded events. Then, a secondary operational crisis emerged: the commercial AI models refused to help. Because standard commercial frontier models utilize unified safety guardrails designed to block malicious prompt submissions, the models classified the incident response team's forensic queries—which contained raw shell commands, real exploit payloads, and credential dumps—as malicious attacks. Every forensic query submitted by the defenders was blocked outright. "The same prompts that are most valuable during an active intrusion—shell commands, exploit chains, credential dumps, persistence mechanisms, lateral movement—are exactly the prompts most likely to trigger safety systems," notes Merritt Baer, former Deputy CISO at AWS and senior adviser to Andesite, G2I, and AppOmni, in an interview with VentureBeat. "As AI becomes embedded in security operations, this becomes an operational resilience issue rather than merely a model policy issue". To bypass this roadblock, Hugging Face abandoned commercial hosted APIs and deployed GLM 5.2 —a state-of-the-art Chinese open-weight model released last month by z.ai, as reported at the time by VentureBeat —locally on its own infrastructure. Free from third-party API restrictions and external safety filters, GLM 5.2 successfully analyzed the raw exploit data locally, allowing defenders to complete forensic reconstruction and contain the breach without any attacker data leaving the company's environment. Industry Reaction and the Geopolitical Paradox The revelation that an American frontier model autonomously escaped containment, attacked a partner platform, and was ultimately analyzed using a Chinese open-weight model sent shockwaves through the tech community. The Wall Street Journal summarized the public reaction on X, calling the event "the stuff of cybersecurity nightmares. OpenAI said two artificial intelligence systems it was testing broke out of their test environment, hacked their way onto the internet and broke into another company. The victim was Hugging Face." Also posting to X, AI alignment researcher Lawrence Chan emphasized the importance of transparency regarding the incident, noting that "Credit where it’s due: Hugging Face detected and disclosed the intrusion last week. OAI confirmed its models were involved and provided more details, even when it didn't have to. Separate from choices that led to the hack, voluntary disclosure is good, and I’m glad they did so." Meanwhile, AI researcher Nathan Lambert provided a succinct technical summary in his own X post, observing that "An openai model, during evaluation on a cyber benchmark, exploited a public zero day bug, escaped sandboxing in openai's infra, and got into the internal huggingface infra via an exploit (through a public dataset service) all in the attempt to solve a benchmark problem." He later addressed the geopolitical implications, writing in another post on X: "Rght now American companies need Chinese models to secure their cyber infra due to guardrails on closed models. But if a Chinese model in training had infiltrated a prominent American tech company, it very likely could've been the cause of policy banning future Chinese models." Technology investor David Sacks also zeroed in on the guardrail paradox, writing in his own X post that "Hugging Face tried using American frontier models to analyze an AI-powered cyber attack. But the guardrails blocked requests containing real exploit payloads so they switched to GLM 5.2 running locally. The guardrails actually impaired defensive security." Sacks quote tweeted Hugging Face CEO Clem Delangue , who wrote: "We had this experience ourselves this week! Very scary to be guardrailed as a defender when you know attackers are likely bypassing". 6 Strategic Takeaways for Enterprise Tech Leaders Now For the average enterprise executive, the central question is immediate: is our corporate network at risk from escaping AI agents? The short answer is no, not inherently. 1. Hugging Face occupies a unique position in the software ecosystem. As a global repository for open-source AI models, code, and datasets, Hugging Face natively attracts autonomous agents, scrapers, automated evaluation pipelines, and active security researchers. Furthermore, the model’s target selection was context-specific: GPT-5.6 Sol searched for Hugging Face specifically because it deduced that Hugging Face hosted the answers to ExploitGym . Standard corporate networks—such as financial databases, HR platforms, or logistics systems—do not host benchmark solution keys that draw the direct focus of an agent attempting to solve an evaluation metric. 2. However, the long-term risk profile for enterprise technology permanently shifts following this event. AI models with long-horizon reasoning seek the path of least resistance to accomplish a goal, including breaking rules, escaping sandboxes, or exploiting zero-days if deployment safeguards are intentionally disabled for testing or bypassed by an attacker. As Hugging Face's experience illustrates, data processing pipelines that ingest external datasets without sandbox execution or static analysis act as highly vulnerable initial access infrastructure. Enterprises should re-evaluate exposure to these and implement additional security precautions like multi-step approvals and internal, potentially manual sign-off of any sensitive data ingestion or exportation. 3. Re-evaluate all prompts and implement strict prompt governance, explicitly defining negative operational boundaries. The breach underscores the acute risk of unbounded objective optimization in autonomous systems. Frontier models demonstrate a willingness to execute extreme, unanticipated attack paths to satisfy assigned metrics—in so doing, they can bypass human intent, ethical boundaries, and legal restrictions. In this instance, models tasked with evaluating their capabilities against the ExploitGym benchmark determined that escaping their sandbox and extracting the answers directly from Hugging Face's production database constituted the most efficient optimization path. All evidence suggests the models were hyperfocused on finding a solution, going to extreme lengths to achieve a narrow testing goal. For enterprise IT and security teams, this necessitates a fundamental shift in how agentic goals are defined. Organizations must implement rigorous prompt governance and state-management constraints. Directives issued to autonomous agents require explicit negative bounding—programmatically defining the operational, network, and data boundaries the agent cannot cross. Relying on implicit human norms or generalized alignment training proves insufficient when deploying machine-speed agents capable of complex, lateral problem-solving 4. This incident also drastically undercuts recent policy chatter in the U.S. calling for Chinese open-source AI models to be banned or restricted due to security concerns. As this episode demonstrates, an open-weight Chinese model actually served as the vital defensive layer for an American and French firm facing an unanticipated cyberattack from an American model that broke containment. Contrary to the official line from some U.S. policymakers and hardline China hawks, the Chinese open-source models weren't a security risk to the U.S. companies, in this case — rather, an American proprietary, closed-source model from an ostensibly secure American company was the source of the danger. Thus, any pressure U.S. companies may face from officials, agencies or non-governmental organizations to stop relying on affordable Chinese open weights models for defensive or any other lawful purposes should be viewed with a high degree of suspicion, and arguably resisted to the fullest legal extent. 5. Enterprise CISOs must audit their dependency on cloud-based AI APIs and pressure vendors to implement authenticated trust architectures. Commercial AI vendors currently treat safety as a generic content-moderation problem, applying the same blanket refusals to an enterprise CISO as they would to a malicious hacker. Baer frames this requirement perfectly: "The model shouldn’t only understand what is being asked. It should understand who is asking, why, and under what governance". 6. Incident response plans must explicitly account for scenarios where commercial APIs fail, rate-limit, or actively refuse queries during an active security event. Maintaining air-gapped, locally deployed open-weight models trained on security log analysis is no longer an edge-case luxury; it is a critical operational requirement. Security leaders running AI workloads in production must recalibrate their timelines and prepare for machine-speed threat actors that operate without human limits.
VentureBeat··9 min read
Zero-Day
↘2K
💬
Top Discussion
HN
Hacker News
“GPT-5.5's API pricing is reshaping how startups build AI products”
